The Transport Interface provides two modes of service: connection mode and connectionless mode.

Connection mode is circuit-oriented and enables the transmission of data over an established connection in a reliable, sequenced manner. It also provides an identification procedure 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, datastream-oriented interactions. Connection-mode service is analogous to BSD's “stream sockets” (as opposed to datagram sockets), which provide a stream of data instead of isolated data units.

Connectionless mode, by contrast, is message-oriented and supports data transfer in self-contained units with no logical relationship 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. This mode corresponds to sending datagrams in the sockets paradigm. 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 (which need not relate to any other service access). Each unit of data transmitted is entirely self-contained, like datagrams transmitted through BSD datagram sockets. Connectionless-mode service is attractive for applications that:

Local Management

The local management phase defines local operations between a transport user and a transport provider. For example, a user must establish a channel of communication with the transport provider, as illustrated in Figure 9-3. Each channel between a transport user and transport provider is a unique endpoint of communication, and is called the transport endpoint. The t_open() routine (see t_open(3)) enables a user to choose a particular transport provider that supplies the connection-mode service, and establishes the transport endpoint.

Figure 9-3. Channel between User and Provider

Another necessary local function for each user is to establish an identity with the transport provider. Each user is identified by a transport address. More accurately, a transport 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 can be anything from a simple character string (such as “file_server”) to 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 routines are available to support local operations. Table 9-1 summarizes all local management routines of the Transport Interface.

Table 9-1. Local Management Routines for the Transport Interface

Routine	Description
t_alloc()	Allocates Transport Interface data structures
t_bind()	Binds a transport address to a transport endpoint
t_close()	Closes a transport endpoint
t_error()	Prints a Transport Interface error message
t_free()	Frees structures allocated using t_alloc()
t_getinfo()	Returns a set of parameters associated with a particular transport provider
t_getstate()	Returns the state of a transport endpoint
t_look()	Returns the current event on a transport endpoint
t_open()	Establishes a transport endpoint connected to a chosen transport provider
t_optmgmt()	Negotiates protocol-specific options with the transport provider
t_sync()	Synchronizes a transport endpoint with the transport provider
t_unbind()	Unbinds a transport address from a transport endpoint

Connection Establishment

The connection establishment phase enables two users to create a connection, or virtual circuit, between them, as demonstrated in Figure 9-4.

Figure 9-4. Transport Connection

This phase is illustrated in the following description of a client/server relationship. The client application and the server application are users of their respective transport providers. One user, the server, typically advertises some service to a group of users, and then listens for requests from those users. When a client requires the service, the client attempts to connect itself to the server using the server's advertised transport address. The t_connect() routine (see t_connect(3N)) initiates the connect request. One argument to t_connect(), the transport address, identifies the server the client wishes to access. The server is notified of each incoming request using t_listen() and can call t_accept() (see t_listen(3N) and t_accept(3N)) to accept the client's request for access to the service. If the request is accepted, the transport connection is established.

Table 9-2 summarizes all routines available for establishing a transport connection.

Table 9-2. Routines for Establishing a Transport Connection

Routine	Description
t_accept()	Accepts a request for a transport connection
t_connect()	Establishes a connection with the transport user at a specified destination
t_listen()	Retrieves an indication of a connect request from another transport user
t_rcvconnect ()	Completes connection establishment if t_connect() was called in asynchronous mode (see “Advanced Topics” )

The Transport Interface has two components:

The state transition rules can be found in the state tables under “State Transitions”. 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: Any user of the Transport Interface must completely understand all possible state transitions before writing software using the interface.

---

Before the client and server can establish a transport connection, each must first establish a local channel (the transport endpoint) to the transport provider using t_open() and establish its identity (or address) using t_bind().

The set of services supported by the Transport Interface may not be implemented by all transport protocols. Each transport provider has a set of characteristics associated with it that determines the services it offers and the limits associated with those services. This information is returned to the user by t_open() and consists of the following:

The three service types (servtype) defined by the Transport Interface are as follows:

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 such service can be associated with the transport provider identified by t_open(). Note: t_open() returns the default provider characteristics associated with a transport endpoint. However, some characteristics can change after an endpoint has been opened. This occurs if the characteristics are associated with negotiated options (option negotiation is described later in this section). For example, if the support of expedited data transfer is a negotiated option, the value of this characteristic can change. t_getinfo() can be called to retrieve the current characteristics of a transport endpoint.

Once a user establishes a transport endpoint with the chosen transport provider, it must establish its identity. As mentioned earlier, t_bind() does this by binding a transport address to the transport endpoint. In addition, for servers, this routine informs the transport provider that the endpoint will be used to listen for incoming connect indications, also called connect requests.

An optional facility, t_optmgmt() (see t_optmgmt(3N)), is also available during the local management phase. It 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.

#include <stdio.h>
#include <tiuser.h>
#include <fcntl.h>

#define SRV_ADDR  1     /* server's well-known address */

void main() 
{
    int fd;
    int nbytes;
    int flags = 0;
    char buf[1024];
    struct t_call *sndcall;
    extern int t_errno;
if ((fd = t_open("/dev/ticotsord", O_RDWR, NULL)) < 0) {
        t_error("t_open failed");
        exit(1);
    } 

    if (t_bind(fd, NULL, NULL) < 0) {
        t_error("t_bind failed");
        exit(2);
    }

The Server

The server in Example 9-2 must take similar local management steps before communication can begin. The server must establish a transport endpoint through which it listens for connect indications. The necessary definitions and local management steps are shown in Example 9-2.

Example 9-2. The Connection-Mode Server Definitions and Local Management

#include <tiuser.h> #include <stropts.h> #include <fcntl.h> #include <stdio.h> #include <signal.h> #define DISCONNECT -1 #define SRV_ADDR 1 /* server's well-known address */ int conn_fd; /* connection established here */ extern int t_errno; void main() { int listen_fd; /* listening transport endpoint */ struct t_bind *bind; struct t_call *call; if ((listen_fd = t_open("/dev/ticotsord", O_RDWR, NULL)) < 0) { t_error("t_open failed for listen_fd"); exit(1); } /* * By assuming that the address is an integer value, * this program may not run over another protocol. */ if ((bind = (struct t_bind *)t_alloc(listen_fd, T_BIND, T_ALL))== NULL) { t_error("t_alloc of t_bind structure failed"); exit(2); } bind->qlen = 1; bind->addr.len = sizeof(int); *(int *)bind->addr.buf = SRV_ADDR; if (t_bind(listen_fd, bind, bind) < 0) { t_error("t_bind failed for listen_fd"); exit(3); } /* Was the correct address bound? */ if (*(int *)bind->addr.buf != SRV_ADDR) { fprintf(stderr, "t_bind bound wrong address\n"); exit(4); }

As with the client, the first step is to call t_open() to establish a transport endpoint with the desired transport provider. This endpoint, listen_fd, is used to listen for connect indications. Next, the server must bind its well-known address to the endpoint. This address is used by each client to access the server. The second argument to 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; }

addr describes the address to be bound, and qlen specifies the maximum outstanding connect indications that can arrive at this endpoint. All Transport Interface structure and constant definitions are found in <tiuser.h>.

The address is specified using a netbuf structure that contains the following members:

struct netbuf { unsigned int maxlen; unsigned int len; char *buf; }

buf points to a buffer containing the data, len specifies the number of bytes of data in the buffer, and maxlen specifies the maximum number of bytes the buffer can hold (and need only be set when data is returned to the user by a Transport Interface routine). For the t_bind structure, the data pointed to by buf identifies a transport address. The structure of addresses is likely to vary between protocol implementations under the Transport Interface; the netbuf structure is intended to support any address structure.

If the value of qlen is greater than 0, the transport endpoint can be used to listen for connect indications. In such cases, t_bind() directs the transport provider to begin queueing connect indications destined for the bound address immediately. Furthermore, the value of qlen specifies the maximum outstanding connect indications the server wishes to process. The server must respond to each connect indication, either accepting or rejecting the request for connection. An outstanding connect indication is one to which the server has not yet responded. Often, a server fully processes a single connect indication and responds to it before receiving the next indication. When this occurs, a value of 1 is appropriate for qlen. However, some servers may wish to retrieve several connect indications before responding to any of them. In such cases, qlen specifies the maximum number of outstanding indications the server processes. An example of a server that manages multiple outstanding connect indications is presented in “Advanced Topics”.

t_alloc() is called to allocate the t_bind structure needed by t_bind(). t_alloc() takes three arguments. The first is a file descriptor that references a transport endpoint. This is used to access the characteristics of the transport provider (see t_open(3N)). The second argument identifies the appropriate Transport Interface structure to be allocated. The third argument specifies which, if any, netbuf buffers should be allocated for that structure. T_ALL specifies that all netbuf buffers associated with the structure should be allocated, and causes the addr buffer to be allocated in this example. The size of this buffer is determined from the transport provider characteristic that defines the maximum address size. The maxlen field of this netbuf structure is set to the size of the buffer allocated by t_alloc(). The use of t_alloc() helps ensure the compatibility of user programs with future releases of the Transport Interface.

The server in this example processes connect indications one at a time, so qlen is set to 1. The address information is then assigned to the newly allocated t_bind structure. This t_bind structure is passed to t_bind() as both the second and third arguments; as the second argument, it contains information for t_bind(), while as the third argument, it returns information to the user.

On return, the t_bind structure contains whatever address was bound to the transport endpoint. If the provider can't bind the requested address (perhaps because it's already bound to another transport endpoint), it returns another appropriate address.

---

Note: Each transport provider manages its address space differently. Some transport providers can allow a single transport address to be bound to several transport endpoints, while others can require a unique address per endpoint. The Transport Interface supports either choice. Based on its address management rules, a provider determines if it can bind the requested address. If not, it chooses another valid address from its address space and binds it to the given transport endpoint.

---

The server must check 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() succeeds, the provider begins queueing connect indications, entering the next phase of communication, connection establishment.

The connection establishment procedures highlight the distinction between clients and servers. The Transport Interface imposes a different set of procedures in this phase for each type of transport user. The client starts the connection establishment procedure by requesting a connection to a particular server using t_connect(). The server is then notified of the client's request by calling t_listen(). The server can either accept or reject the client's request. It calls t_accept() to establish the connection, or calls t_snddis() to reject the request. The client is notified of the server's decision when t_connect() completes. For more information, see t_connect(3N), t_listen(3N), t_accept(3N), and t_snddis(3N).

The Transport Interface supports two facilities during connection establishment that are not necessarily supported by all transport providers:

/* Since it assumes that the address is an integer value,
 * this program may not run over another protocol.
 */ 
if ((sndcall = (struct t_call *)t_alloc(fd, T_CALL, T_ADDR)) == NULL) {
    t_error("t_alloc failed");
    exit(3);
}
sndcall->addr.len = sizeof(int);
*(int *)sndcall->addr.buf = SRV_ADDR;

if (t_connect(fd, sndcall, NULL) < 0) {
    t_error("t_connect failed for fd");
    exit(4);
}

struct t_call  {
    struct netbuf addr;
    struct netbuf opt;
    struct netbuf udata;
    int sequence;
}

The Server

Returning to the example, when the client calls t_connect(), a connect indication is generated on the server's listening transport endpoint. The steps required by the server to process the event are discussed below. For each client, the server accepts the connect request and spawns a server process to manage the connection as follows:

if ((call = (struct t_call *)t_alloc(listen_fd, T_CALL, T_ALL)) == NULL) { t_error("t_alloc of t_call structure failed"); exit(5); } while (1) { if (t_listen(listen_fd, call) < 0) { t_error("t_listen failed for listen_fd"); exit(6); } if ((conn_fd = accept_call(listen_fd, call)) != DISCONNECT) run_server(listen_fd); }

The server loops forever, processing each connect indication. First, the server calls t_listen() to retrieve the next connect indication. When one arrives, the server calls accept_call() to accept the connect request. accept_call() accepts the connection on an alternate transport endpoint (as discussed below) and returns the value of that endpoint. conn_fd is a global variable that identifies the transport endpoint where the connection is established. Because the connection is accepted on an alternate endpoint, the server can continue listening for connect indications on the endpoint that was bound for listening. If the call is accepted without error, run_server() spawns a process to manage the connection.

The server allocates a t_call structure to be used by t_listen(). The third argument to t_alloc(), T_ALL, specifies that all necessary buffers should be allocated for retrieving the caller's address, options, and user data. As mentioned earlier, the transport provider in this example does not support the transfer of user data during connection establishment, and also does not support any protocol options. Therefore, t_alloc() does not allocate buffers for the user data and options. It must, however, allocate a buffer large enough to store the address of the caller. t_alloc() determines the buffer size from the addr characteristic returned by t_open(). The maxlen field of each netbuf structure is set to the size of the buffer allocated by t_alloc() (maxlen is 0 for the user data and options buffers).

Using the t_call structure, the server calls t_listen() to retrieve the next connect indication. If one is currently available, it is returned to the server immediately. Otherwise, t_listen() blocks until a connect indication arrives.

The Transport Interface supports an asynchronous mode for these routines, which prevents a process from blocking. This feature is discussed in “Advanced Topics”.

When a connect indication arrives, the server calls accept_call() to accept the client's request, as follows:

int accept_call(listen_fd, call) int listen_fd; struct t_call *call; { int resfd; if ((resfd = t_open("/dev/ticotsord", O_RDWR, NULL)) < 0) { t_error("t_open for responding fd failed"); exit(7); } if (t_bind(resfd, NULL, NULL) < 0) { t_error("t_bind for responding fd failed"); exit(8); } if (t_accept(listen_fd, resfd, call) < 0) { if (t_errno == TLOOK) { /* must be a disconnect */ if (t_rcvdis(listen_fd, NULL) < 0) { t_error("t_rcvdis failed for listen_fd"); exit(9); } if (t_close(resfd) < 0) { t_error("t_close failed for responding fd"); exit(10); } /* go back up and listen for other calls */ return(DISCONNECT); } t_error("t_accept failed"); exit(11); } return(resfd); }

accept_call() takes two arguments:

• listen_fd identifies the transport endpoint where the connect indication arrived

• call is a pointer to a t_call structure that contains all information associated with the connect indication.

The server first establishes another transport endpoint by opening the clone device node of the transport provider and binding an address. As with the client, a NULL value is passed to t_bind() to specify that the user does not care what address is bound by the provider. The newly established transport endpoint, resfd, is used to accept the client's connect request.

The first two arguments of t_accept() specify the listening transport endpoint and the endpoint where the connection is accepted, respectively. A connection can be accepted on the listening endpoint, but this prevents other clients from accessing the server for the duration of the connection.

The third argument of t_accept() points to the t_call structure associated with the connect indication. This structure should contain the address of the calling user and the sequence number returned by t_listen(). The sequence number is significant if the server manages multiple outstanding connect indications. “Advanced Topics” presents an example of this situation. Also, the t_call structure should identify protocol options the user has requested and user data that can be passed to the client. Because the transport provider in this example does not support protocol options or the transfer of user data during connection establishment, the t_call structure returned by t_listen() can be passed without change to t_accept().

For simplicity in the example, the server exits if either the t_open() or t_bind() call fails. exit() closes the transport endpoint associated with listen_fd, causing the transport provider to pass a disconnect indication to the client that requested the connection. This disconnect indication notifies the client that the connection was not established; t_connect() fails, setting t_errno to TLOOK.

t_accept() can fail if an asynchronous event has occurred on the listening transport endpoint before the connection is accepted, and t_errno is set to TLOOK. The state transition table in “State Transitions” shows that the only event that can occur in this state with only one outstanding connect indication is a disconnect indication. This event can occur if the client decides to undo the connect request it had previously sent. If a disconnect indication arrives, the server must retrieve the disconnect indication using t_rcvdis(). This routine takes a pointer to a t_discon structure as an argument, which is used to retrieve information associated with a disconnect indication. In this example, however, the server does not care to retrieve this information, so it sets the argument to NULL. After receiving the disconnect indication, accept_call() closes the responding transport endpoint and returns DISCONNECT, which informs the server that the connection was disconnected by the client. The server then listens for further connect indications.

Figure 9-5 illustrates how the server establishes connections.

Figure 9-5. Listening and Responding Transport Endpoints

The transport connection is established on the newly created responding endpoint, and the listening endpoint is freed to retrieve further connect indications.

Once the connection is established, both the client and server can begin transferring data over the connection using t_snd() and t_rcv(). The Transport Interface does not differentiate the client from the server from this point on. Either user can send and receive data or release the connection. The Transport Interface guarantees reliable, sequenced delivery of data over an existing connection.

Two classes of data can be transferred over a transport connection: normal data and expedited data.

Expedited data is typically associated with urgent information. The exact semantics of expedited data are subject to the interpretations of the transport provider. Furthermore, not all transport protocols support the notion of an expedited data class (see t_open(3N)).

All transport protocols support the transfer of data in byte stream mode, where byte stream implies no concept of message boundaries on data that's transferred over a connection. However, some transport protocols support the preservation of message boundaries over a transport connection. This service is supported by the Transport Interface, but protocol-independent software must not rely on its existence.

The message interface for data transfer is supported by a special flag of t_snd() and t_rcv() called T_MORE. The messages, called Transport Service Data Units ( TSDU), can be transferred between two transport users as distinct units. The maximum TSDU size is a characteristic of the underlying transport protocol. This information is available to the user from t_open() and t_getinfo(). Because the maximum size can be large (possibly unlimited), the Transport Interface allows a user to transmit a message in multiple units.

To send a message in multiple units over a transport connection, the user must set the T_MORE flag on every t_snd() call except the last. This flag specifies that the user will send more data associated with the message in a subsequent call to t_snd(). The last message unit should be transmitted with T_MORE turned off to specify that this is the end of the TSDU.

Similarly, a TSDU can be passed in multiple units to the receiving user. Again, if t_rcv() returns with the T_MORE flag set, the user should continue calling t_rcv() to retrieve the remainder of the message. The last unit in the message is identified by a call to t_rcv() that does not set T_MORE.

---

Note: The T_MORE flag implies nothing about how the data can be packaged below the Transport Interface or how the data can be delivered to the receiver. Each transport protocol, and each implementation of that protocol, can package and deliver the data differently.

---

For example, if a user sends a complete message in a single call to t_snd(), there is no guarantee that the transport provider will deliver the data in a single unit to the remote transport user. Similarly, a message transmitted in two message units can be delivered in a single unit to the remote transport user. The message boundaries can only be preserved by noting the value of the T_MORE flag on t_snd() and t_rcv(). This guarantees that the receiving user sees a message with the same contents and message boundaries as that sent by the sender.

while ((nbytes = t_rcv(fd, buf, 1024, &flags)) != -1) {
    if (fwrite(buf, 1, nbytes, stdout) < 0) {
        fprintf(stderr, "fwrite failed\n");
        exit(5);
    }
}

void connrelease()
{
    /* conn_fd is global because needed here */
    if (t_look(conn_fd) == T_DISCONNECT) {
        fprintf(stderr, "connection aborted\n");
        exit(12);
    }     /* else orderly release indication - normal exit */
    exit(0);
 }

int run_server(listen_fd)
int listen_fd;
{
    int nbytes;
    FILE *logfp;           /* file pointer to log file */
    char buf[1024];

    switch (fork()) {

    case -1:
        perror("fork failed");
        exit(20);

    default:   /* parent */ 

        /* close conn_fd and then go up and listen again */ 
        if (t_close(conn_fd) < 0) {
            t_error("t_close failed for conn_fd");
            exit(21);
        } 
        return;

    case 0:     /* child */ 

        /* close listen_fd and do service */ 
        if (t_close(listen_fd) < 0) {
            t_error("t_close failed for listen_fd");
            exit(22);
        } 
        if ((logfp = fopen("logfile", "r")) == NULL) {
            perror("cannot open logfile");
            exit(23);
        }
        signal(SIGPOLL, connrelease);
        if (ioctl(conn_fd, I_SETSIG, S_INPUT) < 0) {
            perror("ioctl I_SETSIG failed");
            exit(24);
        }
        /* was disconnect there? */
        if (t_look(conn_fd) != 0) {
            fprintf(stderr, "t_look: unexpected event\n");
            exit(25);
        } 
        while ((nbytes = fread(buf, 1, 1024, logfp)) > 0) 
            if (t_snd(conn_fd, buf, nbytes, 0) < 0) {
                t_error("t_snd failed");
                exit(26);
            }

At any point during data transfer, either user can release the transport connection and end the conversation. As mentioned earlier, two forms of connection release are supported by the Transport Interface:

All transport providers must support the abortive release procedure, but orderly release is an optional facility that is not supported by all transport protocols.

        if (t_sndrel(conn_fd) < 0) {
            t_error("t_sndrel failed");
            exit(27);
        } 
        pause();
    /* until orderly release indication arrives */
    }

    if ((t_errno == TLOOK)  &&  (t_look(fd) == T_ORDREL)) {
        if (t_rcvrel(fd) < 0) {
            t_error("t_rcvrel failed");
            exit(6);
        }
        if (t_sndrel(fd) < 0) {
            t_error("t_sndrel failed");
            exit(7);
        }
        exit(0);
    }
    t_error("t_rcv failed");
    exit(8);

Just as with connection-mode service, the transport users must do appropriate local management steps before transferring data. A user must choose the appropriate connectionless service provider using t_open() and establish its identity using t_bind(). See the t_open(3N) man page or the other “Local Management” section of this chapter (under “Introduction to Connection-Mode Service”) for information about what t_open() returns.

t_optmgmt() can be used to negotiate protocol options associated with the transfer of each data unit. As with the connection-mode service, each transport provider specifies the options, if any, that it supports. Option negotiation is therefore a protocol-specific activity.

The definitions and local management calls needed by the transaction server are shown in Example 9-4:

#include <stdio.h>
#include <fcntl.h> 
#include <tiuser.h> 

#define SRV_ADDR  2     /* server's well-known address */

void main()
{
    int fd;
    int flags;

    struct t_bind *bind;
    struct t_unitdata *ud;
    struct t_uderr *uderr;

    extern int t_errno;

    if ((fd = t_open("/dev/ticlts", O_RDWR, NULL)) < 0) {
        t_error("unable to open /dev/provider");
        exit(1);
    }

    if ((bind = (struct t_bind *)t_alloc(fd, T_BIND,
                T_ADDR)) == NULL)   {
        t_error("t_alloc of t_bind structure failed");
        exit(2);
    } 

    bind->addr.len = sizeof(int);
    *(int *)bind->addr.buf = SRV_ADDR;
    bind->qlen = 0;

    if (t_bind(fd, bind, bind) < 0)  {
        t_error("t_bind failed");
        exit(3);
    } 

    /*
     * is the bound address correct?
     */ 

    if (*(int *)bind->addr.buf != SRV_ADDR)
    {
        fprintf(stderr, "t_bind bound wrong address\n");
        exit(4);
    }

The local management steps should look familiar by now. The server establishes a transport endpoint with the desired transport provider using t_open(). Each provider has an associated service type, so the user can choose a particular service by opening the appropriate transport provider file. This connectionless-mode server ignores the characteristics of the provider returned by t_open() in the same way as the users in the connection-mode example, by setting the third argument to NULL. For simplicity, the transaction server assumes the transport provider has the following characteristics:

The connectionless server also binds a transport address to the endpoint so that potential clients can identify and access the server. A t_bind structure is allocated using t_alloc(), and the buf and len fields of the address are set accordingly.

One important difference between the connection-mode server and this connectionless-mode server is that the qlen field of the t_bind structure has no meaning for connectionless-mode service, since all users are capable of receiving datagrams once they have bound an address. The Transport Interface defines an inherent client/server relationship between two users while establishing a transport connection in the connection-mode service. However, no such relationship exists in the connectionless-mode service. It is the context of this example, not the Transport Interface, that defines one user as a server and another as a client.

Because the address of the server is known by all potential clients, the server checks the bound address returned by t_bind() to ensure it is correct.

Once a user has bound an address to the transport endpoint, datagrams can be sent or received over that endpoint. Each outgoing message is accompanied by the address of the destination user. In addition, the Transport Interface enables a user to specify protocol options that should be associated with the transfer of the data unit (for example, transit delay). As discussed earlier, 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.

The sequence of calls in Example 9-5 illustrates the data transfer phase of the connectionless-mode server:

if ((ud = (struct t_unitdata *)t_alloc(fd, T_UNITDATA,
                                       T_ALL)) == NULL)  {
        t_error("t_alloc of t_unitdata structure failed");
        exit(5);
} 

if ((uderr = (struct t_uderr *)t_alloc(fd, T_UDERROR,
                                       T_ALL)) == NULL)  {
        t_error("t_alloc of t_uderr structure failed");
        exit(6);
} 

    while (1)  {
        if (t_rcvudata(fd, ud, &flags) < 0)  {
            if (t_errno == TLOOK)  {
                /* Error on previously sent datagram */
                if (t_rcvuderr(fd, uderr) < 0)  {
                    exit(7);
                }
                fprintf(stderr, "bad datagram, \
                 error = %d\n", uderr->error);
                continue;
            }
            t_error("t_rcvudata failed");
            exit(8);
        } 

        /*
         * Query() processes the request and places the
         * response in ud->udata.buf, setting ud->udata.len
         */ 

        query(ud);

        if (t_sndudata(fd, ud < 0)  {
            t_error("t_sndudata failed");
            exit(9);
        }
    }
}
query()
{
    /* Merely a stub for simplicity */ 
}

The server must first allocate a t_unitdata structure for storing datagrams, which has the following format:

struct t_unitdata {
    struct netbuf addr;
    struct netbuf opt;
    struct netbuf udata;
}

addr holds the source address of incoming datagrams and the destination address of outgoing datagrams, opt identifies any protocol options associated with the transfer of the datagram, and udata holds the data itself. The addr, opt, and udata fields must all be allocated with buffers large enough to hold any possible incoming values. As described in the previous section, the T_ALL argument to t_alloc() ensures this and sets the maxlen field of each netbuf structure accordingly. Because the provider does not support protocol options in this example, no options buffers are allocated, and maxlen is set to zero in the netbuf structure for options. The server also allocates a t_uderr structure for processing any datagram errors, as discussed later in this section.

The transaction server loops forever, receiving queries, processing the queries, and responding to the clients. It first calls t_rcvudata() to receive the next query. t_rcvudata() retrieves the next available incoming datagram. If none is currently available, t_rcvudata() blocks, waiting for a datagram to arrive. The second argument of t_rcvudata() identifies the t_unitdata structure in which the datagram should be stored.

The third argument, flags, must point to an integer variable and can be set to T_MORE on return from t_rcvudata() to specify that the user's udata buffer was not large enough to store the full datagram. In this case, subsequent calls to t_rcvudata() retrieve the remainder of the datagram. Because t_alloc() allocates a udata buffer large enough to store the maximum datagram size, the transaction server does not have to check the value of flags.

If a datagram is received successfully, the transaction server calls the query() routine to process the request. This routine stores the response in the structure pointed to by ud, and sets ud–>udata.len to the number of bytes in the response. The source address returned by t_rcvudata() in ud–>addr is used as the destination address by t_sndudata().

When the response is ready, t_sndudata() is called to return the response to the client. The Transport Interface prevents a user from flooding the transport provider with datagrams using the same flow control mechanism described for the connection-mode service. In such cases, t_sndudata() blocks until the flow control is relieved, and then resumes its operation.

If the transport provider cannot process a datagram that was passed to it by t_sndudata(), it returns a unit data error event, T_UDERR, to the user. This event includes the destination address and options associated with the datagram, plus a protocol-specific error value that describes what could be wrong with the datagram. The reason a datagram could not be processed is protocol-specific. One reason can be that the transport provider could not interpret the destination address or options. Each transport protocol is expected to specify all reasons why it is unable to process a datagram.

---

Note: The unit data error indication is not necessarily intended to indicate success or failure in delivering the datagram to the specified destination. The transport protocol decides how the indication is used. Remember, the connectionless service does not guarantee reliable delivery of data.

---

The transaction server is notified of this error event when it attempts to receive another datagram. In this case, t_rcvudata() fails, setting t_errno to TLOOK. If TLOOK is set, the only possible event is T_UDERR, so the server calls t_rcvuderr() to retrieve the event. The second argument to t_rcvuderr() is the t_uderr structure that was allocated earlier. This structure is filled in by t_rcvuderr() and has the following format:

struct t_uderr  {
    struct netbuf addr;
    struct netbuf opt;
    long error;
 }

addr and opt identify the destination address and protocol options as specified in the bad datagram, and error is a protocol-specific error code that specifies why the provider could not process the datagram. The transaction server prints the error code and then continues by entering the processing loop again.

The user can transmit data over the transport connection using write(). The tirdwr module passes data through to the transport provider. However, if a user attempts to send a zero-length data packet, which the STREAMS mechanism allows, tirdwr discards the message. If the transport connection is aborted (for example, because the other user aborts the connection using t_snddis()), a STREAMS hangup condition is generated on that Stream, and further write() calls fail and set errno to ENXIO. The user can still retrieve any available data after a hangup.

read() can be used to retrieve data that has arrived over the transport connection. The tirdwr module passes data through to the user from the transport provider. However, any other event or indication passed to the user from the provider is processed by tirdwr as follows:

With tirdwr on a Stream, the user can send and receive data over a transport connection for the duration of that connection. Either user can terminate the connection by closing the file descriptor associated with the transport endpoint or by popping the tirdwr module off the Stream. In either case, tirdwr takes the following actions:

A process cannot initiate an orderly release after tirdwr is pushed onto a Stream, but tirdwr handles an orderly release properly if it is initiated by the user on the other side of a transport connection. If the client described in this section is communicating with the server program in “Introduction to Connection-Mode Service”, that server terminates the transfer of data with an orderly release request. The server then waits for the corresponding indication from the client. At that point, the client exits and the transport endpoint is closed. When the file descriptor is closed, as explained in the first bulleted item above, tirdwr initiates the orderly release request from the client's side of the connection. This generates the indication that the server is expecting, and the connection is released properly.

Many Transport Interface library routines can block waiting for an incoming event or the relaxation of flow control. However, some time-critical applications should not block for any reason. Similarly, an application may wish to do local processing while waiting for some asynchronous transport interface event.

Support for asynchronous processing of Transport Interface events is available to applications using a combination of the STREAMS asynchronous features and the nonblocking mode of the Transport Interface library routines. Earlier examples in this chapter have illustrated the use of the poll() system call and the I_SETSIG ioctl() command for processing events asynchronously.

In addition, any Transport Interface routine that can block while waiting for some event can be run in a special nonblocking mode. For example, t_listen() normally blocks waiting for a connect indication. However, a server can periodically poll a transport endpoint for existing connect indications by calling t_listen() in the nonblocking (or asynchronous) mode. The asynchronous mode is enabled by setting O_NDELAY or O_NONBLOCK on the file descriptor. These can be set as a flag on t_open() or by calling fcntl() (see fcntl(2)) before calling the Transport Interface routine. fcntl() can be used to enable or disable this mode at any time. All programming examples in this chapter use the default synchronous processing mode.

O_NDELAY or O_NONBLOCK affect each Transport Interface routine differently. To determine the exact semantics of O_NDELAY or O_NONBLOCK for a particular routine, see the relevant manual pages.

The example in Example 9-6 demonstrates two important concepts. The first is a server's ability to manage multiple outstanding connect indications. The second is an illustration of the ability to write event-driven software using the Transport Interface and the system call interface.

The server example in Example 9-6 is capable of supporting only one outstanding connect indication, but the Transport Interface supports the ability to manage multiple outstanding connect indications. One reason a server might wish to receive several simultaneous connect indications is to impose a priority scheme on each client. A server can retrieve several connect indications, and then accept them in an order based on a priority associated with each client. A second reason for handling several outstanding connect indications is that the single-threaded scheme has some limitations. Depending on the implementation of the transport provider, it is possible that while the server is processing the current connect indication, other clients will find it busy. If, however, multiple connect indications can be processed simultaneously, the server will be found to be busy only if the maximum allowed number of clients attempt to call the server simultaneously.

The server example in Example 9-6 is event-driven: the process polls a transport endpoint for incoming Transport Interface events, and then takes the appropriate actions for the current event. The example demonstrates the ability to poll multiple transport endpoints for incoming events.

The definitions and local management functions needed by the example in Example 9-6 are similar to those of the server example in Example 9-4.

#include <tiuser.h>
#include <fcntl.h>
#include <stdio.h>
#include <poll.h>
#include <stropts.h>
#include <signal.h>

#define NUM_FDS        1
#define MAX_CONN_IND   4
#define SRV_ADDR       1    /* server's well-known address */

int conn_fd;                /* server connection here */
extern int t_errno;

/* holds connect indications */
struct t_call  *calls[NUM_FDS][MAX_CONN_IND];

void main()
{
    struct pollfd pollfds[NUM_FDS];
    struct t_bind *bind;
    int i;

    /*
     * Only opening and binding one transport endpoint,
     * but more could be supported
     */
    if ((pollfds[0].fd = t_open("/dev/ticotsord", O_RDWR,
                                NULL)) < 0) {
        t_error("t_open failed");
        exit(1);
    } 

    if ((bind = (struct t_bind *)t_alloc(pollfds[0].fd,
          T_BIND, T_ALL)) == NULL) {
        t_error("t_alloc of t_bind structure failed");
        exit(2);
    }
    bind->qlen = MAX_CONN_IND;
    bind->addr.len = sizeof(int);
    *(int *)bind->addr.buf = SRV_ADDR;

    if (t_bind(pollfds[0].fd, bind, bind) < 0)  {
        t_error("t_bind failed");
        exit(3);
    }

    /* Was the correct address bound? */ 
    if (*(int *)bind->addr.buf != SRV_ADDR)  {
        fprintf(stderr, "t_bind bound wrong address\n");
        exit(4);
    }

The file descriptor returned by t_open() is stored in a pollfd structure (see poll(2)) that polls the transport endpoint for incoming data. Notice that only one transport endpoint is established in this example. However, the remainder of the example is written to manage multiple transport endpoints. Several endpoints could be supported with minor changes to the above code.

An important aspect of this server is that it sets qlen to a value greater than 1 for t_bind(). This specifies that the server is willing to handle multiple outstanding connect indications. Remember that the earlier examples single-threaded the connect indications and responses. The server accepted the current connect indication before retrieving additional connect indications. This example, however, can retrieve up to MAX_CONN_IND connect indications at one time before responding to any of them. The transport provider can negotiate the value of qlen downward if it cannot support MAX_CONN_IND outstanding connect indications.

Once the server has bound its address and is ready to process incoming connect requests, it performs the following:

    pollfds[0].events = POLLIN;
    while (1) {
        if (poll(pollfds, NUM_FDS, -1) < 0)  {
            perror("poll failed");
            exit(5);
        }
        for (i = 0; i < NUM_FDS; i++)  {

            switch (pollfds[i].revents)  {

            default:
                perror("poll returned error event");
                exit(6);

            case 0:
                continue;

            case POLLIN:
                do_event(i, pollfds[i].fd);
                service_conn_ind(i, pollfds[i].fd);
            }
        }
    }
}

The events field of the pollfd structure is set to POLLIN, which notifies the server of any incoming Transport Interface events. The server then enters an infinite loop, in which it poll()s the transport endpoint(s) for events, and then processes those events as they occur.

The poll() call blocks indefinitely, waiting for an incoming event. On return, each entry (corresponding to each transport endpoint) is checked for an existing event. If revents is set to 0, no event has occurred on that endpoint. In this case, the server continues to the next transport endpoint. If revents is set to POLLIN, an event does exist on the endpoint. In this case, do_event() is called to process the event. If revents contains any other value, an error must have occurred on the transport endpoint, and the server exits.

For each iteration of the loop, if any event is found on the transport endpoint, service_conn_ind() is called to process any outstanding connect indications. However, if another connect indication is pending, service_conn_ind() saves the current connect indication and responds to it later. This routine is explained shortly. If an incoming event is discovered, the routine in Example 9-7 is called to process it.

do_event(slot, fd)
{
    struct t_discon *discon;
    int i;

    switch (t_look(fd))  {

    default:
        fprintf(stderr,"t_look: unexpected event\n");
        exit(7);

    case T_ERROR:
        fprintf(stderr,"t_look returned T_ERROR event\n");
        exit(8);

    case -1:
        t_error("t_look failed");
        exit(9);

    case 0:
        /* since POLLIN returned, this should not happen */
        fprintf(stderr, "t_look returned no event\n");
        exit(10);

    case T_LISTEN:
         /* find free element in calls array */

        for (i = 0; i < MAX_CONN_IND; i++)  {
            if (calls[slot][i] == NULL)
                break;
        } 

        if ((calls[slot][i] = (struct t_call *)t_alloc(fd,
               T_CALL, T_ALL)) == NULL)   {
            t_error("t_alloc of t_call structure failed");
            exit(11);
        } 

        if (t_listen(fd, calls[slot][i]) < 0)  {
            t_error("t_listen failed");
            exit(12);
        }
        break;
    case T_DISCONNECT:
        discon = (struct t_discon *)t_alloc(fd,T_DIS,T_ALL);
        if (t_rcvdis(fd, discon) < 0)  {
            t_error("t_rcvdis failed");
            exit(13);
        }
          /* find call ind in array and delete it  */

        for (i = 0; i < MAX_CONN_IND; i++)  {
            if (discon->sequence==calls[slot][i]->sequence) {
                t_free((char*)calls[slot][i], T_CALL);
                calls[slot][i] = NULL;
            }
        }
        t_free(discon, T_DIS);
        break;
    }
}

This routine takes a number, slot, and a file descriptor, fd, as arguments. slot is used as an index into the global array calls. This array contains an entry for each polled transport endpoint, where each entry consists of an array of t_call structures that hold incoming connect indications for that transport endpoint. The value of slot is used to identify the transport endpoint.

do_event() calls t_look() to determine the Transport Interface event that has occurred on the transport endpoint specified by fd. If a connect indication (T_LISTEN event) or disconnect indication (T_DISCONNECT event) has arrived, the event is processed. Otherwise, the server prints an appropriate error message and exits.

For connect indications, do_event() scans the array of outstanding connect indications looking for the first free entry. A t_call structure is then allocated for that entry, and the connect indication is retrieved using t_listen(). There must always be at least one free entry in the connect indication array, because the array is large enough to hold the maximum number of outstanding connect indications as negotiated by t_bind(). The processing of the connect indication is deferred until later.

If a disconnect indication arrives, it must correspond to a previously received connect indication. This occurs if a client attempts to undo a previous connect request. In this case, do_event() allocates a t_discon structure to retrieve the relevant disconnect information. This structure has the following members:

struct t_discon  {
    struct netbuf udata;
    int reason;
    int sequence;
 }

udata identifies any user data that might have been sent with the disconnect indication, reason contains a protocol-specific disconnect reason code, and sequence identifies the outstanding connect indication that matches this disconnect indication.

Next, t_rcvdis() is called to retrieve the disconnect indication. The array of connect indications for slot is then scanned for one that contains a sequence number that matches the sequence number in the disconnect indication. When the connect indication is found, it is freed and the corresponding entry is set to NULL.

As mentioned earlier, if any event is found on a transport endpoint, service_conn_ind() is called to process all currently outstanding connect indications associated with that endpoint as follows:

service_conn_ind(slot, fd)
{
    int i;

    for (i = 0; i < MAX_CONN_IND; i++) {
        if (calls[slot][i] == NULL)
            continue;
        if ((conn_fd = t_open("/dev/ticotsord", O_RDWR,
                              NULL)) < 0) {
            t_error("open failed");
            exit(14);
        }
        if (t_bind(conn_fd, NULL, NULL) < 0) {
            t_error("t_bind failed");
            exit(15);
        } 
        if (t_accept(fd, conn_fd, calls[slot][i]) < 0) {
            if (t_errno == TLOOK) {
                t_close(conn_fd);
                return;
            }
            t_error("t_accept failed");
            exit(16);
        }
        t_free((char*)calls[slot][i], T_CALL);
        calls[slot][i] = NULL;

        run_server(fd);
    }
}

For the given slot (the transport endpoint), the array of outstanding connect indications is scanned. For each indication, the server opens a responding transport endpoint, binds an address to the endpoint, and then accepts the connection on that endpoint. If another event (connect indication or disconnect indication) arrives before the current indication is accepted, t_accept() fails and sets t_errno to TLOOK.

---

Note: The user cannot accept an outstanding connect indication if any pending connect indication events or disconnect indication events exist on that transport endpoint.

---

If this error occurs, the responding transport endpoint is closed and service_conn_ind() returns immediately (saving the current connect indication for later processing). This causes the server's main processing loop to be entered, and the new event is discovered by the next call to poll(). In this way, multiple connect indications can be queued by the user.

Eventually, all events are processed, and service_conn_ind() is able to accept each connect indication in turn. Once the connection is established, the run_server() routine used by the server in “Introduction to Connection-Mode Service” is called to manage the data transfer.

Table 9-6 defines the states used to describe the Transport Interface state transitions.

The outgoing events described in Table 9-7 correspond to the return of the specified transport routines, where these routines send a request or response to the transport provider.

In the table, some events (such as acceptn) are distinguished by the context in which they occur. The context is based on the values of the following variables:

The incoming events correspond to the successful return of the specified routines, where these routines retrieve data or event information from the transport provider. The only incoming event not associated directly with the return of a routine is pass_conn, which 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 Transport Interface routine is issued on that endpoint. pass_conn is included in the state tables to describe the behavior when a user accepts a connection on another transport endpoint.

In Table 9-8, the rcvdis events are distinguished by the context in which they occur. The context is based on the value of ocnt, which is the count of outstanding connect indications on the transport endpoint.

In the state tables that follow, some state transitions are accompanied by a list of actions the transport user must take. These actions are represented by the notation [x], where x is a mnemonic for the specific action:

Table 9-9, Table 9-10, and Table 9-11 describe the Transport Interface state transitions. Given a current state and an event, the transition to the next state is shown, as well as any actions that must be taken by the transport user (indicated by [x]). The state is that of the transport provider as seen by the transport user.

To see what the next state will be in a given situation, find the table cell at the intersection of the column headed by the current state and the row labeled with the current incoming or outgoing event. An empty cell represents a state/event combination that is invalid. Along with the next state, each cell can indicate one or more actions from among those listed in the previous section. The transport user must take the specific actions in the order specified in the state table.

The following should be understood when studying the state tables:

Here are the state-transition tables: one for common local management steps; one for data transfer in connectionless mode; and one for connection establishment, connection release, and data transfer in connection mode.

The code in Example 9-8 represents the connection-mode client program described in “Introduction to Connection-Mode Service”.

This client establishes a transport connection with a server, and then receives data from the server and writes that data to the client's standard output. The connection is released using the orderly release facility of the Transport Interface. This client communicates with each of the connection-mode servers presented in the guide.

#include <stdio.h>
#include <tiuser.h>
#include <fcntl.h>

#define SRV_ADDR 1   /* server's well-known address */ 

void main()
{
    int fd;
    int nbytes;
    int flags = 0;
    char buf[1024];
    struct t_call *sndcall;
    extern int t_errno;

    if ((fd = t_open("/dev/ticotsord", O_RDWR, NULL)) < 0) {
        t_error("t_open failed");
        exit(1);
    }

    if (t_bind(fd, NULL, NULL) < 0) {
        t_error("t_bind failed");
        exit(2);
    }

    /* By assuming that the address is an integer value,
     * this program may not run over another protocol. */

    if ((sndcall = (struct t_call *)t_alloc(fd, T_CALL,
        T_ADDR)) == NULL) {
        t_error("t_alloc failed");
        exit(3);
    }
    sndcall->addr.len = sizeof(int);
    *(int *)sndcall->addr.buf = SRV_ADDR;

    if (t_connect(fd, sndcall, NULL) < 0) {
        t_error("t_connect failed for fd");
        exit(4);
    } 
    while ((nbytes = t_rcv(fd, buf, 1024, &flags)) != -1){
        if (fwrite(buf, 1, nbytes, stdout) < 0){
            fprintf(stderr, "fwrite failed\n");
            exit(5);
        }
    } 
    if ((t_errno == TLOOK)  &&  (t_look(fd) == T_ORDREL)) {
        if (t_rcvrel(fd) < 0) {
            t_error("t_rcvrel failed");
            exit(6);
        }
        if (t_sndrel(fd) < 0) {
            t_error("t_sndrel failed");
            exit(7);
        }
        exit(0);
    }
    t_error("t_rcv failed");
    exit(8);
 }

The code in Example 9-9 represents the connection-mode server program described in “Introduction to Connection-Mode Service”. This server establishes a transport connection with a client, and then transfers a log file to the client on the other side of the connection. The connection is released using the orderly release facility of the Transport Interface. The connection-mode client presented earlier communicates with this server.

#include <tiuser.h>
#include <stropts.h>
#include <fcntl.h>
#include <stdio.h>
#include <signal.h>

#define DISCONNECT -1
#define SRV_ADDR  1  /* server's well-known address */

int conn_fd;         /* connection established here */
extern int t_errno;

void main()
{
    int listen_fd;   /* listening transport endpoint */
    struct t_bind *bind;
    struct t_call *call;
    if ((listen_fd = t_open("/dev/ticotsord", O_RDWR, NULL))
        < 0) {
        t_error("t_open failed for listen_fd");
        exit(1);
    }
    /*
     * By assuming that the address is an integer value,
     * this program may not run over another protocol.
     */
    if ((bind = (struct t_bind *)t_alloc(listen_fd, T_BIND,
        T_ALL)) == NULL) {
        t_error("t_alloc of t_bind structure failed");
        exit(2);
    }
    bind->qlen = 1;
    bind->addr.len = sizeof(int);
    *(int *)bind->addr.buf = SRV_ADDR;

    if (t_bind(listen_fd, bind, bind) < 0) {
        t_error("t_bind failed for listen_fd");
        exit(3);
    }

    /* Was the correct address bound? */
    if (*(int *)bind->addr.buf != SRV_ADDR) {
        fprintf(stderr, "t_bind bound wrong address\n");
        exit(4);
    }
    if ((call = (struct t_call *)t_alloc(listen_fd, T_CALL,
                                         T_ALL)) == NULL) {
        t_error("t_alloc of t_call structure failed");
        exit(5);
    }
    while (1) {
        if (t_listen(listen_fd, call) < 0) {
            t_error("t_listen failed for listen_fd");
            exit(6);
        }
        if ((conn_fd = accept_call(listen_fd, call))
            != DISCONNECT)
            run_server(listen_fd);
    }
}
 
int accept_call(listen_fd, call)
int listen_fd; struct t_call *call;
{
    int resfd;

    if ((resfd = t_open("/dev/ticotsord", O_RDWR, NULL))
        < 0) {
        t_error("t_open for responding fd failed");
        exit(7);
    }
    if (t_bind(resfd, NULL, NULL) < 0) {
        t_error("t_bind for responding fd failed");
        exit(8);
    }
    if (t_accept(listen_fd, resfd, call) < 0) {
        if (t_errno == TLOOK) {  /* must be a disconnect */
            if (t_rcvdis(listen_fd, NULL) < 0) {
                t_error("t_rcvdis failed for listen_fd");
                exit(9);
            }
            if (t_close(resfd) < 0) {
                t_error("t_close failed for responding fd");
                exit(10);
            }
            /* go back up and listen for other calls */
            return(DISCONNECT);
        }
        t_error("t_accept failed");
        exit(11);
    }
    return(resfd);
}

void connrelease()
 {
    /* conn_fd is global because needed here */
    if (t_look(conn_fd) == T_DISCONNECT) {
        fprintf(stderr, "connection aborted\n");
        exit(12);
    }
    /* else orderly release indication - normal exit */
    exit(0);
 }

int run_server(listen_fd)
int listen_fd;
{
    int nbytes;
    FILE *logfp;        /* file pointer to log file */
    char buf[1024];

    switch (fork()) {

    case -1:
        perror("fork failed");
        exit(20);

    default:    /* parent */
        /* close conn_fd and then go up and listen again */
        if (t_close(conn_fd) < 0) {
            t_error("t_close failed for conn_fd");
            exit(21);
        }
        return;

    case 0:     /* child */
        /* close listen_fd and do service */
        if (t_close(listen_fd) < 0) {
            t_error("t_close failed for listen_fd");
            exit(22);
        }

        if ((logfp = fopen("logfile", "r")) == NULL) {
            perror("cannot open logfile");
            exit(23);
        }

        signal(SIGPOLL, connrelease);
        if (ioctl(conn_fd, I_SETSIG, S_INPUT) < 0) {
            perror("ioctl I_SETSIG failed");
            exit(24);
        }
        if (t_look(conn_fd) != 0) {
            /* disconnect wasn't there */
            fprintf(stderr, "t_look: unexpected event\n");
            exit(25);
        }

        while ((nbytes = fread(buf, 1, 1024, logfp)) > 0)
            if (t_snd(conn_fd, buf, nbytes, 0) < 0) {
                t_error("t_snd failed");
                exit(26);
            }

        if (t_sndrel(conn_fd) < 0) {
            t_error("t_sndrel failed");
            exit(27);
        }
        pause(); /*until orderly release indication arrives*/
    }
 }

The code in Example 9-10 represents the connectionless-mode transaction server program described in “Introduction to Connectionless-Mode Service”.

This server waits for incoming datagram queries, and then processes each query and sends a response.

#include <stdio.h>
#include <fcntl.h>
#include <tiuser.h>

#define SRV_ADDR  2   /* server's well-known address */

void main()
{
    int fd;
    int flags;
    struct t_bind *bind;
    struct t_unitdata *ud;
    struct t_uderr *uderr;
    extern int t_errno;

    if ((fd = t_open("/dev/ticlts", O_RDWR, NULL)) < 0) {
        t_error("unable to open /dev/provider");
        exit(1);
    } 

    if ((bind = (struct t_bind *)t_alloc(fd, T_BIND,
                                         T_ADDR)) == NULL) {
        t_error("t_alloc of t_bind structure failed");
        exit(2);
    }
    bind->addr.len = sizeof(int);
    *(int *)bind->addr.buf = SRV_ADDR;
    bind->qlen = 0;

    if (t_bind(fd, bind, bind) < 0) {
        t_error("t_bind failed");
        exit(3);
    } 

    /* is the bound address correct? */
    if (*(int *)bind->addr.buf != SRV_ADDR) {
        fprintf(stderr, "t_bind bound wrong address\n");
        exit(4);
    }

    if ((ud = (struct t_unitdata *)t_alloc(fd, T_UNITDATA,
        T_ALL)) == NULL) {
        t_error("t_alloc of t_unitdata structure failed");
        exit(5);
    }
    if ((uderr = (struct t_uderr *)t_alloc(fd, T_UDERROR,
                                           T_ALL)) == NULL) {
        t_error("t_alloc of t_uderr structure failed");
        exit(6);
    } 

    while (1) 
        {
        if (t_rcvudata(fd, ud, &flags) < 0) {
            if (t_errno == TLOOK) {
                /* Error on previously sent datagram */ 
                if (t_rcvuderr(fd, uderr) < 0) {
                    t_error("t_rcvuderr failed");
                    exit(7);
                }
                fprintf(stderr, "bad datagram, \
                  error = %d\n", uderr->error);
                continue;
            } 
            t_error("t_rcvudata failed");
            exit(8);
        } 

        /* 
         * Query() processes the request and places the 
         * response in ud->udata.buf, setting ud->udata.len 
         */ 
        query(ud);

        if (t_sndudata(fd, ud < 0) {
            t_error("t_sndudata failed");
            exit(9);
        }
    }
}

query()
{
    /* Merely a stub for simplicity */
}

The code in Example 9-11 represents the connection-mode read/write client program described in “A Read/Write Interface”. This client establishes a transport connection with a server, and then uses cat to retrieve the data sent by the server and write that data to the client's standard output. This client communicates with each of the connection-mode servers presented in the guide.

#include <stdio.h>
#include <tiuser.h>
#include <fcntl.h>
#include <stropts.h>

#define SRV_ADDR  1   /* server's well-known address */

void main()
{
    int fd;
    int nbytes;
    int flags = 0;
    char buf[1024];
    struct t_call *sndcall;
    extern int t_errno;

    if ((fd = t_open("/dev/ticotsord", O_RDWR, NULL)) < 0) {
        t_error("t_open failed");
        exit(1);
    } 

    if (t_bind(fd, NULL, NULL) < 0) {
        t_error("t_bind failed");
        exit(2);
    } 

     /* By assuming that the address is an integer value,
      * this program may not run over another protocol. */ 

    if ((sndcall = (struct t_call *)t_alloc(fd, T_CALL,
        T_ADDR)) == NULL) {
        t_error("t_alloc failed");
        exit(3);
    } 

    sndcall->addr.len = sizeof(int);
    *(int *)sndcall->addr.buf = SRV_ADDR;

    if (t_connect(fd, sndcall, NULL) < 0) 
{
        t_error("t_connect failed for fd");
        exit(4);
    }
    if (ioctl(fd, I_PUSH, "tirdwr") < 0) {
        perror("I_PUSH of tirdwr failed");
        exit(5);
    } 

    close(0);
    dup(fd);

    execl("/usr/bin/cat", "/usr/bin/cat", 0);
    perror("execl of /usr/bin/cat failed");
    exit(6);
}

The code in Example 9-12 represents the connection-mode server program described in “Advanced Topics”. This server manages multiple connect indications in an event-driven manner. Either connection-mode client presented earlier communicates with this server.

#include <tiuser.h>
#include <fcntl.h>
#include <stdio.h>
#include <poll.h>
#include <stropts.h>
#include <signal.h>

#define NUM_FDS         1
#define MAX_CONN_IND    4
#define SRV_ADDR        1 /* server's well-known address */

int conn_fd;        /* server connection here */
extern int t_errno;

/* holds connect indications */
struct t_call *calls[NUM_FDS][MAX_CONN_IND];

void main()
{
    struct pollfd pollfds[NUM_FDS];
    struct t_bind *bind;
    int i;

    / * Only opening and binding one transport endpoint,
      * but more could be supported  */

    if ((pollfds[0].fd = t_open("/dev/ticotsord", O_RDWR,
        NULL)) < 0) {
        t_error("t_open failed");
        exit(1);
    }

    if ((bind = (struct t_bind *)t_alloc(pollfds[0].fd,
        T_BIND, T_ALL)) == NULL) {
        t_error("t_alloc of t_bind structure failed");
        exit(2);
    }
    bind->qlen = MAX_CONN_IND;
    bind->addr.len = sizeof(int);
    *(int *)bind->addr.buf = SRV_ADDR;

    if (t_bind(pollfds[0].fd, bind, bind) < 0) {
        t_error("t_bind failed");
        exit(3);
    }

    /* Was the correct address bound? */
    if (*(int *)bind->addr.buf != SRV_ADDR) {
        fprintf(stderr, "t_bind bound wrong address\n");
        exit(4);
    } 

    pollfds[0].events = POLLIN;

    while (1) {
        if (poll(pollfds, NUM_FDS, -1) < 0) {
            perror("poll failed");
            exit(5);
        }

        for (i = 0; i < NUM_FDS; i++) {

            switch (pollfds[i].revents) {

            default:
                perror("poll returned error event");
                exit(6);

            case 0:
                continue;

            case POLLIN:
                do_event(i, pollfds[i].fd);
                service_conn_ind(i, pollfds[i].fd);
            }
        }
    } 
} 
do_event(slot, fd) 
{
    struct t_discon *discon;
    int i;

    switch (t_look(fd)) {

    default: 
        fprintf(stderr,"t_look: unexpected event\n");
        exit(7);

    case T_ERROR:
        fprintf(stderr,"t_look returned T_ERROR event\n");
        exit(8);

    case -1:
        t_error("t_look failed");
        exit(9);

    case 0:
        /* since POLLIN returned, this should not happen */
        fprintf(stderr,"t_look returned no event\n");
        exit(10);
        case T_LISTEN:
        /* find free element in calls array */

        for (i = 0; i < MAX_CONN_IND; i++) {
            if (calls[slot][i] == NULL)
                break;
        }
        if ((calls[slot][i] = (struct t_call *)t_alloc(fd,
            T_CALL, T_ALL)) == NULL)  {
            t_error("t_alloc of t_call structure failed");
            exit(11);
        }
        if (t_listen(fd, calls[slot][i]) < 0) {
            t_error("t_listen failed");
            exit(12);
        }
        break;

    case T_DISCONNECT:
        discon = (struct t_discon *)t_alloc(fd,T_DIS,T_ALL);

        if (t_rcvdis(fd, discon) < 0) {
            t_error("t_rcvdis failed");
            exit(13);
        }
         /* find call ind in array and delete it  */

        for (i = 0; i < MAX_CONN_IND; i++) {
            if (discon->sequence==calls[slot][i]->sequence) {
                t_free((char*)calls[slot][i], T_CALL);
                calls[slot][i] = NULL;
            }
        } 
        t_free((char*)discon, T_DIS);
        break;
    }
 } 
service_conn_ind(slot, fd) 
{
    int i;
    for (i = 0; i < MAX_CONN_IND; i++) {
        if (calls[slot][i] == NULL) 
            continue;
        if ((conn_fd = t_open("/dev/ticotsord", O_RDWR,
                              NULL)) < 0){
            t_error("open failed");
            exit(14);
        }

        if (t_bind(conn_fd, NULL, NULL) < 0)  {
            t_error("t_bind failed");
            exit(15);
        }
        if (t_accept(fd, conn_fd, calls[slot][i]) < 0) {
            if (t_errno == TLOOK) {
                t_close(conn_fd);
                return;
            }
            t_error("t_accept failed");
            exit(16);
        }
        t_free((char*)calls[slot][i], T_CALL);
        calls[slot][i] = NULL;

        run_server(fd);
    }
 } 

void connrelease() 
{
    /* conn_fd is global because needed here */
    if (t_look(conn_fd) == T_DISCONNECT) {
        fprintf(stderr, "connection aborted\n");
        exit(12);
    } 

    /* else orderly release indication - normal exit */
    exit(0);
} 

int run_server(listen_fd) 
int listen_fd;
{
    int nbytes;
    FILE *logfp;        /* file pointer to log file */ 
    char buf[1024];

    switch (fork()) 
{

    case -1: 
        perror("fork failed");
        exit(20);

    default:     /* parent */

        /* close conn_fd and then go up and listen again */
        if (t_close(conn_fd) < 0) {
            t_error("t_close failed for conn_fd");
            exit(21);
        }
        return;

    case 0:     /* child */

        /* close listen_fd and do service */
        if (t_close(listen_fd) < 0) {
            t_error("t_close failed for listen_fd");
            exit(22);
        }
        if ((logfp = fopen("logfile", "r")) == NULL) {
            perror("cannot open logfile");
            exit(23);
        }

        signal(SIGPOLL, connrelease);
        if (ioctl(conn_fd, I_SETSIG, S_INPUT) < 0) {
            perror("ioctl I_SETSIG failed");
            exit(24);
        }
        /* disconnect already there? */
        if (t_look(conn_fd) != 0) {
            fprintf(stderr, "t_look: unexpected event\n");
            exit(25);
        }

        while ((nbytes = fread(buf, 1, 1024, logfp)) > 0)
            if (t_snd(conn_fd, buf, nbytes, 0) < 0){
                t_error("t_snd failed");
                exit(26);
            }

        if (t_sndrel(conn_fd) < 0) {
            t_error("t_sndrel failed");
            exit(27);
        }
        pause();
    /* until orderly release indication arrives */
    }
 }