Server Connections

In the Internet domain, the server process creates a socket, binds it to a well-known protocol port, and waits for requests. If the server process uses a reliable stream delivery or the computing response takes a significant amount of time, it may be that a new request arrives before the server finishes responding to an old request.

The listen subroutine allows server processes to prepare a socket for incoming connections. In terms of underlying protocols, the listen subroutine puts the socket in a passive mode ready to accept connections. When the server process starts the listen subroutine, it also informs the operating system that the protocol software should queue multiple simultaneous requests that arrive at a socket. The listen subroutine includes a parameter that allows a process to specify the length of the request queue for that socket. If the queue is full when a connection request arrives, the operating system refuses the connection by discarding the request. The listen subroutine applies only to sockets that have selected reliable stream delivery or connection-oriented datagram service.

A server process uses the socket, bind, and listen subroutines to create a socket, bind it to a well-known protocol address, and specify a queue length for connection requests. Invoking the bind subroutine associates the socket with a well-known protocol port, but the socket is not connected to a specific foreign destination. The server process may specify a wildcard allowing the socket to receive a connection request from an arbitrary client.

All of this applies to the connection-oriented datagram service in the NDD domain, except that the server process binds the locally created socket to the operating system NDD name and specifies ATM B-LLI and B-HLI parameters before calling the listen subroutine. If only B-LLI is specified, all incoming calls (or connections), regardless of the B-HLI value, will be passed to this application.

After a socket has been set up, the server process needs to wait for a connection. The server process waits for a connection by using the accept subroutine. A call to the accept subroutine blocks until a connection request arrives. When a request arrives, the operating system returns the address of the client process that has placed the request. The operating system also creates a new socket that has its destination connected to the requesting client process and returns the new socket descriptor to the calling server process. The original socket still has a wildcard foreign destination that remains open.

When a connection arrives, the call to the accept subroutine returns. The server process can either handle requests interactively or concurrently. In the interactive approach, the server handles the request itself, closes the new socket, and then starts the accept subroutine to obtain the next connection request. In the concurrent approach, after the call to the accept subroutine returns, the server process forks a new process to handle the request. The new process inherits a copy of the new socket, proceeds to service the request, and then exits. The original server process must close its copy of the new socket and then invoke the accept subroutine to obtain the next connection request.

If a select call is made on a file descriptor of a socket waiting to perform an accept subroutine on the connection, when the ready message is returned it does not mean that data is there, only that the request was successfully completed. Now it is possible to start the select subroutine on the returned socket descriptor to see if data is available for a conversation on the message socket.

The concurrent design for server processes results in multiple processes using the same local protocol port number. In TCP-style communication, a pair of end points define a connection. Thus, it does not matter how many processes use a given local protocol port number as long as they connect to different destinations. In the case of a concurrent server, there is one process per client and one additional process that accepts connections. The main server process has a wildcard for the destination, allowing it to connect with an arbitrary foreign site. Each remaining process has a specific foreign destination. When a TCP data segment arrives, it is sent to the socket connected to the segment's source. If no such socket exists, the segment is sent to the socket that has a wildcard for its foreign destination. Furthermore, because the socket with a wildcard foreign destination does not have an open connection, it only honors TCP segments that request a new connection.