Sockets are commonly used for client/server interaction. Typical
system configuration places the server on one machine, with the clients on
other machines. The clients connect to the server, exchange information, and
then disconnect.
A socket has a typical flow of events. In a connection-oriented client-to-server
model, the socket on the server process waits for requests from a client.
To do this, the server first establishes (binds) an address that clients can
use to find the server. When the address is established, the server waits
for clients to request a service. The client-to-server data exchange takes
place when a client connects to the server through a socket. The server performs
the client's request and sends the reply back to the client.
Note: Currently, IBM® supports two versions of most sockets APIs. The default i5/OS™ sockets
use Berkeley Socket Distribution (BSD) 4.3 structures and syntax. The other
version of sockets uses syntax and structures compatible with BSD 4.4 and
the UNIX® 98
programming interface specifications. Programmers can specify _XOPEN_SOURCE
macro to use the UNIX 98 compatible interface.
The following figure shows the typical flow of events (and the sequence
of issued functions) for a connection-oriented socket session. An explanation
of each event follows the figure.
Typical flow of events for a connection-oriented socket:
- The socket() function creates an endpoint for communications
and returns a socket descriptor that represents the endpoint.
- When an application has a socket descriptor, it can bind a unique name
to the socket. Servers must bind a name to be accessible from the network.
- The listen() function indicates a willingness to accept
client connection requests. When a listen() is issued for
a socket, that socket cannot actively initiate connection requests. The listen() API
is issued after a socket is allocated with a socket() function
and the bind() function binds a name to the socket. A listen() function
must be issued before an accept() function is issued.
- The client application uses a connect() function on
a stream socket to establish a connection to the server.
- The server application uses the accept() function to
accept a client connection request. The server must issue the bind() and
listen() functions successfully before it can issue an accept().
- When a connection is established between stream sockets (between client
and server), you can use any of the socket API data transfer functions. Clients
and servers have many data transfer functions from which to choose, such as send(), recv(), read(), write(), and others.
- When a server or client wants to cease operations, it issues a close() function
to release any system resources acquired by the socket.
Note: The socket APIs are located in the communications model between the
application layer and the transport layer. The socket APIs are not a layer
in the communication model. Socket APIs allow applications to interact with
the transport or networking layers of the typical communications model. The
arrows in the following figure show the position of a socket, and the communication
layer that the socket provides.
Typically, a network configuration does not allow connections between a
secure internal network and a less secure external network. However, you can
enable sockets to communicate with server programs that run on a system outside
a firewall (a very secure host).
Sockets are also a part of IBM's AnyNet® implementation for the Multiprotocol
Transport Networking (MPTN) architecture. MPTN architecture provides the ability
to operate a transport network over additional transport networks and to connect
application programs across transport networks of different types.