Asynchronous Networking

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.

Networking Programming Models

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 Service

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.

Making the Endpoint Asynchronous

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.

Asynchronous Network Transfers

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.

Asynchronous Connection-Mode Service

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.

Asynchronously Establishing a Connection

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.

Asynchronous Use of a 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.

Asynchronous Open

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.

Transferring a File Descriptor

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.