Skip Navigation Links | |
Exit Print View | |
Programming Interfaces Guide Oracle Solaris 11.1 Information Library |
2. Session Description Protocol API
8. Programming With XTI and TLI
Advanced XTI/TLI Programming Example
Asynchronous Connectionless-Mode Service
Making the Endpoint Asynchronous
Asynchronous Network Transfers
Asynchronous Connection-Mode Service
Asynchronously Establishing a Connection
Guidelines to Protocol Independence
XTI/TLI Versus Socket Interfaces
Additions to the XTI Interface
10. Transport Selection and Name-to-Address Mapping
11. Real-time Programming and Administration
This section discusses the techniques of asynchronous network communication using XTI/TLI for real-time applications. The SunOS platform provides support for asynchronous network processing of XTI/TLI events using a combination of STREAMS asynchronous features and the non-blocking mode of the XTI/TLI library routines.
Like file and device I/O, network transfers can be done synchronously or asynchronously with process service requests.
Synchronous networking proceeds similar to synchronous file and device I/O. Like the write(2) interface, the send request returns after buffering the message, but might suspend the calling process if buffer space is not immediately available. Like the read(2) interface, a receive request suspends execution of the calling process until data arrives to satisfy the request. Because there are no guaranteed bounds for transport services, synchronous networking is inappropriate for processes that must have real-time behavior with respect to other devices.
Asynchronous networking is provided by non-blocking service requests. Additionally, applications can request asynchronous notification when a connection might be established, when data might be sent, or when data might be received.
Asynchronous connectionless mode networking is conducted by configuring the endpoint for non-blocking service, and either polling for or receiving asynchronous notification when data might be transferred. If asynchronous notification is used, the actual receipt of data typically takes place within a signal handler.
After the endpoint has been established using t_open(3NSL), and its identity established using t_bind(3NSL), the endpoint can be configured for asynchronous service. Use the fcntl(2) interface to set the O_NONBLOCK flag on the endpoint. Thereafter, calls to t_sndudata(3NSL) for which no buffer space is immediately available return -1 with t_errno set to TFLOW. Likewise, calls to t_rcvudata(3NSL) for which no data are available return -1 with t_errno set to TNODATA.
Although an application can use poll(2) to check periodically for the arrival of data or to wait for the receipt of data on an endpoint, receiving asynchronous notification when data arrives might be necessary. Use ioctl(2) with the I_SETSIG command to request that a SIGPOLL signal be sent to the process upon receipt of data at the endpoint. Applications should check for the possibility of multiple messages causing a single signal.
In the following example, protocol is the name of the application-chosen transport protocol.
#include <sys/types.h> #include <tiuser.h> #include <signal.h> #include <stropts.h> int fd; struct t_bind *bind; void sigpoll(int); fd = t_open(protocol, O_RDWR, (struct t_info *) NULL); bind = (struct t_bind *) t_alloc(fd, T_BIND, T_ADDR); ... /* set up binding address */ t_bind(fd, bind, bin /* make endpoint non-blocking */ fcntl(fd, F_SETFL, fcntl(fd, F_GETFL) | O_NONBLOCK); /* establish signal handler for SIGPOLL */ signal(SIGPOLL, sigpoll); /* request SIGPOLL signal when receive data is available */ ioctl(fd, I_SETSIG, S_INPUT | S_HIPRI); ... void sigpoll(int sig) { int flags; struct t_unitdata ud; for (;;) { ... /* initialize ud */ if (t_rcvudata(fd, &ud, &flags) < 0) { if (t_errno == TNODATA) break; /* no more messages */ ... /* process other error conditions */ } ... /* process message in ud */ }
For connection-mode service, an application can arrange not only for the data transfer, but also for the establishment of the connection itself to be done asynchronously. The sequence of operations depends on whether the process is attempting to connect to another process or is awaiting connection attempts.
A process can attempt a connection and asynchronously complete the connection. The process first creates the connecting endpoint and, using fcntl(2), configures the endpoint for non-blocking operation. As with connectionless data transfers, the endpoint can also be configured for asynchronous notification upon completion of the connection and subsequent data transfers. The connecting process then uses t_connect(3NSL) to initiate setting up the transfer. Then t_rcvconnect(3NSL) is used to confirm the establishment of the connection.
To asynchronously await connections, a process first establishes a non-blocking endpoint bound to a service address. When either the result of poll(2) or an asynchronous notification indicates that a connection request has arrived, the process can get the connection request by using t_listen(3NSL). To accept the connection, the process uses t_accept(3NSL) . The responding endpoint must be separately configured for asynchronous data transfers.
The following example illustrates how to request a connection asynchronously.
#include <tiuser.h> int fd; struct t_call *call; fd = /* establish a non-blocking endpoint */ call = (struct t_call *) t_alloc(fd, T_CALL, T_ADDR); /* initialize call structure */ t_connect(fd, call, call); /* connection request is now proceeding asynchronously */ /* receive indication that connection has been accepted */ t_rcvconnect(fd, &call);
The following example illustrates listening for connections asynchronously.
#include <tiuser.h> int fd, res_fd; struct t_call call; fd = /* establish non-blocking endpoint */ /*receive indication that connection request has arrived */ call = (struct t_call *) t_alloc(fd, T_CALL, T_ALL); t_listen(fd, &call); /* determine whether or not to accept connection */ res_fd = /* establish non-blocking endpoint for response */ t_accept(fd, res_fd, call);
Occasionally, an application might be required to dynamically open a regular file in a file system mounted from a remote host, or on a device whose initialization might be prolonged. However, while such a request to open a file is being processed, the application is unable to achieve real-time response to other events. The SunOS software solves this problem by having a second process handle the actual opening of the file, then passes the file descriptor to the real-time process.
The STREAMS interface provided by the SunOS platform provides a mechanism for passing an open file descriptor from one process to another. The process with the open file descriptor uses ioctl(2) with a command argument of I_SENDFD. The second process obtains the file descriptor by calling ioctl(2) with a command argument of I_RECVFD.
In the following example, the parent process prints out information about the test file, and creates a pipe. Next, the parent creates a child process that opens the test file and passes the open file descriptor back to the parent through the pipe. The parent process then displays the status information on the new file descriptor.
Example 8-6 File Descriptor Transfer
#include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <stropts.h> #include <stdio.h> #define TESTFILE "/dev/null" main(int argc, char *argv[]) { int fd; int pipefd[2]; struct stat statbuf; stat(TESTFILE, &statbuf); statout(TESTFILE, &statbuf); pipe(pipefd); if (fork() == 0) { close(pipefd[0]); sendfd(pipefd[1]); } else { close(pipefd[1]) recvfd(pipefd[0]); } } sendfd(int p) { int tfd; tfd = open(TESTFILE, O_RDWR); ioctl(p, I_SENDFD, tfd); } recvfd(int p) { struct strrecvfd rfdbuf; struct stat statbuf; char fdbuf[32]; ioctl(p, I_RECVFD, &rfdbuf); fstat(rfdbuf.fd, &statbuf); sprintf(fdbuf, "recvfd=%d", rfdbuf.fd); statout(fdbuf, &statbuf); } statout(char *f, struct stat *s) { printf("stat: from=%s mode=0%o, ino=%ld, dev=%lx, rdev=%lx\n", f, s->st_mode, s->st_ino, s->st_dev, s->st_rdev); fflush(stdout); }