Digital PDFs

AA-PBKXA-TE

June 1990

97 pages

Original

3.4MB

Document:	ULTRIX Guide tc the X/Open Transport interface
Order Number:	AA-PBKXA-TE
Revision:	000
Pages:	97
Original Filename:

OCR Text

ULTRIX

. -------------------------------------

Guide to the X/Open Transport Interface

Order Number: AA-PBKXA-TE

ULTRIX

Guide to X/Open Transport Interface

Order Number: AA-PBKXA-TE
June 1990

Product Version:

XlOpen Transport Interface Version 1.0

Operating System and Version:

ULTRIX Version 4.0

This manual contains information on writing network applications using the X/Open
Transport Interface. It describes the system calls and subroutines used with the X/Open
Transport Interface.

digital equipment corporation
maynard, massachusetts

Restricted Rights: Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in
subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause of DFARS 252.227-7013.
© Digital Equipment Corporation 1990
All rights reserved.

The information in this document is subject to change without notice and should not be construed as a commitment
by Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility for any errors that may
appear in this document.
The software described in this document is furnished under a license and may be used or copied only in accordance
with the terms of such license.
No responsibility is assumed for the use or reliability of software on equipment that is not supplied by Digital or its
affiliated companies.

The following are trademarks of Digital Equipment Corporation:

IBmaama
CDA
DDIF
DDIS
DEC
DECnet
DECstation

DECUS
DECwindows
DTIF
MASSBUS
MicroVAX
Q-bus
ULTRIX
ULTRIX Mail Connection

ULTRIX Worksystem Software
UNIBUS
VAX
VAXstation
VMS
VMS/ULTRIX Connection
VT
XVI

UNIX is a registered trademark of AT&T in the USA and other countries.
XlOpen is a trademark of X/Open Company Ltd.

Contents

About This Manual
Audience

vii

Organization

. . ... . . . ... .. . .... . . ... . ...... .. . . . . . . . ...... .... . .... .. . ...... . ..... . . . ... .... . . . . . . . .. ... .. .. . .. . ..

Related Documents

. . .. . .. . . ... .. .... . . ... .. . .... . . . . . .. . .. . .......... ...... .. .. ... . . ..... . . ... . . . .. .. .. . .. ...

vii
viii

Conventions

viii

New and Changed Information

Overview of the Transport Service Interface

1.1

Transport Service Interface

1-1

1.1.1

1-2
1-2
1-2
1-2

1.1.2

1.1.3
1.1.4

Transport Service Interface Characteristics ....................................... .
Application Portability .................................................................. .
XTI Enhancements ........................................................................ .
Event Handling ............................................................................ .

1.2

Transport Provider

................................................................................... .

1-3

1.3

Transport Endpoints

................................................................................ .

1-3

1.4

Modes of Service

1-3

1.4.1

1-3

Connection-Mode Service

1.4.1.1
1.4.1.2
1.4.1.3
1.4.1.4
1.4.1.5
1.4.2

1-4
1-5
1-6
1-6
1-7

..........................................................

1-8

Initialization ...................................................................... .
Data Transfer ..................................................................... .
Deinitialization .................................................................. .

1-9

Connectionless-Mode Service

1.4.2.1
1.4.2.2
1.4.2.3
1.5

Initialization .......................................................................
Connection Establishment ....................................................
Data Transfer ......................................................................
Connection Release .............................................................
Deinitialization ...................................................................

State Transitions

1-8
1-10

1-10

Connection-Mode Service

2.1
2.2

Connection-Mode Programming Examples

2.3

Connection-Mode Initialization

2-1
2-1

2.2.1
2.2.2

2-3
2-5

The Client
The Server

Data Transfer

2.4.1
2.4.2
2.5

................................................................................... .
................................................................................... .

Connection Establishment

2.3.1
2.3.2
2.4

The Client
The Server

................................................................................... .
................................................................................... .

.......................................................................................... .

The Client
The Server

2.6

Deinitialization

Connectionless-Mode Service

3.1
3.2
3.3

Initialization

Advanced Topics

4.1

Management of Local Transport Characteristics

3-1
3-3
3-5

Deinitialization

4.1.2

..................................... .
.................................... ..

4-1
4-1
4-2
4-2
4-3

........................ .......•..................................................

4-4

Transport-Protocol Characteristics ................................................... .
Quality of Service ......................................................................... .
4.1.2.1
4.1.2.2

4.2
4.3
4.4
4.5

2-21

Data Transfer

4.1.1

2-16
2-16
2-18
2-19
2-19
2-20

Connection Release

2.5.1
2.5.2

2-10
2-11
2-13

Types of Service Supported by TCP
Types of Service Supported by UDP

Management of Memory Resources
Modes of Execution
Event Handling

4-4

Error Reporting

4-5

ivContents

State Transitions

A.l

States and Events in XTI

A-I

A.I.l
A.I.2
A.l.3
A.I.4
A.I.5
A.I.6

A-I
A-2
A-4
A-5
A-5
A-7

Transport Service Interface States ................................................... .
Outgoing Events .......................................................................... .
Incoming Events .......................................................................... .
Transport User Actions ................................................................. .
State Tables ............................................................................... ..
Events and TLOOK Error Indication ............................................. ..

Guidelines for Writing Protocol-Independent Software

B.l

Amount of Required Changes

B.2

General Rules

Migrating from Socket-Based Software to Xli-Based Software

Connection-Mode Programming Examples

D.l

Connection-Mode Client Programming Example

D-l

D.2

Connection-Mode Server Programming Example

D-4

Connectionless-Mode Programming Examples

E.l

Connectionless-Mode Server Programming Example

B-1

E.2

Connectionless-Mode Client Programming Example

B-3

....................................................................

B-1
B-1

Glossary
Examples
2-1: Initialize Phase of the Client (Connection Mode)

2-3

2-2: Initialize Phase for the Server (Connection Mode)

2-6

2-3: Connection Phase for the Client (Connection Mode)

2-11

2-4: Connection Phase for the Server (Connection Mode)

2-13

2-5: Data Transfer for the Client (Connection Mode)

.......................................... ..

2-16

............................................... ..

2-18

2-6: Data Transfer for Server (Connection Mode)

2-7: Connection Release for the Client (Connection Mode)

2-19

2-8: Connection Release for the Server (Connection Mode)

2-21

Contents v

3-1: Initialization Phase for the Transaction Server (Connectionless Mode)

..............

3-1

..........................

3-4

...................................................................

D-l

3-2: Data Transfer for Transaction Server (Connectionless Mode)
D-l : Connection-Mode Client Code
D-2: Connection-Mode Server Code

D-5

E-l: Connectionless-Mode Server Code

B-1

E-2: Connectionless_mode Client Code

B-3

Figures
1-1: Transport Service Interface

1-1

1-2: Communication Path Between Transport User and Provider
1-3: Connection Establishment

.......................... ..

1-4

.......................................................................... .

1-5

1-4: Connectionless Communication Path

........................................................... .

1-8

Tables
1-1: Initialization Functions for Connection-Mode
1-2: Connection Establishment Functions

.............................................. ..

1-5

.......................................................... ..

1-6

1-3: Data Transfer Functions for Connection-Mode

1-6

1-4: Connection Release Functions

.................................................................... .

1-7

.......................................................................... .

1-8

1-5: Deinitialization Functions

1-7: Data Transfer Functions for Connectionless-Mode

1-9
1-9

1-8: Deinitialization Functions for Connectionless-Mode

1-10

4-1: Transport Provider Characteristics

...............................................................

4-2

.......................................................................................

4-2

1-6: Initialization Functions for Connectionless-Mode

4-2: Types of Service

A-I: Transport Service Interface States
A-2: Outgoing Events

. . ... .. ... ...... .. .. ... .. ..... . . . .. .. . . ... .. .... .. ... ... . .. ... .

A-I

.......................................................................................

A-2

A-3: Context Values for Table A-2
A-4: Incoming Events

.....................................................................

A-3

.......................................................................................

A-4

A-5: Common Local Management State Table

.....................................................

A-6

...............................................................

A-6

....................................................................

A-6

A-6: Connectionless-Mode State Table
A-7: Connection-Mode State Table

A-8: Asynchronous Events That Returns a [TLOOK] Error

...................................

A-7

C-l: Active TCP User

......................................................................................

C-l

C-2: Passive TCP User

........................... ..........................................................

C-2

................................................................................................

C-3

C-3: UDP User

vi Contents

About This Manual

This guide contains information on the X/Open Transport Interface (XTI) with
information necessary for developing network application programs on the ULTRIX
operating system. The manual also contains information on migrating from socketbased software to the XTI-based software.

Audience
This guide is intended for experienced programmers who want to write network
application programs using the X/Open Transport Interface. Readers should be
familiar with the C programming language and ULTRIX networking concepts.

Organization
This guide consists of four chapters and five appendixes:
Chapter 1: Overview of the Transport Service Interface
This chapter provides a high level overview of the transport service interface
(XTI), that supports the transfer of data between two user processes: transport
user and transport provider.
Chapter 2: Connection-Mode Service
This chapter describes the connection-mode service of the transport service
interface. The client-server paradigm is used to describe the connection-mode
service.
Chapter 3: Connectionless-Mode Service
This chapter describes the connectionless-mode service of the transport service
interface. The connectionless-mode service is used for short-term
request/response interactions.
Chapter 4: Advanced Topics
This chapter describes: The characteristics associated with a transport endpoint
that can be changed after an endpoint is opened. How memory resources can be
managed. Choosing a mode of execution for an application. Reporting events to
an application. Using the two levels of error reporting.
Appendix A: States and Events in XTI
This appendix contains tables that list the possible states of the transport
provider as seen by the transport user, the incoming and outgoing events that
may occur on any connection, and identifies the allowable sequence of
functions.
.
Appendix B: Guidelines for Writing Protocol-Independent Software
This appendix describes how applications can be written to run over several
transport providers without significant changes.

Appendix C: Migrating from Socket-based Software to XTI-based Software
This appendix describes how to migrate a program that uses sockets to a
program that uses the XTI interface.
Appendix D: Connection-Mode Programming Code Examples
This appendix contains the entire connection-mode programming code from
which the examples used in Chapter 2 are taken.
Appendix E: Connectionless-Mode Programming Code Examples
This appendix contains the connectionless-mode programming code from which
the examples used in Chapter 3 were taken.

Related Documents
You should have available the documents in the ULTRIX documentation set,
including the ULTRIX Reference Pages, appropriate C programming documentation,
and the Guide to Network Programming.

Conventions
macro

In text, bold type is used to introduce new tenns.

{I}

In syntax descriptions and function definitions, braces enclose
lists from which one item must be chosen. Vertical bars are used
to separate items.

cat(1)

Cross-references to the ULTRIX Reference Pages include the
appropriate section number in parentheses. For example, a
reference to cat(1) indicates that you can find the material on the
cat command in Section 1 of the reference pages.

system output This typeface is used in interactive examples to indicate system
output and also in code examples and other screen displays. In
text, this typeface is used to indicate the exact name of a
command, option, partition, pathname, directory, or file.

rlogin

In syntax descriptions and function definitions, this typeface is
used to indicate tenns that you must type exactly as shown.

UPPERCASE
lowercase

The ULTRIX system differentiates between lowercase and
uppercase characters. Literal strings that appear in text,
examples, syntax descriptions, and function definitions must be
typed exactly as shown.

filename

In examples, syntax descriptions, and function definitions, italics
are used to indicate variable values; and in text, to give references
to other documents.
A vertical ellipsis indicates that a portion of an example that
would nonnally be present is not shown.

viii About This Manual

New and Changed Information
This is a new manual.

About This Manual ix

Overview of the Transport Service Interface

This chapter provides a high-level overview of the transport service interface, which
supports the transfer of data between two user processes: transport user and transport
provider. Figure 1-1 illustrates the transport service interface.

Figure 1-1: Transport Service Interface
TRANSPORT USER
(Networking application or Session layer protocol)
~~

Service
Request

Communication
Path

Events

TRANSPORTSERVICE
INTERFACE

TRANSPORT PROVIDER
(TCP or UDP protocol)
ZK-0098U-R

The transport provider is the entity that provides the services of the transport service
interface, and the transport user is the entity that requires these services. Examples of
transport providers are Transport Control Protocol (TCP) and User Datagram
Protocol (UDP). A transport user may be a networking application or session layer
protocol.
To access the services of the transport provider, the transport user issues the
appropriate service requests. An example of a service request would be to request a
data transfer over a connection. In response, the transport provider notifies the user of
various events, such as the arrival of data on a connection.

1.1 Transport Service Interface
The transport service interface (XTI) consists of a set of transport-independent C
library functions that conform to the X/Open Transport Interface specifications. XTI
applications can be written to support both BSD sockets and System V streams. A
network application that uses the XTI calls is portable across systems, as long as both
systems incorporate the XTI calls and support the same underlying transport provider.
At present, ULTRIX operating system supports TCP and UDP transport providers
using XTI.

1.1.1

Transport Service Interface Characteristics
In many ways, XTI is similar to the existing Berkeley Software Distributions (BSD)
socket-based interprocess communication (lPC) primitives. Both provide a
programming interface to access the underlying transport services and both use a file
descriptor to identify the endpoint for communication. In XTI, the endpoint (file
descriptor) is called a transport endpoint.

1.1.2

Application Portability
Compared to IPC, XTI provides additional functionality to facilite application
portability. The additional functionality consists of the following:

1.1.3

•

XTI provides calls that return the characteristics of the transport protocol. A
portable application can use this information to identify the underlying transport
provider. XTI also provides calls to retrieve, verify, or negotiate protocol
options with the local transport provider.

•

XTI defines an event management mechanism that lets transport providers
notify applications of significant events. The current event on a transport
endpoint is always available through user request. Furthermore, the occurrence
of an asynchronous event that requires immediate attention also causes some
XTI calls to return t_look () (some event).

•

XTI allows multiple processes to share the same transport endpoint.
Synchronization calls are defined to allow an application to synchronize with its
transport provider. Synchronization among applications is still left to the user
application.

XTI Enhancements
Compared to the BSD IPC calls, XTI has enhancements. These include:

1.1.4

•

During connection establishment, XTI allows an application to exchange and
negotiate connection options, determine the status of a previously-sent connect
request, or selectively accept connections from several incoming connections.

•

During data transfer, XTI applications can send one transport service data unit
(normal or expedited) in multiple portions or receive one transport service data
unit (normal or expedited) using multiple issues of the same call.

•

During connection release, XTI applications can send user-initiated disconnect
requests, identify the cause of a disconnect and retrieve any user data sent with
the disconnect, initiate an orderly release, or acknowledge receipt of an orderly
release indication.

Event Handling
The transport service interface is inherently asynchronous. Events can occur
independently of the actions of the transport user. Signals can also interrupt the
blocking call.
XTI defines a set of asynchronous events in which the application would be
interested. The transport provider generates these events as a result of either protocol
messages received over the network or clearing of flow control conditions within the
transport provider. Refer to Chapter 4 for a detailed description of event handling.

1-2 Overview of the Transport Service Interface

1.2 Transport Provider
The transport provider is the transport protocol that provides the services of the
transport service interface. Each transport provider supports a set of default qualityof-service parameters. These parameters are negotiable on a per-connection basis for
connection-mode transport services and exchanged on a per-datagram basis for
connectionless-mode transport services. Refer to Chapter 4 for a description of the
transport provider's parameters.

1.3 Transport EndpOints
The file descriptor (transport endpoint) used by XTI is a UNIX file descriptor, which
can be manipulated by file system calls such as fork () , exec () , read () , and
write ().

1.4 Modes of Service
The transport service interface provides two modes of service: connection and
connectionless. Connection-mode is circuit-oriented and enables data to be
transmitted over an established connection in a reliable, sequenced manner. It also
provides an identification mechanism that avoids the overhead of address resolution
and transmission during the data transfer phase. This service is attractive for
applications that require relatively long-lived, data stream-oriented interactions.
In contrast, connectionless-mode is message-oriented and supports data transfer in
self-contained units with no logical relationships required among multiple units. This
service requires only a preexisting association between the peer users involved, which
determines the characteristics of the data to be transmitted. All the information
required to deliver a unit of data (for example, the destination address) is presented to
the transport provider, together with the data to be transmitted, in one service access
that need not relate to any other service access. Each unit of data transmitted is
entirely self-contained. Connectionless-mode service is attractive for applications
that:

1.4.1

•

Involve short-term request/response interactions

•

Exhibit a high level of redundancy

•

Are dynamically reconfigurable

•

Do not require guaranteed, in-sequence delivery of data

Connection-Mode Service
The connection-mode transport service is characterized by five phases:

•
•

Initialization

•

Data transfer

•

Connection release

•

Deinitialization

Connection establishment

Overview of the Transport Service Interface 1-3

1.4.1.1

Initialization - The initialization phase defines the local operation between a
transport user and transport provider. For example, a user must establish a
communication path to the transport provider, as illustrated in Figure 1-2. Each
communication path between a transport user and transport provider is a unique
endpoint of communication and is called the transport endpoint. The t _open ( )
function enables a user to choose a particular transport provider that will supply the
connection-mode services and establish the transport endpoint.

Figure 1-2: Communication Path Between Transport User and Provider
TRANSPORT USER
(Networking application or Session layer protocol)
~~

Service
Request

Communication
Path

.4~

Events

TRANSPORT SERVICE
INTERFACE

TRANSPORT PROVIDER
(TCP or UDP protocol)
ZK-0098U-R

Another necessary local function for each user is to establish an identity with the
transport provider. Each user is identified by a protocol address. A protocol address is
associated with each transport endpoint, and one user process can manage several
transport endpoints. In connection-mode service, one user requests a connection to
another user by specifying that user's address. The structure of a transport address is
defined by the address space of the transport provider. An address may be as simple
as a random character string or as complex as an encoded bit pattern that specifies all
information needed to route data through a network. Each transport provider defines
its own mechanism for identifying users. Addresses can be assigned to each transport
endpoint by t_bind () .
In addition to t open () and t bind () , several functions are available to support
local initialization. Table 1-1 summarizes all local initialization functions of the
transport service interface.

1-4 Overview of the Transport Service Interface

Table 1-1: Initialization Functions for Connection-Mode

1.4.1.2

Function

Description

CallocO

Allocates transport service interface.

CbindO

Binds a protocol address to a transport endpoint.

CerrorO

Prints a transport service interface error message.

CfreeO

Frees structures allocated using callocO.

t~etinfoO

Gets protocol-specific service information.

t~etstateO

Gets the current state of the transport endpoint.

t_IookO

Returns the current event on a transport endpoint.

CopenO

Establishes a transport endpoint connected to a
choosen transport provider.

CoptmgmtO

Negotiates protocol-specific options with the
transport provider.

CsyncO

Synchronizes a transport endpoint with the transport
provider.

Connection Establishment - The connection establishment phase enables two
transport users to create a connection (virtual circuit), between them, as illustrated in
Figure 1-3.

Figure 1-3: Connection Establishment
TRANSPORT USER 2
(Server)

TRANSPORT USER 1
(Client)

TRANSPORTSERVICE
INTERFACE

TRANSPORT CONNECTION
~------------------------------------

TRANSPORT PROVIDER

ZK-0100U-R

This phase is illustrated by a client-server relationship between two transport users.
One user, the server, typically advertises some service to a group of users and then
listens for requests from those users. As each client requires the service, it attempts to
connect itself to the server using the server's advertised transport address. The
t _connect () function initiates the connect request. One argument to

Overview of the Transport Service Interface 1-5

t _connect ( ) , the transport address, identifies the server that the client wishes to
access. The server is notified of each incoming request using t_listen () and may
call t_accept () to accept the client's request for access to the service. If the
request is accepted, the transport connection is established.
Table 1-2 summarizes all functions available for establishing a transport connection.

Table 1~2: Connection Establishment Functions

1.4.1.3

Function

Description

cacceptO

Accepts a request for a transport connection.

CconnectO

Establishes a connection with the transport user
at a specified destination.

ClistenO

Retrieves an indication of a connection request
from another transport user.

CrcvconnectO

Completes a connection establishment if CconnectO
was called in asynchronous mode. See Chapter 4.

Data Transfer - The data transfer phase enables users to transfer data in both
directions over an established connection. Two routines, t snd () and t rcv () ,
send and receive data over the connection. All data sent by-a user is guaranteed to be
delivered to the user on the other end of the connection, in the order in which it was
sent. Table 1-3 summarizes the connection mode data transfer functions.

Table 1-3: Data Transfer Functions for Connection-Mode

1.4.1.4

Function

Description

CsndO

Sends either normal or expedited data over a
transport connection.

CrcvO

Receives either normal or expedited data on a
transport connection.

Connection Release - The connection release phase terminates a given transport
connection in the connection-mode service. Two sets of calls are used, depending on
whether the release is abrupt (abortive) or orderly.
The t snddis () and t rcvdis () functions are used for the abortive release.
Because the abortive release does not coordinate between the peer transport
providers, data can be lost. The t_snddis () call rejects an incoming connection
request or ends a connection abruptly, depending on the state of the connection when
the call is made. The t rcvdis () call identifies the reason for the abortive release
of a connection, where the connection is released by the transport provider or another

1-6 Overview of the Transport Service Interface

transport user.
Orderly release of a transport connections is an optional feature for the TCP protocol.
Data from outstanding t snd () calls are transmitted and retransmitted, as flow
control permits, until all t snd () calls have been serviced.
The t_sndrel () and t_rcvrel () calls are used for the orderly release. The
t_sndrel () call can be issued by either transport user to initiate an orderly release
of a transport connection. This call indicates to the transport provider that the
transport user has no more data to send. The connection remains intact until both
users issue the t sndrel () function and t rcvrel () function. The
t _ rcvrel () function is issued when a userls notified of an orderly release request,
to inform the transport provider that the user is aware of the remote user's actions.

Table 1-4: Connection Release Functions

1.4.1.5

Function

Description

crcvdisO

Returns an indication of an aborted connection,
including a reason code and user data.

crcvrelO

Returns an indication that the remote user has
requested an orderly release of a connection.

csnddisO

Aborts a connection or rejects a connection
request.

CsndrelO

Requests the orderly release of a connection.

Deinitialization - The deinitialization phase provides local management of a
transport endpoint. It can involve one· or both of the following:
•

Disabling a transport endpoint from accepting any further requests

•

Informing the user that the transport provider is finished with the transport
endpoint

Issuing t_unbind () disables a transport endpoint so that no further request
destined for that endpoint will be accepted by the transport provider. In addition,
t_unbind () disables event generation and disassociates the endpoint from its
protocol address.
Issuing t c los e () informs the transport provider that the user is finished with the
transport endpoint and frees any local resources associated with that endpoint. Table
1-5 summarizes the deinitialization functions.

Overview of the Transport Service Interface 1-7

Table 1-5: Deinitialization Functions

1.4.2

Function

Description

cunbindO

No further data or events destined for this transport
endpoint will be accepted by the transport provider.

ccloseO

The transport provider is infonned that the user is
finished with the transport endpoint.

Connection less-Mode Service
The connectionless-mode transport service is characterized by three phases:

1.4.2.1

•

Initialization

•

Data transfer

•

Deinitialization.

Initialization - The initialization phase defines the local operation between a
transport user and transport provider. For example, a user must establish a
communication path to the transport provider, as illustrated in Figure 1-4. Each
communication path between a transport user and transport provider is a unique
endpoint of communication, and is called the transport endpoint. The t _open ( )
function enables a user to choose a particular transport provider that will supply the
connectionless-mode services and establish the transport endpoint.

Figure 1-4: Connectionless Communication Path
TRANSPORT USER

Transport Endpoint
(Communication Path)

_ _ _ _ _ _...._ _ _ _ _ _ TRANSPORTSERVICE
INTERFACE

TRANSPORT PROVIDER
ZK-0099U-R

Another necessary local function for each user is to establish an identity with the
transport provider. Each user is identified by a protocol address, which is associated
with each transport endpoint, and one user process can manage several transport
endpoints. In connectionless-mode service, in addition to the data sent by a user

1-8 Overview of the Transport Service Interface

process, each message contains a protocol address, making it possible to deliver the
message to the correct recipient and for the recipient to send a reply. Addresses can
be assigned to each transport endpoint by t_bind () .
In addition to t _open () and t _bind ( ) , several functions are available to support
local initialization. Table 1-6 summarizes all local initialization functions of the
transport service interface.

Table 1-6: Initialization Functions for Connectionless-Mode

1.4.2.2

Function

Description

callocO

Allocates transport service interface.

cbindO

Binds a protocol address to a transport endpoint.

cerrorO

Prints a transport service interface error message.

cfreeO

Frees structures allocated using callocO.

cgetinfoO

Gets protocol-specific service information.

cgetstateO

Gets the current state of the transport endpoint.

ClookO

Returns the current event on a transport endpoint.

copenO

Establishes a transport endpoint connected to a
chosen transport provider.

CoptmgmtO'

Negotiates protocol-specific options with the
transport provider.

csyncO

Synchronizes a transport endpoint with the transport
provider.

Data Transfer - The data transfer phase enables a user to transfer data units,
sometimes called datagrams, to the specified peer user. Each data unit must be
accompanied by the transport address of the destination user. Two functions,
t_sndudata () and t_rcvudata () support this message-based data transfer
facility. Table 1-7 summarizes all functions associated with connectionless-mode data
transfer.
Table 1-7: Data Transfer Functions for Connectionless-Mode
Command

Description

crcvudataO

Retrieves a message sent by another transport user.

crcvuderrO

Retrieves error information associated with a previously
sent message.

csndudataO

Sends a message to the specified destination user.

Overview of the Transport Service Interface 1-9

1.4.2.3

Deinitialization - The deinitialization phase provides local management of a
transport endpoint. It may involve one or both of the following:
•

Disabling a transport endpoint from accepting any further requests

•

Informing the user that the transport provider is finished with the transport
endpoint

Issuing t _unbind () disables a transport endpoint such that no further request
destined for the given endpoint will be accepted by the transport provider. In
addition, t_unbind () disables event generation and disassociates the endpoint
from its protocol address.
Issuing t _ c los e () informs the transport provider that the user is finished with the
transport endpoint and frees any local resources associated with that endpoint. Table
1-8 summarizes the deinitialization functions.

Table 1·8: Deinitialization Functions for Connectionless-Mode
Function

Description

cunbindO

No further data or events destined for this transport
endpoint will be accepted by the transport provider.

ccloseO

The transport provider is informed that the user is
finished with the transport endpoint.

1.5 State Transitions
The transport service interface has two components:
•

The library functions that provide the transport services to users

•

The state transition rules that define the sequence in which the transport
functions may be involved

The state transition rules are presented in Appendix A of this guide in the form of
state tables. The state tables define the legal sequence of library calls based on state
information and the handling of events. These events include user-generated library
calls as well as provider-generated event indications.

Note
Before writing software programs using the transport service interface,
the user needs to understand all the possible state transitions.

1-10 Overview of the Transport Service Interface

Connection-Mode Service

This chapter describes the connection-mode service of the transport service interface.
As described in Section 1.4.1.2, the connection-mode service can be illustrated using
a client-server paradigm.

2.1

Connection-Mode Programming Examples
The important concepts of connection-mode are described in this chapter with two
programming examples: client and server. The client example illustrates how a client
establishes a connection to a server and then communicates with the server. The other
example illustrates the server's side of the interaction. The two examples discussed in
this chapter are presented in their entirety in Appendix D.

2.2 Connection-Mode Initialization
Before the client and server (transport users) can establish a transport connection,
each must first establish a communication path to the transport provider. A transport
endpoint specifies a communication path between a transport user and a specific
transport provider. A local file descriptor identifies a specific transport provider. To
activate a transport endpoint, a protocol address must be associated with an endpoint.
The t open () function is used to create a transport endpoint and returns protocolspecific infonnation associated with that endpoint. A file descriptor is returned as the
local identifier of the transport endpoint.
A successful t open () returns a file descriptor and the default characteristics of the
underlying transport protocol are returned in the info parameter. This infonnation
differs across transport providers. Refer to Chapter 4 for a description of what
infonnation is returned by which transport provider. This information is returned to
the user by t _open () and consists of the following:
addr
Maximum size of a transport address
options
Maximum bytes of protocol-specific options that can be passed between the
transport user and transport provider
tsdu
Maximum message size that can be transmitted in either connection-mode or
connectionless-mode
etsdu
Maximum expedited data message size that can be sent over a transport
connection

connect
Maximum number of bytes of user data that can be passed between users during
connection establishment
discon
Maximum number of user data that can be passed between users during the
abortive release of a connection
servtype
Type of service supported by the transport provider

One of the following service types is returned:
T_COTS
The transport provider supports connection-mode service but does not provide
the optional orderly release facility.
T_COTS_ORD
The transport provider supports connection-mode service with the optional
orderly release facility.
T_CLTS
The transport provider supports connectionless-mode service.
Only one of the services can be associated with the transport provider identified by
t_open ().
Note
Some characteristics returned by t _open () can change after an
endpoint has been opened. This occurs if the characteristics are
associated with negotiated options, described later in this section.
After a user establishes a transport endpoint with the chosen transport provider, a
protocol address must be associated with a given transport, thereby activating the
endpoint. This association is done with t bind () , which binds a protocol address
to the transport provider. In addition, forservers, this association directs the
transport provider to begin accepting connect indications, if desired.
Depending upon the transport provider, t_bind () can allow more than one
transport endpoint to be bound to the same protocol address but disallows more than
one protocol address to be bound to the same transport endpoint. If the application
requests the binding of more than one transport endpoint to the same protocol
address, only one transport endpoint can be used to listen for connect indications
associated with that protocol address.
An optional facility, t _ optmgmt ( ) , is available during the local initialization
phase. The t optmgmt () function enables a user to negotiate the values of
protocol options with the transport provider. Each transport protocol is expected to
define its own set of negotiable protocol options, which can include such information
as quality-of-service parameters. Because of the protocol-specific nature of options,
only applications written for a particular protocol environment are expected to use
this facility.

2-2 Connection-Mode Service

2.2.1

The Client
Example 2-1 illustrates the steps necessary to initialize the client. A discussion of
the client initialize phase follows this example segment.
Example 2-1: Initialize Phase of the Client (Connection Mode)
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include

extern int errno;
int net;
struct t_info t_open_info;
/* transport char. from transport */
struct t_info t_getinfo_info;
struct tcp_options tcp_optSi
struct t_optmgmt t_optm_req;
struct t_optmgmt t_optm_reti
struct sockaddr_in sin;
struct
servent *sp;
char *hostname;
struct hostent *host;
#define MAXDSIZE 512
char snd_buf[MAXDSIZE];
char rcv_buf[MAXDSIZE];
int ni
int status;
struct t_call t_conn_sndcall;
struct t call t_conn_rcvcall;
struct t_call t_rcvconn_call;
struct t_discon discon;
int t_rcv_flags;
main (argc, argv)
int argc;
char *argv[];

char destin[255];
if «net = t open ("tcp", 0 RDWRIO NONBLOCK, &t_open_info)) < 0)
t_error ("<=open failed") -;
~
exit(t_errno);

{

III

status = t_getinfo(net, &t_getinfo_info);

/*
* t_bind - bind an address to a transport endpoint

*/
if (t_bind(net, 0, 0) < 0) {
~
t_error (" iexample: t bind error");

Connection-Mode Service 2-3

Example 2-1:

(continued)

exit(l) ;

t_optm_req.opt.len = 0;
t_optm_req.flags = T_DEFAULTi
t_optm_ret.opt.maxlen = sizeof(struct tcp_options);
t_optm_ret.opt.buf = (char *) &tcp_opts;
status = t optmgmt(net, &t optm req, &t optm ret);
if (status-< 0) {
-t_error("iexample: t_optmgmt error");
exit (1) ;

printf("host :");
scanf("%s",destin);
host = gethostbyname(destin);
if (host) {
sin. sin_family = host->h_addrtype;
bcopy(host->h_addr, (caddr_t)&sin.sin_addr, host->h_length);
hostname = host->h_name;

III

The first argument to t _open ( ) , tcp, identifies the transport provider as tcp.
In this example, the transport protocol is identified by name (tcp). It is opened
for both reading and writing, as specified by the _RDWR open. The
O_RDWR flag is ORed with the O_NONBLOCK flag, which specifies
nonblocking operation (asynchronous mode). The asynchronous mode means
that if the requested operation t _open () cannot be completed, the
t _open () call returns -1 immediately and t_ errno is set to a specific value.
The third argument, &t open info, returns various default characteristics of the
underlying transport protocolby setting fields in the t open info structure.
This argument, t_open_info, points to the t_open_info structure, which
contains the following members:

long addr
/* max size of the transport protocol address */
long options
/* max number of bytes of protocol-specific options */
long tsdu
/* max size of a transport service data unit (TSDU) */
long etsdu
/* max size of expedited transport service data unit (ETSDUO) */
long discon
/* max amount of data allowed on t snddis () and t_rcvdis ()
functions */
long sertype
/*service type supported by thje transport provider */
Refer to the t _open () reference pages for a description of the members of the
t_open_info structure.

2-4 Connection-Mode Service

As mentioned before, the third argument of the t _open () call can be used to return
to the user the service characteristics of the transport provider. This information is
useful when writing protocol-independent software, which is discussed in Appendix
B. If the user did not need to know the transport characteristics, NULL would be
specified for the third argument in the t_open call.

[2]

After opening the transport service, the t_getinfo () call gets protocolspecific service information, which is redundant to what was done with the
third argument of the t open () call. (The t get info () call was added
for illustrative purposesonly.) Another alternative would have been to NULL
the third argument of the t open () call and use the t get info () to
obtain the protocol-specificservice information.
-

The return value of the t _ open () call is a file descriptor obtained by opening the
transport protocol file. This file descriptor is an identifier that is used by all
subsequent transport service interface calls.

[aJ

After creating the transport endpoint, the client calls t bind () to assign an
address to it. The first argument (net) identifies the transport endpoint. The
second argument describes the address the user would like to bind to the
endpoint, and the third argument is set on return from t bind () to specify
the address that the provider bound.
-

To access a server, clients use the address associated with the server's transport
endpoint. Typically, the client does not care about its own address because no other
process tries to access it. This is illustrated in the example, where the second and
third arguments to t bin d () are set to NULL. A NULL second argument means
that the transport provider assigns an appropriate address to be bound; in other words,
the address chosen for the user. A NULL third argument indicates that the user does
not care what address is assigned to the endpoint.

2.2.2

If either t open () or t bind () fail, the program calls terror () to
send an appropriate error message to stderr. If any transport service
interface routine fails, the global integer t errno is assigned an appropriate
transport error value. A set of such error values has been defined (in
<xti. h» for the transport service interface, and t errno prints an error
message corresponding to the value in t_errno. If the error associated with a
transport function is a system error, t errno is set to TSYSERR, and errno is
set to the appropriate value.
-

[5J

The example also illustrates the use of the optional facility, t _ optmgmt ( ) ,
which enables a user to negotiate the values of protocol options with the
transport provider. Each transport protocol defines its own set of negotiable
protocol options, which can include such information as quality-of-service
parameters. Because t _ optmgmt () is protocol-specific, only applications
written for a specific protocol environment are expected to use this facility.

The Server
The server in this example must perform local initialization steps similarly to the
client before communications can begin. The server must establish a transport
endpoint through which it listens for connect indications. The necessary initialization
steps are shown in Example 2-2. A discussion of the server initialization phase
follows this example segment.

Connection-Mode Service 2-5

Example 2-2: Initialize Phase for the Server (Connection Mode)
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/wait.h>
#include <sys/file.h>
#include <netinet/in.h>
#include <stdio.h>
#include <signal.h>
#include <errno.h>
#include <sgtty.h>
#include <netdb.h>
#include <syslog.h>
#include <xti.h>
int net,netl,n,nl;
extern
int errno;
main (argc, argv)
char *argv[];
int fromlen;
struct sockaddr_in from;
int status;
status = get_income();
if (status != 0)
exit(l);
else {
sleep(lO);
exit(O);
}

int
get_income ()
{

struct sockaddr in sname;
struct servent *sp;
int i;
int child;
struct t - call t_list_call;
struct t - call *t_listJ>tr;
struct t - call t_snddis_call;
struct t bind t_bind_addr_req;
struct t bind t_bind_addr_reql;
struct t bind t bind addr ret;
struct t - info t=open=info;
/* transport char. from transport
int t - status;

/*
* Call t_open - establish a transport endpoint

*/
if ((net

2-6 Connection-Mode Service

Example 2-2:

(continued)

t error ("rexample: t_open error");
e~it(l);

* t bind - bind an address to a transport endpoint
*

sname.sin-port
200;
sname.sin_family = AF_INET;
sname.sin_addr.s_addr = 0;

/* load port # */

t_bind_addr_req.addr.len = sizeof (struct sockaddr_in);
t_bind_addr_req.addr.buf = (char *) &sname;
t_bind_addr_req.qlen = 1;
t_bind_addr_ret.addr.maxlen = sizeof (struct sockaddr_in);
t_bind_addr_ret.addr.buf = (char *) &sname;

if «t_bind(net, &t_bind_addr_req, &t_bind_addr_ret»
t_error("rexample: t_bind error");
exit(l);

< 0)

{

t_list-ptr = (struct t_call *) t_alloc(net, T_CALL_STR, T_ADDR);
bcopy(&sname, t_list-ptr->addr.buf, t_list-ptr->addr.maxlen);

if (t_status < 0) {
if (t_errno != TNODATA)
t_error("rexample: t listen error");
t_unbind(net);
t_close(net);
exit(l) ;

printf("Have a incomming connection with sequence # %d\n",
t_list-ptr->sequence);
printf("attempting to accept sequence # %d\n",
t_list-ptr->sequence);
net1 = get_endpoint();
if (t_status = t_accept(net,net1,t_list-ptr) < 0)
t_error("rexample: t_accept error");
if (t errno == TLOOK) {
pri~tf("event %x came in\n",t_look(net1»;

{

exit(l);

fcntl(net1,F_SETOWN, getpid(»;
child = fork();
if (child == 0)
t_unbind(net);
t_close(net);
t_sync(net1);
doit(net1, t_list-ptr->sequence);

Connection-Mode Service 2-7

Example 2-2:

(continued)

else
{

printf("Forking Child process =%d for fd
child,netl, t_list-ptr->sequence);
t_unbind (netl) ;
t_close(netl);
t_free(t_list-ptr, T_CALL_STR);

%d seq=%d\n",

return(O);

int
get_endpoint ()
{

struct sockaddr in sname;
struct servent *sp;
int tmp_net;
struct
struct
struct
struct
struct

t - call t - list - call;
t _bind t _bind_addr_req;
t bind t _bind_addr_reql;
t _bind t _bind_addr - ret;
t - info t _open_ info;
/* transport char. from transport */

/*
* Call t_open

establish a transport endpoint

if ((tmp_net = t_open ("tcp", O_RDWR, &t_open_info)) < 0)
t_error("rexample: t_open error");
exit (1) ;

{

/*
* t bind - bind an address to a transport endpoint

*/
sname.sin-port = 0;
sname.sin_family = AF_INET;
sname.sin_addr.s_addr = 0;

t_bind_addr_req.addr.len = sizeof (struct sockaddr_in);
t_bind_addr_req.addr.buf = (char *) &sname;
t_bind_addr_req.qlen = 0;
t_bind_addr_ret.addr.maxlen = sizeof (struct sockaddr_in);
t_bind_addr_ret.addr.buf = (char *) &sname;
if ((t_bind(tmp_net, &t_bind_addr_req, &t_bind_addr_ret)) < 0)
t_error("rexample: t_bind error");
exit(l);

{

return(tmp_net);

I1J

Like the client, the first step is to call t _open () to establish a transport
endpoint with the desired transport provider. Refer to the

2-8 Connection-Mode Service

get_incomeroutine in the example for this discussion. This endpoint, net,
is used to listen for connection requests from the clients.

l2l

Next, the server must bind its address, which is well-known to the clients, to
the endpoint. Each client uses this address to access the server. The second
argument to t_bind () ,&t_bind_addr_req, t_bind () requests that a
particular address be bound to the transport endpoint. This argument points to a
t_bind structure with the following format:
struct t_bind {
struct netbuf addr;
unsigned qlen;

The members have the following meanings:
addr
Address to be bound
qlen
Maximum outstanding connect indications that can arrive at this endpoint

Note
All transport service interface structure and constant definitions are
located in <xt i . h>.

A netbuf structure specifies the address, which consists of the following members:
struct netbuf {
unsigned int maxlen;
unsigned int len;
char *bufi

These members have the following meaning:

but
Points to a buffer containing data which identifies a transport address.
len
Specifies the bytes of data in the buffer.
maxlen
Indicates the maximum bytes the buffer can hold (set only to return data to the
user by the transport service interface routine).
The structure of addresses varies among each protocol implementation under the
transport service interface. The netbuf structure should be able to support any
variations.
The qlen value specifies the number of outstanding connect indications the transport
provider should support for the given transport endpoint. An outstanding connect
indication is one that has been passed to the transport user by the transport provider
but which has not been accepted or rejected. In the example, qlen (value of 1) is
greater than 0, which means the transport endpoint can be used to listen for connect
indications. The t _bind () call directs the transport provider to immediately begin
queueing connect indications destined for the bound address. Furthermore, the qlen
value specifies the maximum outstanding connect indications the server can process.

Connection-Mode Service 2-9

The server must respond to each connect request, either accepting or rejecting the
request for connection.

IaJ

The t_alloc () call is called to allocate memory for the needed t_bind
structure to hold the correct address. The t alloc () function takes three
arguments:fd (net, struct type), (T CALL STR), andfields (T ADDR). The
first argument, net, which-is a file descriptor, references a transport endpoint. It
is used to access the characteristics of the transport provider. The second
argument, struct_type, identifies the appropriate transport service interface
structure to be allocated. The third argument,fields, specifies which netbuf
buffers should be allocated for that structure. The size of this buffer is
determined from the transport provider characteristics that define the maximum
address size. The t alloc () call sets the maxlen field of this netbuf
structure to the size-of the newly allocated buffer.

In this example, because qlen is set to 1, the server processes connect indications one
at a time. The address information is assigned to the newly allocated t bind
structure. The t_bind structure is used to pass information to t_bind () in the
second argument and also is used to return information to the user in the third
argument.
On return, the t _ bin d structure contains the address that was bound to the transport
endpoint. Should the transport provider not be able to bind the requested address (for
example, it can already be bound), another appropriate address would be chosen.
The server checks the bound address to ensure that it is the one previously advertised
to clients. Otherwise, the clients are unable to reach the server.
If t_bind () is successful, the transport provider begins queueing connect
indications. The next phase of communication, connection establishment, is entered.

2.3 Connection Establishment
The connection establishment procedures emphasize the difference between clients
and servers. The transport service interface imposes a different set of procedures in
this phase for each type of transport user. The client uses t _connect () to initiate
the connection establishment procedure by requesting a connection to a particular
server. The server is then notified of the client's request by calling t listen () .
The server can either accept the client's request by calling t_accept () to establish
the connection, or calling t _ snddis () to reject the client's request. The server
notifies the client of the decision to accept or reject the connection when
t_connect () completes.
The transport service interface supports two facilities during connection establishment
that may not be supported by all transport providers. The first is the ability to transfer
data between the client and server when establishing the connection. The client can
send data to the server when it requests a connection. This data is passed to the
server by t_Iisten (). Similarly, the server can send data to the client when it
accepts or rejects the connection. The connect characteristic returned by t _open ( )
determines how much data, if any, two users can transfer during connect
establishment.
The second optional service supported by the transport service interface during
connection establishment is the negotiation of protocol options. The client can
specify protocol options that it would like the transport provider or the remote user to
use. The transport service interface supports both local and remote option negotiation.

2-10 Connection-Mode Service

As discussed earilier, option negotiation is inherently a protocol-specific function.
Use of this facility is discouraged if protocol-independent software is a goal (Refer to
Appendix B).

2.3.1

The Client
Continuing with the connection-mode example, the steps needed by the client to
establish a connection are shown in Example 2-3. The example segment is followed
by a discussion of the steps.

Example 2·3: Connection Phase for the Client (Connection Mode)
printf("host :");
scanf("%s",destin);
host = gethostbyname(destin);
if (host) {
sin. sin_family = host->h_addrtype;
bcopy(host->h_addr, (caddr_t)&sin.sin_addr, host->h_length);
hostname = host->h_name;

sin.sin-port = 200; /* try to connect to port 200 */
t_conn_sndcall.addr.len = sizeof (struct sockaddr_in);
t_conn_sndcall.addr.buf = (char *) &sin;
t_conn_sndcall.opt.len = 0;
t_conn_sndcall.udata.len = 0;
t conn rcvcall.addr.maxlen = sizeof (struct sockaddr in);
t-conn-rcvcall.addr.buf = (char *) &sin;
t=conn=rcvcall.opt.maxlen = sizeof(struct tcp_options);
t_conn_rcvcall.opt.buf = (char *) &tcp_opts;
t conn rcvcall.udata.maxlen = 0;
t=rcvconn_call.addr.maxlen = sizeof (struct sockaddr_in);
t rcvconn call.addr.buf = (char *) &sin;
t=rcvconn=call.opt.maxlen = sizeof(struct tcp_options);
t_rcvconn_call.opt.buf = (char *) &tcp_opts;
t_rcvconn_call.udata.maxlen = 0;
t rcvconn call.udata.buf = 0;
if ((t_co~nect(net, &t_conn_sndcall, &t_conn_rcvcall»
< 0)
if (t_errno == TNODATA) {
while (1) {
status = t_rcvconnect(net, &t_rcvconn_call);

{

if (status < 0) {
if (t_errno == TLOOK)
printf("Event %x came in\n",t_look(net»;
(void) t unbind(net);
(void) t=close(net);
exit(l);
if (t_errno != TNODATA) {
t_error ("iexample: t_rcvconnect ()");
(void) t_unbind(net);
(void) t_close(net);
exit(l);

else
break;
}

else {

Connection-Mode Service 2-11

Example 2-3:

(continued)

t_error (fliexample: t_connect () fI);
(void) t_unbind(net);
(void) t_close(net);
exit(l);

ff]

The t connect () call establishes the connection with the server. The first
argument, net, identifies the transport provider through which the connection is
established. The second argument, t conn sndcall, identifies the destination
server by containing the address of a t c~11 structure, which has the
following members:
struct t_call {
struct netbuf addr;
struct netbuf opt;
struct netbuf udatai
int sequence;

The members have the following meanings:
addr

Specifies the protocol address of the destination transport user.
opt

Presents any protocol-specific infonnation that may be needed by the
transport provider.
udata

Points to optional user data that can be passed to the destination
transport user during connection establishment.
sequence
Has no meaning for this function.

It should be noted that the t conn sndcall.opt.len argument in this example is set to
zero. This argument definesthe options, which are specific to the underlying
protocol, that are passed to the transport provider. By setting this argument to zero,
the user has chosen to use the default options.
The t conn sndcal!.udata.len argument has also been set to zero in our example.
This argument enables the caller to pass user data to the destination transport; but, by
specifying a value of zero, no data is sent to the destination transport user.
The third argument (t conn reveal!) can be used to return infonnation about the
newly established connection to the user, and can retrieve any user data sent by the
server in its response to the connect request. The t_conn_reveal! argument points to a
t _ c a 11 structure. The members of the t _ c a 11 structure have the following
meanings:
addr

Returns the protocol address associated with the responding transport endpoint.
opt

Presents any protocol-specific infonnation associated with the connection.
udata

Points to optional user that can be returned during connection establishment.
2-12 Connection-Mode Service

sequence
Has no meaining for this function.
On return, the addr, opt, and udata fields of t_conn_rcvcall are updated to reflect
values associated with connection. Thus, the maxlen field of each argument must be
set before issuing t _connect () to indicate the maximum size of the buffer for
each. However, if t conn rcvcall had been set to NULL, than no information is
returned to the user-from the t_connect () .

121

The t rcvconnect () call confirms the connection to the server
(asynchronous mode only). The first argument, net, identifies the local transport
endpoint where communication has been established. The second argument,
t_rcvconn_call, points to a t_call structure that contains information about
the newly established connection.
In our example, the t_rcvconnect () call is operating in asynchronous mode
because the O_NONBLOCK flag was specified in the t _open () call. This
means that t_rcvconnect () is reduced to a poll for an existing connect
confirmation. If there is no connect confirmation, t rcvconnect () fails and
returns immediately, without waiting for the connection to be established. The
t _ rcvconnect () call must be reissued at a later time to complete the
connection establishment phase and retrieve the information returned to the call.

As shown in the state tables of Appendix A, it is possible in some states to receive
one of several asynchronous events. The t look () routine enables a user to
determine what event has occured if a TLOOK error is returned. The user can then
process that event accordingly. In the example, if a connect request is rejected, the
event passed to the client is a disconnect indication. The client exits if its request is
rejected.

2.3.2

The Server
Continuing with the server example, when the client calls t _connect ( ) , a connect
indication is generated on the server's listening endpoint. For each client, the server
accepts the connect request and spawns a server process to manage the connection.
Example 2-4 shows the required steps by the server to establish a connection and it is
followed by a discussion of the steps.

Example 2·4: Connection Phase for the Server (Connection Mode)
t_list-ptr = (struct t_call *) t_alloc(net, T_CALL_STR, T_ADDR);
bcopy(&sname, t_list-ptr->addr.buf, t_list-ptr->addr.maxlen);

if (t_status < 0) {
if (t_errno != TNODATA) {
t_error("rexample: t listen error");
t_unbind(net);
t_close(net);
exit(l);

printf("Have an incomming connection with sequence
t_list-ptr->sequence);
printf("attempting to accept sequence 41= %d\n",

41=

%d\n" ,

Connection-Mode Service 2-13

Example 2-4:

(continued)

t_Iist-ptr->sequence);
netl = get_endpoint();
if (t_status = t_accept(net,netl,t_list-ptr) < 0)
t_error("rexample: t_accept error");
if (t_errno == TLOOK) {
printf("event %x came in\n",t_Iook(netl»;

{

exit (1) ;

fcntl(netl,F_SETOWN, getpid(»;
child = fork();
if (child == 0)
t_unbind(net);
t_close(net);
~
t_sync(netl);
blJ
doit(netl, t_Iist-ptr->sequence);
else
{

printf("Forking Child process =%d for fd
child,netl, t_list-ptr->sequence);
t_unbind(netl);
t_close(netl);
t_free(t_Iist-ptr, T_CALL_STR);

%d seq=%d\n",

return(O);

int
get_endpoint ()
{

struct sockaddr_in sname;
struct servent *sp;
int tmp_net;
struct t call t_Iist_call;
struct t bind t_bind_addr_req;
struct t bind t bind addr reql;
struct t-bind t-bind-addr-ret;
struct t info t=open=info;
1* transport char. from transport
int t_status;

1*
* Call t_open - establish a transport endpoint

*1
if «tmp_net = t_open ("tcp", O_RDWR, &t_open_info»
t_error("rexample: t_open error");
exit(l) ;

1*
* t_bind - bind an address to a transport endpoint

*1
sname.sin-port
sname.sin_family

2-14 Connection-Mode Service

< 0) {

Example 2-4:

(continued)

t_bind_addr_req.addr.len = sizeof (struct sockaddr_in);
t_bind_addr_req.addr.buf = (char *) &sname;
t_bind_addr_req.qlen = 0;
t_bind_addr_ret.addr.maxlen = sizeof (struct sockaddr_in);
t_bind_addr_ret.addr.buf = (char *) &sname;
if «t_bind(tmp_net, &t_bind_addr_req, &t_bind_addr_ret)) < 0)
t_error("rexample: t_bind error");
exit(l);

{

return(tmp_net);

ill

The server loops to process each connect indication. First, the server calls
t 1 i s ten () to retrieve the next connect indication. When a connect
indication arrives, the server calls t_accept () to accept the connect request.
The first argument, net, of t accept () identifies the local transport endpoint
where the connect indication-arrived. The second argument, net1, is used for
the local transport endpoint that establishes the connection. Because the
connection is accepted on an alternate endpoint, the server can continue to
listen for connect indications on the endpoint that was bound for listening. If
the call is accepted without error, a process is spawned to manage the
connection.

As mentioned before, a different transport endpoint, net1, is used for a connection
than the transport endpoint, net, that is used to receive the connection indication.
Before t_accept () can be issued, the endpoint, net1, must be bound to a protocol
address and must be in the T_IDLE state. Refer to the get endpoint () function
in the example for the procedure on binding the protocol address.
The third argument, t_listytr, points to a t_call structure that contains
information required by the transport provider to complete the connection. The
members of the t_call structure have the following meanings:
addr

Specifies the address of the caller.
opt

Indicates any protocol-specific parameters associated with the connection.
udata

Points to any data to be returned to the call.
Sequence
Is the value returned by t listen () that uniquely associates the response
with a previously received-connect indication.

121

The t alloc () function is called so that the server can allocate a t call
structure to be used by t_listen (). The first argument, net, refersto the
transport endpoint that is used to allocate the new structure. The second
argument (T_CALL_STR) specifies that the allocated structure that is of type
t_call and third argument, T_ADDR, specifies which buffers are to be
allocated. The t a l l 0 c () call must allocate a buffer large enough to store
the address of the caller. The buffer size is determined from the addr

Connection-Mode Service 2-15

characteristics returned by t open ( ) . The maxlen field of each netbuf
structure is set by t alloe() to the size of the newly allocated buffer.

131

In the example, the t_syne () function is called to synchronize the internal
tables. This function converts an uninitialized file descriptor to an initialized
transport endpoint by updating the necessary library data structures.

2.4 Data Transfer
Once the connection has been established, the transport server interface does not
differentiate between the client and the server. Either the client or server can begin
transferring data over the connection using t snd () or t rev (). Not only can
either user send or receive data, but either can also release the connection when
appropriate. The transport service interface guarantees reliable, sequenced delivery of
data over an existing connection.
Using the TCP protocol, the transport service interface supports the exchange of both
normal and expedited data over a transport connection. Expedited data is typically
associated with information of an urgent nature. The urgent nature is often indicated
by one byte in the data stream. Most TCP applications are expected to discard all
data up to the urgent data when the urgent signal is received. It should be noted that
the exact semantics of expedited data are subject to the interpretation of the transport
provider.
The TCP transport provider allows the user to specify an urgent condition at any
point in the normal data stream. Several such indications can be combined, with only
the last one shown to the destination. There is no limit to the number of urgent
indications that can be sent. However, the user must send at least one data octet with
each urgent indication. Current TCP implementation supports sending up to the
maximum segment size of urgent data, but retrieval of only one byte of urgent data.
If several urgent data are received, only the outstanding urgent data is reported.

Note
The user must set the T_MORE flag (t snd () ) to send multiple units
over a transport connection, whereas theT _MORE flag is automatically
set to receive ( t_rev () ) a message in multiple units. The TCP
transport provider ignores the T_MORE flag.

2.4.1

The Client
Example 2-5 shows how the client can transfer data to or from the server. A
discussion of client data transfer follows this example segment.

Example 2-5: Data Transfer for the Client (Connection Mode)
printf("calling t_snd with %d bytes of regular data\n~sizeof(snd_buf));
n = t_snd(net, &snd_buf[O],sizeof(snd_buf) , 0);
dU
if (n < 0) {
if (t errno == TLOOK) {
printf(nGenerated a %X TLOOK error\n",t_look(net));
(void) t_unbind(net);
(void) t_close(net);
exit(l);

2-16 Connection-Mode Service

Example 2-5:

(continued)

t_error(IIiexample: t_snd error");
(void) t_unbind(net);
(void) t_close(net);
exit(l);
printf(IIt_snd sent %d bytes\n",n);
while (1) {
n = t_rcv(net, rcv_buf, sizeof(rcv_buf), &t_rcv_flags);

< 0)

{

if (t_errno != TNODATA)
t_error(IIiexample: t_rcverror");
(void) t_unbind(net);
(void) t_close(net);
exit (1);
}

else {
t_error(IIiexample: NO data available");
}

}

if (n > 0) break;

printf(IIt_rcv received %d bytes\n",n);
if (t_rcv_flags & T_EXPEDITED)
printf("data is expedited\n");
else
printf ("data is normal \n ") ;
n = t_sndrel (net,

(struct t

call *)

0);

if (n < 0) {
t_error(IIiexample: error in t_sndrel:");
t_unbind(net);
t_close(net);
exit(l);

[1]

The client calls t snd () to send data to the server. The first argument, net,
identifies the localtransport endpoint over which the data is to be sent. The
second argument, &snd builD], points to the user data to be sent, while the
third argument, sizeoi(snd bui), specifies the number of bytes to be sent. The
fourth argument is used for optional flags. In the example, the argument D
means no flags are set. The optional flags could have been either
T EXPEDITED or T MORE. The T EXPEDITED flag specifies the data to be
expedited, while a T~MORE flag is Ignored by the TCP transport provider.

I2l

The client continuously calls t rev () to process incoming data. Because
t rev () is operating in the asynchronous mode in the example, if there is no
data, t rev () fails. The first argument net identifies the local
transport endpoint through which data arrives. The second argument, rev_ buf,
points to the buffer where the user data is placed. The third argument,
sizeoi(rev bui), specifies the size of the receive buffer in bytes.

Connection-Mode Service 2-17

2.4.2

The Server
Example 2-6 shows how the server can transfer data to and from the client. The
server data transfer is discussed following this example segment.
Example 2-6: Data Transfer for Server (Connection Mode)
doit(f, seq)
int f,seq;
int t_rcv_flags;
struct hostent *hp;
char rcv_buf[S12];
char snd_buf[S12];
int n;

while (1) {
n = t rcv(f,rcv_buf, sizeof(rcv_buf)

,&t_rcv_flags);

if (n < 0) {
if (t_errno != TNODATA)
t_error(IIrexample: t rcv error");
t_unbind(f) ;
t_close (f) ;
exit(l);
}

else {
t_error(IIrexample: NO data available");
}

if (n > 0) break;

printf(IIt_rcv received %d bytes\n",n);
if (t_rcv_flags & T EXPEDITED)
printf ("data is eipedited\n");
else
printf("data is normal\n");
printf("calling t_snd with %d bytes of regular data\n",sizeof(snd_buf));
n = t_snd(f, &snd_buf[O],sizeof(snd_buf) , 0);
if (n < 0) {
if (t_errno == TLOOK) {
printf("Generated a %X TLOOK error\n",t_look(f));
(void) t_unbind(f);
(void) t_close(f);
exit(l);
t_error(IIrexample: t
(void) t_unbind(f);
(void) t_close(f);
exit(l);

snd error");

printf(IIt_snd sent %d bytes\n",n);

As mentioned before, when the connection has been established, the transport service
interface does not differentiate between the client and the server. As the following
description shows, the server description is very similar to the client description.

2-18 Connection-Mode Service

[1]

The server calls t _rev () to receive data or expedited data over the
connection. The first argument, f, of t _rev () identifies the local transport
endpoint through which data arrives. The second argument, rev_buj, points to
the buffer where the user data is placed, while the third argument,
sizeojd(rev_buf, specifies the size of the receive buffer. The fourth argument,
&t_revJf,ags, points to the optional flags. The example checks for expedited
data; if there is expedited data, the message "data is expedited" is printed.

2.5 Connection Release
At any point during data transfer, either user can release the transport connection and
end the data exchange between the two users. The transport service interface
supports two kinds of connection release:
•

Abortive release

•

Orderly release

The abortive release breaks a connection immediately and can result in the loss of
any data that has not yet reached the destination user. To generate an abortive release,
either user calls t snddis (). In addition, the transport provider can abort a
connection if a problem occurs below the transport service interface. A user can use
t snddis () to send data to the remote user when aborting a connection. Although
the abortive release is supported by all transport providers, the ability to send data
when aborting a connection is not.
When the remote user is notified of the aborted connection, t revdis () must be
called to retrieve the disconnect indication. This call returns reason code that
indicates the connection was aborted, and returns any user data that may have
accompanied the disconnect indication (if the abortive release was initiated by the
remote user). This reason code is specific to the underlying transport protocol and
should not be interpreted by protocol-independent software.

The orderly release gracefully terminates a connection and guarantees that no data is
lost. Orderly release is an optional facility that is supported by the TCP transport
provider.

2.5.1

The Client
If the server releases the connection by issuing t _ sndre 1 ( ) , t _ rev () fails and
sets t errno () to TLOOK. The client then processes the connection release as
shownin Example 2-7.

Example 2-7: Connection Release for the Client (Connection Mode)
n

= t_sndrel (net,

(struct t_call *) 0);

if (n < 0) {
t_error("iexample: error in t_sndrel:");
t_unbind(net);
t_close(net);
exit(1);

while (1)

{

Connection-Mode Service 2-19

Example 2·7:

(continued)

n = t_rcvrel(net);

if (n < 0) {
if (t_errno != TLOOK && t_errno != TNOREL)
t_error(niexample: error in t_rcvrel: n );
t_unbind(net);
t_close(net);
exit(l);
}

else {
if (t_errno == TNOREL)
t_error(niexample: NO T_ORDREL available");
else {
t error (niexample: TLOOK event n );
t=unbind(net);
t_close(net);
exit(l);
}
}

if (n == 0) break;
t_unbind(net);
t_close(net);
exit(O);

~
131

Under normal circumstances, the client terminates the transfer of data by
calling t sndrel () to initiate the connection release. When the orderly
release indication arrives at the client's side of the connection, the client checks
to make sure the expected orderly release indication has arrived. If so, it
proceeds with the release procedures by calling t_rcvrel () to process the
indication and t_sndrel () to inform the server that it is also ready to
release the connection. At this point the client exits, thereby closing its
transport endpoint.

[2]

Deinitialization of a transport endpoint provides local management only, it
does not send information over the network. Issuing t unbind () disables a
transport endpoint so that no further request destined for the given endpoint is
accepted by the transport provider. In addition, t_unbind () disables event
generation and disassociates the endpoint from its protocol address.

131

Issuing t _ c los e () informs the transport provider that the user is finished
with the transport endpoint and frees any local resources associated with that
endpoint.

2.5.2 The Server
The client-server example in this chapter assumes that the transport provider supports
the orderly release of a connection. When all the data has been transferred by the
server, the connection can be released as shown in Example 2-8.

2-20 Connection-Mode Service

Example 2·8: Connection Release for the Server (Connection Mode)
while (1) {
n = t_rcvrel(f);
(n < 0) {
if (t_errno != TLOOK && t_errno != TNOREL)
t_error("rexample: error in t_rcvrel:");
t_unbind(f);
t_close(f);
exit (1) ;

}

else {
if (t_errno == TLOOK) {
t_error("TLOOK error");
t_unbind(f);
t_close(f);
exit(l);
t_error("rexample: NO T ORDREL available");
}

if (n == 0) break;
n = t_sndrel(f,

(struct t_call *) 0);

if (n < 0) {
t_error(nrexample: error in t_sndrel:n)i
t_unbind(f);
t_close(f);
exit(l);
t_unbind (f) ;
t_close(f);
exit(O);

2.6 Deinitialization
Refer to the previous client and server connection-release example segment for an
example of deinitialization.

Connection-Mode Service 2-21

Connectionless-Mode Service

This chapter describes the connectionless-mode service of the transport service
interface. Connectionless-mode service is appropriate for short-term request/response
interactions, such as transaction processing applications. Data is transferred in selfcontained units with no logical relationship required among mUltiple units.
The connectionless-mode services will be described using a transaction server as an
example. This server waits for incoming transaction queries and processes and then
responds to each query.
The example in this chapter appears in its entirety in Appendix E.

3.1

Initialization
Like the connection-mode service, the transport users must perform appropriate
initialization steps before data can be transferred. A user must choose the appropriate
connectionless transport service provider using t _open () and establish its identity
using t_bind () .
In Example 3-1, the definitions and local management calls needed by the transaction
server are shown and a description follows the example.

Example 3·1: Initialization Phase for the Transaction Server
(Connectionless Mode)
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/wait.h>
#include <sys/file.h>
#include <netinet/in.h>
#include <stdio.h>
#include <signal.h>
#include <errno.h>
#include <sgtty.h>
#include <netdb.h>
#include <syslog.h>
#include <xti.h>

struct sockaddr in sname;
int net,ncc;
extern
int errno;
extern void do_setup();
struct t_unitdata unitdata;
main (argc, argv)
char *argv[];
do_setup () ;
doit(net);

Example 3-1:

(continued)

doit(f)
int fi
int t_rcv_flagsi
struct hostent *hPi
char rcv_buf[5120]i
struct sockaddr sname1i
unitdata.addr.maxlen = sizeof(sname1);
unitdata.addr.buf = (char *) &sname1;
unitdata.opt.maxlen = 0;
unitdata.opt.buf = 0;
unitdata.udata.maxlen = sizeof(rcv_buf);
unitdata.udata.buf
&rcv_buf[O];

void
do_setup ()
struct t call t_Iist_call;
struct t bind t_bind_addr_req;
struct t bind t_bind_addr_req1;
struct t bind t_bind_addr_ret;
struct t_info t_open_info;
/* transport char. from transport */
int t_status;

/*
* Call t_open - establish a transport endpoint

*/
if ((net = t_open ("udp", O_RDWR, &t_open_info)) < 0)
t_error(IIrexamless: t_open error");
exit(1);

{

[]

/*
* t bind - bind an address to a transport endpoint

*
*/

sname.sin-port
200;
sname.sin_family = AF_INET;
t_bind_addr_req.addr.len = sizeof (struct sockaddr_in);
t_bind_addr_req.addr.buf = (char *) &sname;
t_bind_addr_req.qlen = 1;
t_bind_addr_ret.addr.maxlen = sizeof (struct sockaddr_in);
t_bind_addr_ret.addr.buf = (char *) &sname;
if ((t_bind(net, &t_bind_addr_req, &t_bind_addr_ret)) < 0)
t_error(IIrexamless: t_bind error");
exit (1) ;

3-2 ConnectiQnless:-Moc:je Sf3rvice

{

I1l

The connectionless-mode initialization is similar to the connection-mode
initialization. The server establishes a transport endpoint with the desired
transport provider, using t open ( ). In the above example segment, the first
argument, udp, of t _ open-() identifies the UDP transport provider. The
second argument, 0 _RDWR, identifies the open flag as being READ and
WRITE operation. The third argument, &t open info, points to a location
where the returned characteristics of the underlyiiig transport protocol are
placed. Refer to the t _open () reference pages for a description of the
returned characteristics.

121

Like the connection-mode server, the connectionless-mode server also binds a
transport address to the endpoint, so that potential clients can identify and
access the server. The transport address is bound to the endpoint by using a
t_bind () call. The first argument, net, identifies the transport endpoint which
is associated with a protocol address. Both the second argument,
&t_bind_addr_req, and third argument, &t_bind_addr_ret, point to t_bind
structures. The second argument contains the address that is requested to be
bound with the transport endpoint. On return, the third argument contains the
address that was actually bound to the transport endpoint. This returned address
can be different from the address specified in the second argument.

Unlike the connection-mode server, the qlen field of the t bind structure has no
meaning for connectionless-mode service, because all users are capable of receiving
datagrams once they have bound an address. It should be noted that the transport
service interface does define a client-server relationship between two users in the
connection-mode service; however, no such relationship exists in the connectionlessmode service. It is this example, not the transport service interface, that defines one
user as a server and another as a client.
Once the endpoint is bound, the transport user can send or receive data units through
the transport endpoint.

3.2 Data Transfer
After a user has bound a protocol address to the transport endpoint, data grams can be
sent or received over that endpoint. Each outgoing message is accompanied by the
address of the destination user. In addition, the transport service interface enables a
user to specify protocol options that should be associated with the transfer of the data
unit. Each transport provider defines the set of options, if any, that can accompany a
datagram. When the datagram is passed to the destination user, the associated
protocol options can be returned as well.
Example 3-2 shows the steps for the server to receive data. A description of the data
transfer follows this example segment.

Connectionless-Mode Service 3-3

Example 3-2: Data Transfer for Transaction Server (Connectionless
Mode)
doit(f)
int f;
int t_rev_flags;
struct hostent *hp;
char rcv_buf[5120);
struct sockaddr snamel;
unitdata.addr.maxlen = sizeof(snamel);
unitdata.addr.buf = (char *) &snameli
unitdata.opt.maxlen = 0;
unitdata.opt.buf = 0;
unitdata.udata.maxlen = sizeof(rcv_buf);
unitdata.udata.buf = &rcv_buf[O);
nec = t_rcvudata(f,&unitdata,&t_rcv_flags);

if (nec == 0)
printf("received %d oetets\n",unitdata.udata.len)i
else
printf("nce = %d, errno =%d\n",nce,errno)i
(void) t_close(f);
~
exit(O) i

In the example, t rcvudata is called to receive a data unit. The first
argument,/, of tycvudata identifies the local transport endpoint through
which data will be received. The second argument, &unitdata, points to a
t_unitdata structure that contains the following members:
struct netbuf addr;
struct netbuf opt;
struct netbuf udata

On return from the call, the members have the following meanings:
addr

Specifies the protocol address of the sending unit.
opt

Identifies protocol-specific options that were associated with this data unit.
udata

Specifies the user data that was received.
The third argument, &t_revJags is set on return to indicate that the complete data
unit was not received. In other words, the buffer defined in the udata field of
&unitdata is not large enough to hold the current data unit. The buffer is filled and
T_MORE is set in &t_revJags on return, to indicate that another t_rev_ udata
should be issued to retreive the rest of the data unit. Subsequent t rcvudata calls
return zero for the length of the address and for options, until the full data unit has
been received.

-~-Conn-ectionless;;Mode-S-ervic-e

3.3 Deinitialization
Deinitialization of a transport endpoint provides local management only. It does not
send information over the network. Issuing t_unbind () disables a transport
endpoint so that no further request destined for the given endpoint is accepted by the
transport provider. In addition, t unbind () disables event generation and
disassociates the endpoint from its protocol address.

121

Issuing t _ c los e () informs the transport provider that the user is finished
with the transport endpoint and frees any local resources associated with that
endpoint.

Refer to Example 3-2 for an example of deinitialization.

Connection less-Mode Service 3-5

Advanced Topics

This chapter contains important concepts of the transport service interface that have
not been discussed in the previous chapters. It describes:

4.1

•

The characteristics associated with a transport endpoint that can be changed
after an endpoint is opened

•

How memory resources can be managed

•

Choosing a mode of execution for an application

•

Reporting events to an application

•

Using the two levels of error reporting

Management of Local Transport Characteristics
As was discussed in previous chapters, the t open () call returns the default
provider characteristics associated with a transport endpoint. However, some
characteristics can change after an endpoint has been opened. The characteristics that
can change are associated with negotiated options. An example of a negotiated option
is the support of an expedited data transfer. The t_getinfo () call can be used to
retrieve the current characteristics of a transport endpoint.
The t _ optmgmt () call can be used to negotiate the values of protocol options with
the transport provider. Each transport protocol defines its own set of negotiable
protocol options. See Section 4.1.1 for a description of the transport-protocol
characteristics. Because of the protocol-specific nature of options, only applications
written for a particular protocol environment are expected to use the t _ optmgmt ( )
call.
In the connectionless-mode, the t optmgmt () call can be used to negotiate
protocol options that can be associated with the transfer of each data unit. Like
connection-mode service, each transport provider specifies the options, if any, that it
supports. Option negotiation is therefore a protocol-specific activity.
The XTI library provides information on both the default characteristics of the
underlying transport protocol and the quality of service supported by the transport
provider.

4.1.1

Transport-Protocol Characteristics
Table 4-1 lists the characteristics of the transport protocol, which is supported by the
underlying transport provider. The characteristics are returned in the t_info
structure by both t_open () and t_getinfo () calls.

Table 4·1: Transport Provider Characteristics
Parameters

Before Call

After Call (TCP)

After Call (UDP)

info->addr

info->options

info->tsdu

info->etsdu

-1

info->connect

info->discon

-2
-2

-2
x
-2
-2
-2

info->servtype

T_COTS_ORD

T_CLTS

/
The parameter value is meaningless
x

Value determined by the transport protocol

o
The transport provider does not support the concept, although the function is
supported in another form

-1
No limit on the value supported
-2

Not allowed by the transport protocol

4.1.2 Quality of Service
The following are quality of service (types of service) supported by the different
transport providers.

4.1 .2.1

Types of Service Supported by TCP - The TCP transport provider supports the
types of services listed in Table 4-2. The type of service is returned in the
tcp_options structure in the opt fields of parameters of the t_listen (),
t_accept (), t_connect, t_rcvconnect (), and t_optmgmt () calls.

_ _ _ _ _u u _ _ _ _ _ _ _ _ _ _ _ _

~g~dvanced Topic~_________________________ __

Table 4·2: Types of Service
Parameter

Service Type

Description

precedence

TCP_ROUTINE

Routine precedence, defined in xti.h

timeout(ms)

TCP_LINGERTIME
converted to ms

Maximum linger time (2 minutes),
defined in tcp_timer.h
Default maximum segment size for TCP,
defined in tcp.h

secoptions

4.1.2.2

security

T_UNUSED

Not used

compartment

T_UNUSED

Not used

handling

T_UNUSED

Not used

tcc

T_UNUSED

Not used

Types of Service Supported by UDP - The UDP transport provider does not
support Quality of Service options, because the association of types of service with
each datagram is not supported by UDP.

4.2 Management of Memory Resources
The t a110c () and t free () functions are used to manage the memory
resources for XTI applications. The t_a11oc () function dynamically allocates
storage for the specified library data structure. The structure type has to be one of the
following:
•

T_BIND_STR

•
•
•

T_CALL_STR

•
•

T_UNITDATA_STR

T_OPTMGMT_STR
T_DIS_STR
T_INFO_STR

The t_free () function is used to free memory previously allocated by
t a l l 0 C ( ). If memory has been allocated for buffers referenced by the structure,
the t f r e e () call also frees the referenced buffers first, before the structure itself is
freed~Also, the t free () call frees memory allocated by ma110c (). If the ptr
argument in the t -=-all 0 C () call or any of the buf pointers points to a block of
memory that was not previously allocated by t_a11oc () , t_free () does not
return with any warning.

Advanced Topics 4-3

4.3 Modes of Execution
The XTI library offers both synchronous and asynchronous modes of execution. The
effect is local only to the application process. By default, all XTI calls are
synchronous.
In the synchronous mode, an application normally blocks until completion. For
example, an application making a synchronous t_rev () call blocks until data from
over the network can be retrieved.
In the asynchronous mode, an application can use the nonblocking I/O feature. If the
requested operation cannot be completed, the XTI call returns immediately with -1,
and t_ errno is set to a specific value. For example, an application making an
asynchronous t _ rev () call returns immediately if no data is available. The
application can then periodically poll for the required event by means of the
t_look () call. The reissued XTI call can be successful only after the event has
occurred.
The aynchronous mode is specified through the 0 _NON BLOCK flag, which can be
set in either at_open () call or a fentl () call.

4.4 Event Handling
The XTI defines a set of events that must be reported to XTI applications. These
events are generated (written) by the transport provider and consumed (read) by XTI
applications. Two means are specified for reporting these events to the application:
•

A request to t _look () call

•

An exception (in the form of a [TLOOK] error return) during some XTI calls

The TLOOK error serves a special purpose in the transport service interface. It
notifies the user that an event has occurred. As such, TLOOK does not indicate an
error with a transport service interface routine, but the normal processing of that
routine will not be performed because of the pending event.
The t_look () call provides a means to peek (without consuming) the events,
except for the T_ aODATA and T_GOEXDATA events that are consumed, that have
been generated by the transport provider. The order of event reporting by t _look ()
is systems dependent.
Nine asynchronous events are defined in the transport service interfaces for both
connection and connectionless mode services. The events defined are as follows:
T_LISTEN
A request for a connection (connect indication) has arrived at the transport
endpoint.
T_CONNECT
A connect confirmation of a previously sent connect request has arrived at the
transport endpoint. A connect confirmation is generated when a server accepts a
connect request.
T_DATA
User data has arrived at the transport endpoint.
T_EXDATA
Expedited user has arrived at the transport endpoint.

------------------------------ -

- - - - - - - ------------

-- -

------------

T_DISCONNECT
A notification that the connection was aborted or that the server rejected a
connect request. This is known as the disconnect indication.
T_ORDREL
A request for the orderly release of a connection has arrived at the transport
endpoint. This is known as the orderly release indication.
T_UDERR
The notification of an error in a previously sent datagram has arrived at the
transport endpoint. This is known as unit data error indication.
T_GODATA
An indication that flow control restrictions on normal data have been removed.
T_GOEXDATA
An indication that flow control restrictions on expedited data have been
removed.
As shown in the state tables of Appendix C, it is possible in some states to receive
one of several asynchronous events. The t look () routine enables a user to
determine what event has occurred, if a TLOOK error is returned. The user can then
process that event accordingly. In the example, if a connect request is rejected, the
event passed to the client is a disconnect indication. The client exits if its request is
rejected.
The t _look () function is the only XTI call that reports events. It provides a means
for applications to poll for occurrence of events at a transport endpoint. Any of the
above events can be reported in t look (). Because it is a local management
function only, no information is sent over the network.
You can use the t_look () function with XTI calls operating in the synchronous or
asynchronous mode. You can issue it to find out what happened at a transport
endpoint, before issuing the appropriate XTI call. Upon immediate return from an
asynchronous XTI call, t_look () can also be used to poll for the appropriate event
before reissuing the asynchronous XTI call.
Although t look () facilitates event-driven applications, it does not invoke the
application automatically when a specific event occurs.

4.5 Error Reporting
There are two levels at which errors are defined:
•

Library level

•

System level

System level errors are errors resulting from the operating system routines that are
invoked by the XTI library implementation. These errors result in having the XTI
library setting t errno () to [TSYSERR] and the external variable errno
containing the vaiue of the system error.
Library level errors are errors resulting from invalid input parameters or the function
being called out of state. An external integer, t_errno, defined in <xti. h>, reflects
the type of error. The errors reported are caused by:
•

Input parameters that are illegal or out-of-bounds

•

The function being invoked in the wrong sequence

Advanced Topics 4-5

•

Lack of pennission to execute the operation required by the function

•

Events occurring while the function is executing in the asynchronous mode

The t_ errno function is used to print out a message describing the last error
encountered during a call to a transport library function. This call provides local
management functions only, because no infonnation is sent over the network.

---

------------·-·------4::~rACfvanceal

oprcs----------------

------~-----------

----------------------------

State Transitions

A.1

States and Events in Xli
The tables in this appendix describe the possible states of the transport provider as
seen by the transport user, the incoming and outgoing events that may occur on any
connection, and identify the allowable sequence of function calls. Given a current
state and event, the transition of the next state is shown, as well as any aCtions that
must be taken by the transport user.
Note

The terror () function and the support functions, t getstate () ,
t getinfo (), t alloe (), t free (), t look (), and
t -sync () are excluded from thestate tables, because they do not affect
the state of the interface. Each of these functions may be issued from any
state of the interface except the un initialized state.

A.1.1

Transport Service Interface States
Table A-I lists all possible states of the transport provider as seen by the transport
user. The transport service interface manages a transport endpoint by using, at most
eight states. The service type may be connection-mode (T_COTS), connection-mode
with orderly release (T_COTS_ORD), or connectionless-mode (T_CLTS).

Table A-1: Transport Service Interface States

A.1.2

State

Description

Service Type

T_UNINIT

Uninitialized - initial
and final state of the interface

T_COTS
T_CLTS
T_COTS_ORD

T_UNBND

Unbound

T_COTS
T_COTS_ORD
T_CLTS

T_IDLE

No connection established

T_COTS
T_COTS_ORD
T_CLTS

T_OUTCON

Outgoing connection pending
for active user

T_COTS
T_COTS_ORD

T_INCON

Incoming connection pending
for passive user

T_COTS
T_COTS_ORD

T_DATAXFER

Data transfer

T_COTS
T_COTS_ORD

T_OUTREL

Outgoing orderly release
(waiting for orderly release indication)

T_COTS_ORD

T_INREL

Incoming orderly release
(waiting to send orderly release request)

T_COTS_ORD

Outgoing Events
The outgoing events listed in Table A-2 correspond to the successful return of the
user-level transport functions, where these functions send a response to the transport
provider.
As shown in Table A-2, some events (for example, acceptX are distinguished by
the context in which they occur. The context is based on the values shown in Table
A-3.

----------- .. ------A.;;2-State-iransitions-----

Table A·2: Outgoing Events
Event

Description

Service Type

opened

Successful return of copen

T_COTS,T_COTS_ORD,T_CLTS

bind

Successful return of Cbind

T_COTS,T_COTS_ORD,T_CLTS

optmgmt

Successful return of Coptmgmt

T_COTS,T_COTS_ORD,T_CLTS

unbind

Successful return of cunbind

T_COTS,T_COTS_ORD,T_CLTS

closed

Successful return of Cclose

T_COTS,T_COTS_ORD,T_CLTS

connectl

Successful return of Cconnect
in synchronous mode

T_COTS, T_COTS_ORD

connect2

TNODATA error on cconnect
in asynchronous mode, or TLOOK
error due to a disconnect indication
arriving on the transport endpoint

acceptl

Successful return of caccept
with Dent== l,fd==resfd

accept2

Successful return of caccept
with Dent==1,fd!=resfd

accept3

Successful return of caccept
with Dent>1

snd

Successful return of t_snddis

T_COTS, T_COTS_ORD

snddisl

Successful return of Csnddis
with Dent>l

T_COTS, T_COTS_ORD

snddis2

Successful return of csnddis
with Dent>1

sndrel

Successful return of CSNDREL

T_COTS_ORD

sndudata

Successful return of csndudata

T_CLTS

Table A-3 lists the values that affect the events listed in Table A-2.

State Transitions A-3

Table A-3: Context Values for Table A-2

A.1.3

Value

Description

ocnt

Count of outstanding connect indications (connect indications
passed to the user but not accepted or rejected by the user),
only meaningful for the listening transport endpoint

File descriptor of the current transport endpoint

resfd

File descriptor of the transport endpoint where a connection
will be accepted

Incoming Events
Table A-4 lists incoming events, except for pas s conn, that correspond to the
successful return of the specified user-level transport functions, where these functions
retrieve data or event information from the transport provider. The pas s _conn
event is not associated directly with the return of a function on a given transport
endpoint.
The pass conn event occurs when a user transfers a connection to another
transport endpoint. This event occurs on the endpoint that is being passed the
connection, despite the fact that no function is issued on that endpoint. The
pass conn event is included in the state tables to describe what happens when a
user accepts a connection on another transport endpoint.
Notice in Table A-4 that the rcvdisX events are distinguished by the context in
which they occur. The context is based on the value of oent, which is the count of
outstanding connect indications on the current transport endpoint.

----------

-----------~A~State-TFan5itiOl1-s---------

--- -----

Table A·4: Incoming Events
Incoming Event

Description

Service Type

listen

Successful return of Clisten

T_COTS
T_COTS_ORD

rcvconnect

Successful return of Crcvconnect

T_COTS
T_COTS_ORD

rcv

Successful return of Crcv

T_COTS
T_COTS_ORD

rcvdisl

Successful return of Crcvdis
with oent==O

T_COTS
T_COTS_ORD

rcvdis2

Successful return of Crcvdis
with oent== 1

T_COTS
T_COTS_ORD

rcvdis3

Successful return of Crcvdis
with oent>l

T_COTS
T_COTS_ORD

rcvrel

Successful return of t_rcvrel

T_COTS_ORD

rcvudat

Successful return of Crcvudata

T_CLTS

rcvuderr

Successful return Crcvuderr

T_CLTS

pass_conn

Receive a passed connection

T_COTS
T_COTS_ORD

A.1.4 Transport User Actions
Some state transitions are accompanied by a list of actions the transport user must
take. These actions are represented by the notation [n], where n is the number of the
specific action, as follows:
[1]

Set the count of outstanding connect indications to zero.

[2]
Increment the count of outstanding connect indications.
[3]

Decrement the count of outstanding connect indications.

[4]
Pass a connection to another transport endpoint as indicated in t_acceptO.

A.1.5

State Tables
Tables A-5 describes the possible next states, given the current state and event. The
state is that of the transport provider as seen by the transport user.
The contents of each box represent the next state, given the current state (column)
and the current incoming or outgoing event (row). An empty box represents a
State Transitions A~

state/event combination that is invalid. Along with the next state, each box may
include an action list as specfied in Table A-7. The transport user must take the
specific actions in the order specified in the state table.

Table A-5: Common Local Management State Table
Event

T_UNINIT State

opened

T_UNBND

T_ UNBND State

T_IDLE State

T_IDLE[1]

bind
optmgmt

T_UNBND

unbind

T_UNBND
T_UNINIT

closed

T_UNITIT

Table A-6 describes the possible next states, given the current state and event. The
state is that of the transport provider as seen by the transport user.
The contents of each box represent the next state, given the current state (column)
and the current incoming or outgoing event (row). An empty box represents a
state/event combination that is invalid. Along with the next state, each box may
include an action list as specfied in Table A-7. The transport user must take the
specific actions in the order specified in the state table.
Table A-6: Connection less-Mode State Table
Event

T_IDLE State

sndudata

T_IDLE

rcvudata

T_IDLE

rcvuderr

T_IDLE

Along with the next state, each box may include an action list as specfied in Table
A-7. The transport user must take the specific actions in the order specified in the
state table.

Table A·7: Connection·Mode State Table
Event

T_IDLE

connectl

T_DATAXFER

T_OUTCON

connect2

T_DATAXFER

rcvconnect

T_DATAXFER

listen

T_INCON[2]

T_INCON

T_DATAXFERT_OUTREL T_INREL

T_INCON[2]

accept!

T_DATAXFER[3]

accept2

T_IDLE[3] [4]

accept3

T_INCON[3][4]

snd

T_DATAXFER

T_INREL

rcv

TDATAXFER

T_INREL

T_IDLE

sndrel

T_INREL

T_IDLE

rcvrel

T_INREL

T_IDLE

T_UNINIT

T_UNINIT T_UNINIT

T_IDLE

snddisl

T_IDLE[3}
T_IDLE[3]

snddis2
T_IDLE

rcvdisl
rcvdis2

T_IDLE[3]

rcvdis3

T_INCON[3]

pass_conn T_DATAXFER
closed

A.1.6

T_UNINIT

Events and TLOOK Error Indication
Table A-8 lists the asynchronous events that cause an XTI call to return with a
[TLOOK] error.

State Transitions A-7

Table A-8: Asynchronous Events That Returns a [TlOOK] Error
Xli Call

Asynchronous Events

Comment

Caccept:

T_DISCONNECT, T_LISTEN

Cconnect:

T_DISCONNECT, T_LISTEN Occurs only when Cconnect is on an
endpoint that has been bound with
a qlen = 0 and for which a connect
indication is pending.
This event indicates a disconnect has
occurred on an outstanding connect
indication.

Clisten:

Crcv:

T_DISCONNECT, T_ORDREL

Crcvconnect:

T_DISCONNECT

t_rcvrel:

T_DISCONNECT

Crcvudata:

T_UDERR

Csnd:

T_DISCONNECT, T_ORDREL

Csndudata:

T_UDERR

cunbind:

T_LISTEN

Csndrel:T_DISCONNECT

When a [TLOOK] error has been received on a transport endpoint by means of an
XTI function, subsequent calls to that and other XTI functions to which the same
[TLOOK] error applies, continue to return [TLOOK] until the event is consumed. An
event causing the [TLOOK] error can be determined by calling t_look (), and can
then be consumed by calling the corresponding consuming XTI function.

Guidelines for Writing ProtocolIndependent Software

Protocol-independent applications are applications that can run over several transport
providers without significant changes.

B.1

Amount of Required Changes
The number of changes required depends upon the following factors:
•

Extent of transport services required by the application

•

Functional compatibility of the transport providers

•

Availability of optional XTI functions for examination. and negotiation of
transport options

Each transport provider should provide most, if not all, of the transport services
required by the application. Deficiencies in this area may require enhancements in the
application.
Transport providers that are functionally equivalent often have similar transport
characteristics. Thus, default characteristics set by the underlying transport protocols
may be sufficient for application portability. On the other hand, if the default
characteristics between the transport providers differ greatly, the user may enhance
the application or negotiate protocol options with the providers. Optional XTI
functions such as t _ optmgmt () can be used for this purpose.

B.2 General Rules
In order to maximize portability of XTI applications between different kinds of
machines and to support protocol independence, you should follow these general
rules:
•

An application should make use only of these functions and mechanisms
described as being mandatory features of XTI. This assumes that the default
transport services offered are adequate for application support.

•

In the connection mode service, the concept of a transport service data unit
(TSDU) may not be supported by all transport providers. The user should make
no assumptions about the preservation of logical data boundaries across a
connection.

•

The transport provider identifier should not be hard-coded into the application.
While software may be written for a particular class of service (for example,
connectionless-mode service), it should not be written to depend on any
attribute of the underlying protocol.

•

The protocol-specific service limits returned on the t _open () and
t get info () functions must not be exceeded. It is the responsibility of the
user to access these limits and then adhere to the limits throughout the
communication process.

•

The user program should not look at or change options that are specific to the
underlying protocol. The t optmgmt () function enables a user to access
default protocol options from the transport provider, which can then be blindly
passed as an argument on the appropriate connection establishment function.
Optionally, the user can choose not to pass options as an argument on connect
establishment functions.

•

The reason codes associated with t_rcvdis () are also protocol.dependent.
The user should not interpret this information if protocol-independence is a
concern.

•

Protocol-specific addressing issues should be hidden from the user program.
Similarly, the user must have some way of accessing a destination address in an
invisible manner, such as through a name server.

•

The error codes associated with t_rcvuderr () are protocol-dependent. The
user should not interpret this information if protocol-idependence is a concern.

•

Optional orderly release facility of the connection-mode service, for example,
t_sndrel () and t_rcvrel () , should not be used by programs targetted
for multiple protocol environments. This facility is not supported by all
connection-based transport protocols.

Migrating from Socket-Based Software to
Xli-Based Software

This appendix contains infonnation on migrating from socket-based software to
XTI-based software. Table C-l lists an example of the call sequences issued by an
active TCP user. Table C-2lists an example of the call sequences issued by a passive
TCP user which communicates with the active TCP user in Table C-l. Table C-3
lists an example of the call sequences issued by a UDP user.
Table C-l lists an example of the call sequences issued by an active user.

Table C-1: Active TCP User
Socket Level Calls

XTI Calls

s=socket (af, type, protocol)

fd = copen (name, ofiag, info)
name that corresponds to <af,
type, protocol> is provided in <xti.h>
oflag = O_RDWR

bind (s, sockname, namelen)

Cbind (fd, req, ret)
req->addr.len = (unsigned int) namelen
req->addr.buf = (char *) sockname
req->qlen = (unsigned) 0

ret->addr.maxlen = (unsigned int)
struct sockaddr_in)
ret->addr.buf = &<local socket>
connect (s, name, namelen)

Cconnect (fd, sndcall, rcvcall)
sndcall->addr.1en = (unsigned int) namelen
sndcall->addr.buf = (char *) name
sndcall->optJen = (unsigned int) sizeof (struct tcp_options)
sndcall->opt.buf = &<tcp options>
sndcall->udata.1en = 0

nc = snd (s, msg, len, sflags)

cc = csnd(fd, msg, len, tflags)
tflags = T_EXPEDITED if sfiags is set to MSG_OOB

close (s)

Cclose (fd)

Table C-2 lists an example of the call sequences issued by a passive TCP user that
communicates with the active TCP user in Table C-l.

Table C-2: Passive TCP User
Socket Level Calls

Xli Calls

s = socket (af, type, protocol)

fd = copen (name, oflag, info)
Name which corresponds to <af,
type, protocol> is provided in <xti.h>
oflag = O_RDWR

bind (s, sockname, nameln)

Cbind (fd, req, ret)
req->addr.1en = (unsigned int) nameln
req->addr.buf = (char *) sockname
req->qlen = (unsigned) backlog
where backlog is input to listen
ret->addr.maxlen = (unsigned int)(struct sockaddr_in)
ret->addr.buf = addr.buf = &<local socket>

setsockopt (s, IPPROTO_TCP),
TCP_ACCEPTMODE, &acc_mode,
sizeof(acc_mode»

listen (s, backlog)

Clisten (fd, call)
call->addr.maxlen = (unsigned int) (struct sockaddr_in)
call->addr.buf = &<remote socket>
call->opt.maxlen = (unsigned int) sizeof(struct tcp_options)
call->opt.buf =&<remote options>
call->udata.maxlen = 0

ns = accept (s, addr, addrlen)
setsockopt (ns, IPPROTO_TCP

caccept (fd, resfd, call)

TCP_CONACCEPT, 0, 0)
call->addr.1en = (unsigned int) (struct sockaddr_in)
call->addr.buf = &<remote socket>
call->opt.len = (unsigned int) sizeof(struct tcp_options)
call->opt.buf = &<tcp options>
call->udata.1en = 0
call->sequence = <sequence number returned in Clisten)
cc =recv (ns, buf, len, flags)

nc = Crcv (resfd, buf, len, rflags)

close (ns)

Cclose (resfd)

Note
If resfd != fd, resfd must be obtained by means of a t open () call and
the t_bind () call must be issued with qlen = O. Onoutput, rflags, if
the type of data received matches that given by flags in the recv call.
Table C-3 lists an example of the call sequences issued by a UDP user.

Table C-3: UDP User
Socket Level Calls

XTI Calls

s = socket (af, type protocol)

fd = Copen (name, oflag, info)
Name that corresponds to <af,
type, protocol> is provided in <xti.h>
oflag = O_RDWR

bind (s, sockname, namelen)

Cbind (fd, req, ret)
req->addr.len = (unsigned int) namelen
req->addr.buf = (char *) sockname
req->qlen = (unsigned) 0
ret->addr.maxlen = (unsigned int) (struct sockaddr_in)
ret->addr.buf = &local socket>

cc = sendto (s, msg, len,

Csndudata (fd,unitdata)
flags, to, tolen)
unitdata->addr.len = (unsigned int) tolen
unitdata->addr.buf =to
unitdata->opt.len = 0
unitdata->udata.len = len
unitdata->udata.buf =msg

cc = recvfrom (s, buf, len, flags)
from, fromlen)

Crcvudata (fd, unitdata, flags,
unitdata->addr.buf = from
unitdata->opt.maxlen = 0
unitdata->udata.maxlen = (unsigned int) len
unitdata->udata.buf = buf

close (s)

Cclose (fd)

Migrating from Socket-Based Software to XII-Based Software C-3

Connection-Mode Programming Examples

This appendix contains the entire connection-mode client and server code from which
the examples used in Chapter 2 were taken.

0.1

Connection-Mode Client Programming Example
Example D-l shows how the client establishes a transport connection with the server
and then exchanges data with the server. The connection is released using the orderly
release facility of the transport service interface.
Example 0-1: Connection-Mode Client Code
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include

extern int errnOi
int neti
struct t_info t_open_infoi
/* transport char. from transport */
struct t_info t_getinfo_infoi
struct tcp_options tcP_OptSi
struct t_optmgmt t_optm_reqi
struct t_optmgmt t_optm_reti
struct sockaddr_in sin;
struct
servent *SPi
char *hostnamei
struct hostent *hosti
#define MAXDSIZE 512
char snd_buf[MAXDSIZE);
char rcv_buf[MAXDSIZE)i
int ni
int status;
struct t_call t_conn_sndcalli
struct t call t_conn_rcvcalli
struct t call t_rcvconn_call;
struct t_discon disconi
int t_rcv_flagsi
main (argc, argv)
int argci
char *argv[];

Example 0·1:

(continued)

char destin[255];
if «net = t_open("tcp", O_RDWRIO NONBLOCK, &t_open_info»
t_error (lit_open failed");
exit(t_errno);

< 0)

status

* t

bind - bind an address to a transport endpoint

*
*1
if (t_bind (net, 0, 0) < 0) {
t_error(IIiexample: t_bind error"):
exit(l) :

t_optm_req.opt.len = 0:
t_optm_req.flags = T_DEFAULT:
t_optm_ret.opt.maxlen = sizeof(struct tcp_options):
t_optm_ret.opt.buf = (char *) &tcp_opts:
status = t_optmgmt(net, &t_optm_req, &t_optm_ret):
if (status < 0) {
t error (IIiexample: t_optmgmt error");
e~it(l) ;
t_optm_req.opt.len = 0;
t_optm_req.flags = T_DEFAULT:
t_optm_ret.opt.maxlen = sizeof(struct tcp_options):
t_optm_ret.opt.buf = (char *) &tcp_opts:
status = t_optmgmt(net, &t_optm_req, &t_optm_ret);
if (status < 0) {
t_error(IIiexample: t_optmgmt error"):
exit(l) ;

printf ("host : ") ;
scanf("%s",destin):
host = gethostbyname(destin);
if (host) {
sin. sin_family = host->h_addrtype:
bcopy(host->h_addr, (caddr_t)&sin.sin_addr, host->h_length);
hostname = host->h_name;
sin.sin-port = 200; 1* try to connect to port 200 *1
t_conn_sndcall.addr.len = sizeof (struct sockaddr_in);
t_conn_sndcall.addr.buf = (char *) &sin;
t_conn_sndcall.opt.len = 0;
t conn sndcall.udata.len = 0;
t=conn=rcvcall.addr.maxlen = sizeof (struct sockaddr in);
t_conn_rcvcall.addr.buf = (char *) &sin;
t_conn_rcvcall.opt.maxlen = sizeof(struct tcp_options);
t_conn_rcvcall.opt.buf = (char *) &tcp_opts;

{

Example 0-1:

(continued)

t_conn_rcvcall.udata.maxlen = 0;
t_rcvconn_call.addr.maxlen = sizeof (struct sockaddr in);
t_rcvconn_call.addr.buf = (char *) &sin;
t_rcvconn_call.opt.maxlen = sizeof(struct tcp_options);
t_rcvconn_call.opt.buf = (char *) &tcp_opts;
t_rcvconn_call.udata.maxlen = 0;
t_rcvconn_call.udata.buf = 0;
if «t_connect(net, &t_conn_sndcall, &t_conn_rcvcall»
if (t_errno == TNODATA) {
while (1) {
status = t_rcvconnect(net, &t_rcvconn_call);

< 0)

{

if (status < 0) {
if (t_errno == TLOOK)
printf("Event %x came in\n",t_look(net»;
(void) t_unbind(net);
(void) t_close(net);
exit(l);
if (t_errno != TNODATA) {
t_error(niexample: t_rcvconnect()n);
(void) t_unbind(net);
(void) t_close(net);
exi t (1) ;

else
break;
}

else {
t error ("iexample: t connect()");
(;oid) t_unbind(net);
(void) t close(net);
exit (1);-

printf(ncalling t_snd with %d bytes of regular data\n",sizeof(snd_buf»;
n = t_snd(net, &snd_buf[O],sizeof(snd_buf) , 0);
if

< 0)

{

if (t errno == TLOOK) {
printf("Generated a %X TLOOK error\n",t_look(net»;
(void) t_unbind(net);
(void) t_close(net);
exit(l);
t_error("iexample: t_snd error");
(void) t unbind(net);
(void) t=close(net);
exit(l);
printf("t_snd sent %d bytes\n",n);
while (1) {
n = t_rcv(net, rcv_buf, sizeof(rcv_buf), &t_rcv_flags);
if (n < 0) {
if (t_errno != TNODATA)
t error (niexample: t rcv error n );
(;oid) t_unbind(net);
(void) t_close(net);

Connection-Mode Programming Examples D-3

Example 0·1:

(continued)

exit(l);
}

else {
t_error("iexample: NO data available");
}

if (n > 0) break;

printf("t_rcv received %d bytes\n",n);
if (t_rcv_flags & T EXPEDITED)
printf ("data is e-;pedi ted\n") ;
else
printf("data is normal\n");
n = t_sndrel (net,

(struct t

call *) 0);

if (n < 0) {
t_error("iexample: error in t_sndrel:");
t_unbind(net);
t_close(net) ;
exit(l);

while (1) {
n = t_rcvrel(net);
if (n < 0) {
if (t_errno != TLOOK && t_errno != TNOREL)
t_error("iexample: error in t_rcvrel:");
t_unbind(net);
t_close(net);
exit(l);
}

else {
if (t_errno == TNOREL)
t_error("iexample: NO T_ORDREL available");
else {
t_error(IIiexample: TLOOK event");
t_unbind(net);
t_close(net);
exit(l);
}
}
}

if (n == 0) break;
t_unbind(net);
t close(net);
exit(O);

0.2 Connection-Mode Server Programming Example
Example D-2 shows how the server establishes a transport connection with a client
and then exchanges data with the client on the other side of the connection. The
connection is released using the orderly release facility of the transport service
interface.

-- -D-4-Genneetiefl-Mede-Pregrammiflg-Examples---

Example 0-2: Connection-Mode Server Code
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/wait.h>
#include <sys/file.h>
#include <netinet/in.h>
#include <stdio.h>
#include <signal.h>
#include <errno.h>
#include <sgtty.h>
#include <netdb.h>
#include <syslog.h>
#include <xti.h>
int net,net1,n,n1;
extern
int errno;
main (argc, argv)
char *argv[];
int fromlen;
struct sockaddr_in from;
int status;
status = get_income();
if (status != 0)
exit (1) ;
else {
sleep(10);
exit(O) ;
}

doit(f, seq)
int f,seqi
int t_rcv_flags;
struct hostent *hp;
char rcv_buf[S12];
char snd_buf[S12];
int n;

while (1) {
n = t_rcv(f,rcv_buf, sizeof(rcv_buf)

,&t_rcv_flags);

if (n < 0) {
if (t_errno != TNODATA)
t error (llrexample: t_rcverror");
<=unbind (f) ;
t_close(f);
exit (1) ;
}

else {
t_error("rexample: NO data available"};
}

if (n > 0) break;
printf("t_rcv received %d bytes\n",n);

Connection-Mode Programming Examples ~

Example 0-2:

(continued)

if (t_rcv_flags & T_EXPEDITED)
printf("data is expedited\n");
else
printf("data is normal\n");
printf("calling t_snd with %d bytes of regular data\n",sizeof(snd_buf»;
n = t_snd(f, &snd_buf[O),sizeof(snd_buf) , 0);
if (n < 0) {
if (t_errno == TLOOK)
printf("Generated a %X TLOOK error\n",t_look(f»;
(void) t_unbind(f);
(void) t_close(f);
exit(l);
t_error("rexample: t
(void) t_unbind(f);
(void) t_close(f);
exit(l) ;

snd error");

printf("t_snd sent %d bytes\n",n);
while (1) {
n = t_rcvrel(f);
if (n < 0) {
if (t_errno != TLOOK && t_errno != TNOREL)
t_error("rexample: error in t_rcvrel:");
t_unbind(f);
t_close(f);
exit(l);
}

else {
if (t_errno == TLOOK) {
t_error("TLOOK error");
t_unbind (f) ;
t_close(f);
exit(l);
t_error("rexample: NO T ORDREL available");
}

}

if (n

0) break;

= t_sndrel(f, (struct t call *)

0);

if (n < 0) {
t_error("rexample: error in t_sndrel:");
t_unbind(f);
t_close(f);
exit(l);

t_unbind(f);
t_close(f);
exit(O);

int
get_income ()

__D-!'~·EtConnection,,-ModeJ~J'ogl'ammil'lg--Examples -

Example 0-2:

(continued)

struct sockaddr_in sname;
struct servent *sp;
int i;
int child;
struct t_call t list call;
struct t call *t_listytr;
struct t call t snddis call;
struct t_bind t-bind addr req;
struct t bind t=bind=addr=req1i
struct t bind t bind addr ret;
struct t_info t=open=info;
1* transport char. from transport
int t_status;

1*
* Call t_open - establish a transport endpoint

if ((net = t_open (lttcplt, O_RDWR, &t_open_info»
t_error(ltrexample: t_open error lt );
exit(l);

< 0) {

1*
* t bind - bind an address to a transport endpoint

*
*1
sname.sinyort
200;
sname.sin_family = AF_INET;
sname.sin_addr.s_addr = 0;

1* load port # *1

t bind addr req.addr.len = sizeof (struct sockaddr_in);
t=bind=addr=req.addr.buf = (char *) &sname;
t_bind_addr_req.qlen = 1;
t_bind_addr_ret.addr.maxlen = sizeof (struct sockaddr_in);
t_bind_addr_ret.addr.buf = (char *) &sname;

if ((t bind(net, &t bind addr req, &t bind addr ret»
t_er~or (ltrexample~ t_b'ind e~rorlt); exit(l)i

< 0)

{

t_listytr = (struct t_call *) t_alloc(net, T_CALL_STR, T_ADDR);
bcopy(&sname, t_listytr->addr.buf, t_listytr->addr.maxlen);

if (t_status < 0) {
if (t_errno != TNODATA)
t_error(ltrexample: t_listen error lt );
t_unbind(net)i
t_close(net);
exit(l);

printf(nHave a incomming connection with sequence # %d\n",

Connection-Mode Programming Examples 0-7

Example 0·2:

(continued)

t_list-ptr->sequence);
printf("attempting to accept sequence # %d\n",
t_list-ptr->sequence);
netl = get_endpoint();
if (t_status = t_accept(net,netl,t_Iist-ptr) < 0)
t error ("rexample: t accept error");
if (t_errno == TLOOK) {
printf("~vent %x carne in\n",t_Iook(netl));

{

exit(1);

fcntl(netl,F SETOWN, getpid());
child = fork();
if (child == 0)
t_unbind(net);
t_close(net);
t_sync(net1) ;
doit(netl, t_list-ptr->sequence);
else
{

printf("Forking Child process =%d for fd
child,netl, t_Iist-ptr->sequence);
t_unbind(netl);
t_close(netl);
t_free(t_Iist-ptr, T_CALL_STR);

%d seq=%d\n",

return(O)i

int
get_endpoint ()
{

struct sockaddr in sname;
struct servent *SPi
int tmp_net;
struct t_call t list call;
struct t_bind t=bind=addr_reqi
struct t_bind t bind addr reql;
struct t_bind t=bind=addr=reti
struct t_info t_open_info;
/* transport char. from transport */
int t_status;

* Call t_open - establish a transport endpoint

*/
if «tmp_net = t_open ("tcp", O_RDWR, &t_open_info)) < 0)
t_error("rexample: t_open error");
exit (1) i

* t_bind - bind an address to a transport endpoint
*

-D-8-GanfleGtian-Maee-Pra€Jramming-E-xamples-

{

Example 0-2:

(continued)

sname.sin-port = 0;
sname.sin_family = AF_INET;
sname.sin_addr.s_addr = 0;
t_bind_addr_req.addr.len
sizeof (struct sockaddr_in);
t bind addr req.addr.buf
(char *) &snarne;
t=bind=addr=req.qlen = 0;
t_bind_addr_ret.addr.maxlen = sizeof (struct sockaddr_in);
t_bind_addr_ret.addr.buf = (char *) &snarne;
if ((t_bind(tmp_net, &t_bind_addr_req, &t_bind_addr_ret)) < 0) {
t_error("rexample: t_bind error");
exit(l);
return(tmp_net);

Connection-Mode Programming Examples 0-9

Connectionless-Mode Programming
Examples

This appendix contains the entire connectionless-mode server code from which the
examples used in Chapter 3 were taken. It also contains a connectionless-mode client
code example.

E.1

Connection less-Mode Server Programming Example
Example E-l shows how the server waits for incoming datagram queries and then
processes each query.
As was mentioned in Chapter 3, the client-server relationship between two users does
not exist in the connectionless-mode service. It is only within context of the example
that the term is used because the transport service interface does not support this
relationship.

Example E-1: Connectionless-Mode Server Code
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include

struct sockaddr_in snamei
int net,ncCi
extern
int errno;
extern void do_setup()i
struct t_unitdata unitdatai
main (argc, argv)
char *argv[]i
do_setup () ;
doit(net);

doit (f)
int f;
int t_rcv_flags;
struct hostent *hPi
char rcv_buf[5120]i

Example E-1:

(continued)

struct sockaddr snamel;
unitdata.addr.maxlen = sizeof(snamel);
unitdata.addr.buf = (char *) &snamel;
unitdata.opt.maxlen = 0;
unitdata.opt.buf = 0;
unitdata.udata.maxlen = sizeof(rcv_buf);
unitdata.udata.buf = &rcv_buf[O);
ncc = t_rcvudata(f,&unitdata,&t_rcv_flags);
if (ncc == 0)
printf("received %d octets\n",unitdata.udata.len);
else
printf("ncc = %d, errno =%d\n",ncc,errno);
(void) t_close(f);
exit (0) ;

void
do_setup ()
struct t call t_list_call;
struct t_bind t_bind_addr_req;
struct t_bind t_bind_addr_req1;
struct t bind t_bind_addr_ret;
struct t_info t_open_info;
/* transport char. from transport */
int t_status;

* Call t_open *

establish a transport endpoint

if «net = t_open ("udp", O_RDWR, &t_open_info)) < 0)
t_error("rexamless: t_open error");
exit(l) ;

{

* t bind - bind an address to a transport endpoint
*
*/

sname.sin-port
200;
sname.sin_family = AF_INET;
t_bind_addr_req.addr.len = sizeof (struct sockaddr_in);
t_bind_addr_req.addr.buf = (char *) &sname;
t bind addr req.qlen = 1;
t=bind=addr=ret.addr.maxlen = sizeof (struct sockaddr_in);
t_bind_addr_ret.addr.buf = (char *) &sname;

if «t_bind(net, &t_bind_addr_req, &t_bind_addr_ret)) < 0)
t_error("rexamless: t_bind error");
exit(l);

E-2 Connectionless-Mode Programming Examples

{

E.2 Connectionless-Mode Client Programming Example
Example E-2 represents the client-side (user) that would communicate with the
server-side (user) as represented by the code under the previous section:
Connectionless-Mode Server. This code is not found in Chapter 3.

Example E-2: Connection less_mode Client Code
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <netinet/in.h>
#include <stdio.h>
#include <ctype.h>
#include <errno.h>
#include <signal.h>
#include <setjmp.h>
#include <netdb.h>
#include <xtLh>
#include <fcntl.h>
int net;
extern
int errno;
struct sockaddr_in sin;
char *hostname;
char hnamebuf[32];
struct t call t conn_sndcall;
struct t call t conn rcvcall;
struct t=info t=open=info;
/* transport char. from transport */
struct t_unitdata unitdata;
int t_rcv_flags;
char snd_buf[6000];
char rcv_buf[6000];
struct hostent *host;
int scc,n;
main (argc, argv)
int argc;
char *argv[];
host

gethostbyname("nil");

if (host) {
sin. sin family = host->h addrtype;
bcopy(host->h_addr, (caddr_t)&sin.sin_addr, host->h_length);
hostname = host->h_name;
sin.sinyort

/* don't set port till time to do connect */

/*
* Call t_open - establish a transport endpoint

*/
if ((net = t_open ("udp", O_RDWR, &t_open_info)) < 0)
t_error("iexamless: t_open error");
return(l);

{

Connection less-Mode Programming Examples E-3

Example E·2:

(continued)

* t_bind - bind an address to a transport endpoint
*

if ((t_bind(net, 0, 0»
< 0)
t_error(tliexarnless: t_bind error tl );
exit(l);

sin.sin-port = 200;
unitdata.addr.len = sizeof(sin);
unitdata.addr.buf = (char *) &sin;
unitdata.opt.len = 0;
unitdata.udata.len = sizeof(snd_buf);
unitdata.udata.buf = snd_buf;
unitdata.opt.len = 0;
n = t_sndudata(net, &unitdata);
if (n < 0) {
if (t_errno != TNODATA) {
t_error(tliexarnless: t_sndudata error tl );
(void) t_close(net);
exit(l);

t_close(net);
exit (0);

E-4 Connectionless-Mode Programming Examples

Glossary

abortive release
A connection termination that breaks a connection immediately and
may result in the loss of any data that has not reached the
destination user.
asynchronous mode
The mode of execution in which. transport service interface routines
do not block while waiting for specific asynchronous events to
occur, but instead return immediately if the event is not pending.
client
The transport user in connection-mode that initiates the
establishment of a transport connection to a another transport user
(server).
connection establishment
The phase in connection-mode that enables two transport users to
create a transport connection (virtual circuit) between them.
connection-mode
A circuit-oriented mode of transfer that enables data to be
transmitted over an established connection in a reliable, sequenced
manner. It also provides an identification mechanism that avoids
the overhead of address resolution and transmission during the data
transfer phase.
connectionless-mode
A message-oriented mode that supports data transfer in selfcontained units with no logical relationships required among
multiple units.
connection release
The phase in connection-mode that terminates a previously
established connection and ends the data exchange between two
transport users.
datagram
A unit of data transferred between two transport users during the
connectionless-mode.
data transfer
The phase in connection-mode or connectionless-mode that
supports the exchange of data between two transport users.
ETSDU
An acronym for Expedited Transport Service Data Unit. ETSDU is
the maximum expedited data message size that may be sent over a
transport connection.

expedited data
Data that are considered urgent. The transport protocol that
provides the transport service defines the specific semantics for the
expedited data.
initialization
The phase in either connection-mode or connectionless-mode in
which a transport user establishes a transport endpoint and binds a
transport address to the endpoint.
orderl y release
A procedure in connection-mode to gracefully terminate a transport
connection with no loss of data.
peer user
The user with whom a given user is communicating above the
transport service interface.
protocol address
The identifier used to differentiate and locate specific transport
endpoints in a network.
server
The transport user in connection-mode that advertises services to
other users (clients) and enables these clients to establish a
transport connection to it.
service request
A request for some action generated by a user to the transport
provider of a particular service.
synchronous mode
The mode of execution in which an application normally blocks
until completion. For example, an application making a
synchronous t rev () call will block until data from over the
network can beretrieved.
An acronym for Transport ConnectionLess Transport Service.
T_ CLTS means that the transport provider supports
connectionless-mode service.
T_COTS
An acronym for Transport Connection Oriented Transport Service.
T_COTS means that the transport provider supports connectionmode service but does not provide the optional orderly release
facility.
transport addresss
See protocol address definition.
transport connection
The communication circuit that is established between two
transport users in connection-mode.
transport endpoint
The local communication path between a transport user and a
transport provider.

2 Glossary

transport service interface
A set of transport-independent C library functions that support the
services of a transport interface. These functions confonn to the
X/Open Transport Interface Specifications.
transport provider
The transport protocol that provides the services of the transport
service interface.
transport service data unit
The amount of user data whose identity is preserved from one end
of a transport connection to the other.
transport user
The user-level application or protocol that accesses the services of
the transport service interface.
TSDU
An acronym for Transport Service Data Unit. TSDU is the
maximum message size that may be transmitted in either
connection-mode or connectionless-mode.
virtual circuit
A transport connection established in connection mode.

Glossary 3

Index

A
aborting
connection, 2-19

address
client, 2-5
applications
migrating, C-l
portability, B-1
portability rules, B-1
protocol independent, B-1

asynchronous mode
description of, 2-4, 2-13
events, 2-13

calling functions
legal sequence, 1-10
state tables, 1-10
client
addresss of, 2-5

communication path
establishing, 1-4, 2-1
connect indication
processing, 2-15
connect indications
listening, 2-15
listening for, 2-2, 2-9
maximum number of, 2-9
outstanding, 2-9

queueing, 2-9

binding
address, 2-9

connection
aborting, 2-19

address to endpoint, 2-5

accepting or rejecting, 2-10

transport address, 3-3

establishing, 1-4, 2-15

binding address
required state, 2-15

establishment, 1-5
initiating, 2-10

bound address of, 2-10

multiple units, 2-16

buffers
allocating, 2-10, 2-15
flags, 3-4
maximum size of, 2-13

orderly release, 2-19

netbuf, 2-10
size of, 2-15, 2-17, 2-19
user data, 2-17

release, 2-19
requirement for, 2-15

connection release
abortive, 1-6
orderly, 1-7
connectionless-mode
communication path, 1-8
data transfer, 1-9
description, 1-3
initialization functions, 1-9

connectionless-mode (cont.)
phases of, 1-8
when to use, 3-1

initialization
functions, 1-4

connection-mode
communication path, 1-4
description, 1-3

phases of, 1-3

listening

release connection, 1-.6

connect indications, 2-2
for connection, 2-9

D
data
expedited, 2-16, 2-19

data transfer
functions, 1-6
number of bytes, 2-17
terminating, 2-20

M
memory resources
managing, 4-3
modes
asynchronous, 4-4
synchronous, 4-4

datagrams
all received, 3-4
receiving, 3-4
sending and receiving, 3-3

N
netbuf structure, 2-9

E
error

portability
additional XTI functionality, 1-2

message, 2-5
system, 2-5
values defined, 2-5

requirements, 1-1
programming example
connectionless-mode client, B-3

errors
library level, 4-5

connectionless-mode server, B-1

system level, 4-5

connection-mode client, D-l

TLOOK,4-4
event handling
disabling, 1-7
events
asynchronous, 1-2,4-4

connection-mode server, D-4

protocol options
negotiating, 2-2, 2-5, 2-10
quality-of-service, 2-2
specifying, 3-3

disable, 3-5
disabling, 2-20
incoming, A-4
outgoing, A-2

expedited
data, 2-16, 2-19

Index-2

Q
quality of service
negotiating, 1-3

transport endpoint (cont.)

server
accepting request, 1-6
description, 1-5
identity, 1-5
notify request, 1-6
service
advertising, 1-5
synchronizing
transport endpoint, 2-16

disabling, 1-7, 2-20
establishing, 1-4, 1-8, 2-8, 3-3
freeing, 1-7
identifying, 2-1, 2-13, 2-17, 2-19
identity, 2-1
manipulating, 1-3
number of bound addresses to, 2-2
synchronizing, 2-16
used for connection, 2-15
transport protocol
characteristics of, 2-1, 2-4, 3-3
transport provider

T
t_acceptO, 2-10, 2-15
t_allocO, 2-10, 2-15, 2-16, 4-3
t_hindO, 1-4, 1-9,2-2, 2-5, 2-9, 2-10, 3-1, 3-3
t_call structure, 2-12, 2-15
t_c1oseO, 1-7, 1-10, 2-20, 3-5
t_connectO, 1-5,2-10, 2-12, 2-13
tcp_options structure, 4-2
t_errnoO,4-5
t_errorO,2-5
t_freeO,4-3
t_getinfoO, 2-5, 4-1
tJnfo structure, 4-1
t_listenO, 1-6,2-10, 2-15
t_lookO,4-4
t_openO, 1-4, 1-8, 2-1, 2-4, 2-5, 2-8, 2-16, 3-1,
3-3,4-1
t_openJnfo structure, 2-4
t_optmgmtO, 2-2, 2-5, 4-1
transport address
actual,3-3
binding, 3-3
transport endpoint
assigning address, 2-5

accepting connection, 2-2
address, 1-8
address structure, 1-4
characteristics, 4-1
characteristics of, 2-2, 4-1
default characteristics, B-1
description of, 1-1
establishing communication path, 2-1
establishing connection, 1-4
functions of, A-2
identifying, 2-4, 2-12, 3-3
identity, 1-4, 1-8,3-1
passing data to, 2-12
protocol options, 4-1
quality of service, 1-3
returning information, 2-1, 2-12
service request of, 1-1
service types, 2-2
state tables, A-5, A-6
states, A-I
supported protocols, 1-1
urgent condition, 2-16
transport service interface

assigning an address, 1-4

BSD IPC enhancements, 1-2

associated address, 1-4, 2-2, 2-5

characteristics, 1-2

binding address, 2-9, 2-15
binding to, 2-2

components, 1-10
consists of, 1-1

closing, 2-20
description, 1-3
disable, 3-5

event handling, 1-2
transport user
actions, A-5

Index-3

t_rcvO, 1-6, 2-16,2-17, 2-19
t_rcvconnectO, 2-13
t_rcvdataO, 3-4
t _rcvdis, 2-19
t_rcvdisO, 1-6, 1-7
t_rcvreIO, 1-7, 2-20
t_rcvudataO, 1-9,3-4
t_sndO, 1-6, 2-16,2-17
t_snddisO, 1-6, 2-10, 2-19
t_sndreIO, 1-7,2-20
t_sndudataO, 1-9
t_syncO,2-16
t_unbindO, 1-7, 1-10, 2-20, 3-5
types of service
TCP protocol, 4-2
UDP protocol, 4-3

Index-4

How to Order Additional Documentation

Technical Support
If you need help deciding which documentation best meets your needs, call 800-343-4040 before placing
your electronic, telephone, or direct mail order.

Electronic Orders
To place an order at the Electronic Store, dial 800-234-1998 using a 1200- or 2400-baud modem from
anywhere in the USA, Canada, or Puerto Rico. If you need assistance using the Electronic Store, call
800-DIGITAL (800-344-4825).

Telephone and Direct Mail Orders
Your Location

Call

Contact

Continental USA,
Alaska, or Hawaii

800-DIGITAL

Digital Equipment Corporation
P.O. Box CS2008
Nashua, New Hampshire 03061

Puerto Rico

809-754-7575

Local Digital Subsidiary

Canada

800-267-6215

Digital Equipment of Canada
Attn: DECdirect Operations KA02/2
P.O. Box 13000
100 Herzberg Road
Kanata, Ontario, Canada K2K 2A6

International
Internal*

Local Digital subsidiary or
approved distributor
SSB Order Processing - WMO/E15

or
Software Supply Business
Digital Equipment Corporation
Westminster, Massachusetts 01473

* For internal orders, you must submit an Internal Software Order Form (EN-01740-07).

Reader's Comments

ULTRIX
Guide to XlOpen Transport Interface
AA-PBKXA-TE

Please use this postage-paid form to comment on this manual. If you require a written reply to a software
problem and are eligible to receive one under Software Performance Report (SPR) service, submit your
comments on an SPR form.
Thank you for your assistance.

Please rate this manual:
Accuracy (software works as manual says)
Completeness (enough information)
Clarity (easy to understand)
Organization (structure of subject matter)
Figures (useful)
Examples (useful)
Index (ability to find topic)
Page layout (easy to find information)

Excellent

Good

Fair

Poor

0
0
0
0
0
0
0
0

What would you like to see more/less of?

What do you like best about this manual?

What do you like least about this manual? _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

Please list errors you have found in this manual:
Page

Description

Additional comments or suggestions to improve this manual:

What version of the software described by this manual are you using?
Namerritle _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Dept.
Company _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Date _ _ _ __
Mailing Address _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __
_ _ _ _ _ _ _ _ _ _ _ _ Email _____________ Phone _ _ _ _ _ __

- - - - - _.

Do Not Tear - Fold Here and Tape

IDmaamDTM

-----------------------------rr]-rll----------:::::::::--NECESSARY
IF MAILED IN THE
UNITED STATES

BUSINESS REPLY MAIL
FIRST-CLASS MAIL PERMIT NO. 33 MAYNARD MA
POSTAGE WILL BE PAID BY ADDRESSEE

DIGITAL EQUIPMENT CORPORATION
OPEN SOFTWARE PUBLICATIONS MANAGER
ZK03-2/Z04
110 SPIT BROOK ROAD
NASHUA NH 03062-9987

IIh 1IIIIhlllllllllllllllllllllllllllllllllllllilII
- - - - - - - . Do Not Tear - Fold Here .- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - i

Cut

Along
Dotted
Line

Reader's Comments

ULTRIX
Guide to XlOpen Transport Interface
AA-PBKXA-TE

Excellent

Good

Fair

Poor

0
0
0
0
0
0
0
0

What would you like to see more/less of?

What do you like best about this manual?

What do you like least about this manual? _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

Please list errors you have found in this manual:
Page

Description

Additional comments or suggestions to improve this manual:

What version of the software described by this manual are you using?
Nameffitle _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ Dept.
Company _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Date _ _ _ _ __
Mailing Address
_ _ _ _ _ _ _ _ _ _ _ _ Email _____________ Phone

------.

Do Not Tear - Fold Here and Tape

IJllmaamDlM

-----------------------------Ill-Ill----------::~::E---NECESSARY
IF MAILED IN THE
UNITED STATES

BUSINESS REPLY MAIL
FIRST-CLASS MAIL PERMIT NO. 33 MAYNARD MA
POSTAGE WILL BE PAID BY ADDRESSEE

DIGITAL EQUIPMENT CORPORATION
OPEN SOFTWARE PUBLICATIONS MANAGER
ZK03-2/Z04
110 SPIT BROOK ROAD
NASHUA NH 03062-9987

1IIIIIIIIIIIIIIIIIIIIIIhlhilihllllllhllllhllill
-------.

Do Not Tear - Fold Here

Cut
Along
Dotted
Line