Programming with the X/Open Transport Interface (XTI)

Local management

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.

t_optmgmt may 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.

In the example, the definitions and local management calls needed by the transaction server are as follows:

   #include <stdio.h>
   #include <fcntl.h>
   #include <xti.h>
   
   #define SRV_ADDR	2		/* server's well known address */
   

   main()
   {
   	int fd;
   	int flags;
   

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

   	if ((fd = t_open("/dev/tidg", 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, NULL) < 0) {
   		t_error("t_bind failed");
   		exit(3);
   	}

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 may 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 transport address is an integer value that uniquely identifies each user.
The transport provider supports the T_CLTS service type (connectionless transport service, or datagram).
The transport provider does not support any protocol-specific options.

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

One important difference between the connection-mode server and this connectionless-mode server is that the qlen member 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, it is important that the bound address be the one specified in the t_bind call. Note that the XTI version of t_bind will fail if the requested address cannot be bound. Therefore, it is not necessary to check that the requested address and bound address are the same after a successful call to t_bind.