Example: Passing descriptors between processes

These examples demonstrate how to design a server program using the sendmsg() and recvmsg() APIs to handle incoming connections.

When the server starts, it creates a pool of worker jobs. These preallocated (spawned) worker jobs wait until needed. When the client job connects to the server, the server gives the incoming connection to one of the worker jobs.

The following figure illustrates how the server, worker, and client jobs interact when the system uses the sendmsg() and recvmsg() server design.
Server, worker, and client job interaction when you use the sendmsg() and recvmsg() server design.

Flow of socket events: Server that uses sendmsg() and recvmsg() APIs

The following sequence of the socket calls provides a description of the graphic. It also describes the relationship between the server and worker examples. The first example uses the following socket calls to create a child process with the sendmsg() and recvmsg() API calls:

  1. The socket() API returns a socket descriptor, which represents an endpoint. The statement also identifies that the INET (Internet Protocol) address family with the TCP transport (SOCK_STREAM) is used for this socket.
  2. After the socket descriptor is created, the bind() API gets a unique name for the socket.
  3. The listen() allows the server to accept incoming client connections.
  4. The socketpair() API creates a pair of UNIX datagram sockets. A server can use the socketpair() API to create a pair of AF_UNIX sockets.
  5. The spawn() API initializes the parameters for a work job to handle incoming requests. In this example, the child job created inherits the socket descriptor that was created by the socketpair().
  6. The server uses the accept() API to accept an incoming connection request. The accept() call blocks indefinitely, waiting for the incoming connection to arrive.
  7. The sendmsg() API sends an incoming connection to one of the worker jobs. The child process accepts the connection with therecvmsg() API. The child job is not active when the server called sendmsg().
  8. In this example, the first close() API closes the accepted socket. The second close() call ends the listening socket.

Socket flow of events: Worker job that uses recvmsg()

The second example uses the following sequence of API calls:

  1. After the server has accepted a connection and passed its socket descriptor to the worker job, the recvmsg() API receives the descriptor. In this example, the recvmsg() API waits until the server sends the descriptor.
  2. The recv() API receives a message from the client.
  3. The send() API echoes data back to the client.
  4. The close() API ends the worker job.