Previous topic |
Next topic |
Contents |
Contact z/OS |
Library |
PDF
Client/server socket programs: Blocking, nonblocking, and asynchronous socket calls z/OS Communications Server: IP Sockets Application Programming Interface Guide and Reference SC27-3660-00 |
||||||||||||||||||||||||||||||
A socket is in blocking mode when an I/O call waits for an event to complete. If the blocking mode is set for a socket, the calling program is suspended until the expected event completes. If nonblocking is set by the FCNTL() or IOCTL() calls, the calling program continues even though the I/O call might not have completed. If the I/O call could not be completed, it returns with ERRNO EWOULDBLOCK. (The calling program should use SELECT() to test for completion of any socket call returning an EWOULDBLOCK.) Note: The default mode is blocking.
If data is not available to the socket, and the socket is in blocking and synchronous modes, the READ call blocks the caller until data arrives. All IBM® TCP/IP Services socket APIs support nonblocking socket calls. Some APIs, in addition to nonblocking calls, support asynchronous socket calls.
Table 1 lists the actions taken by the socket programming interface.
Test pending activity on a number of sockets in a synchronous program by using the select() call. Pass the list of socket descriptors that you want to test for activity to the select() call; specify by socket descriptor the following type of activity you want test to find:
When you use select() call logic, you do not issue any socket call on a given socket until the select() call tells you that something has happened on that socket; for example, data has arrived and is ready to be read by a read() call. By using the select() call, you do not issue a blocking call until you know that the call cannot block. The select() call can itself be blocking, nonblocking, or, for the macro API, asynchronous. If the call is blocking and none of the socket descriptors included in the list passed to the select() call have had any activity, the call does not return to your program until one of them has activity, or until the timer value passed on the select() call expires. The select() call and selectex() call are available. The difference between select() and selectex() calls is that selectex() call allows you to include nonsocket related events in the list of events that can trigger the selectex() call to complete. You do so by passing one or more MVS™ event control blocks (ECBs) on the selectex() call. If there is activity on any of the sockets included in the select list, if the specified timer expires, or if one of the external events completes, the selectex() call returns to your program. Typically, a server program waits for socket activity or an operator command to shut it down. By using the selectex() call, a shutdown ECB can be included in the list of events to be monitored for activity. |
Copyright IBM Corporation 1990, 2014
|