How sockets work

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.


The two endpoints establish a connection, and bring the client and server together.

Typical flow of events for a connection-oriented socket:

  1. The socket() function creates an endpoint for communications and returns a socket descriptor that represents the endpoint.
  2. 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.
  3. 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.
  4. The client application uses a connect() function on a stream socket to establish a connection to the server.
  5. 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().
  6. 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.
  7. 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.
Position of a socket in the communication layer

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.

Related reference
Berkeley Software Distribution compatibility
UNIX 98 compatibility
Related information
socket()
listen()
bind()
accept()
send()
recv()
close()
Socket APIs
API finder