No Comments Written by Robert on March 27, 2008 – 4:48 am

Client–server systems have been operating across networks since the early days of the ARPANET back in the late 1960s. The mechanisms that are used became more or less standardized in the early 1980s.Most of the client–server systems would then have run on variants of the Unix operating system. Network communications standardized on the Internet’s Transmission Control Protocol/Internet Protocol suite (TCP/IP). The most popular application programmer interface was the Berkeley ‘socket’ library. The major servers of the time would have included the file transfer (ftp) server, the telnet server that supported remote log in, mail and news servers, and utility programs such as echo. These servers all involve active clients initiating contact with passive servers. In most cases, the servers are always running as background daemon processes on the machine that is hosting them; the typical server daemon is in a blocked state, waiting for a client to initiate contact and request services.

The Internet Protocol (IP) defines a mechanism for getting packets of data from one machine to another across the Internet. More elaborate protocols are layered over IP. You don’t want to send packets between machines; you want to exchange data between particular processes running on these machines. This is handled at the next level in the layered protocol schemes, with protocols such as UDP (User Datagram Protocol) and TCP. Both these protocols define the end points for communications between processes in terms of ‘ports’. Ports are operating system resources; at a very simple level, you can view them as having an integer identifier and associated input and output data buffers. A process can claim a port. Server programs use ‘well known ports’; they always claim the same port number (e.g. the ftp daemon process that handles file transfers will always claim port 21). Clients that need to use a port only for a short period get an arbitrary port allocated by the operating system. The headers for UDP and TCP packets include the IP addresses of client and server machines, and the port numbers for the client and server processes. The client composes the first packet, inserting the host’s IP address once this has been determined, and the ‘well known port number’ for the desired service; it also inserts its own temporary port number and the IP address of the machine on which it is running. These data allow the server to send response packets that are properly addressed to the client.

The UDP protocol is relatively lightweight. It allows a client to compose a datagram and send this to a server. Usually, a datagram will arrive safely and the server will respond. The programmer has to decide what to do if there is no response, and implement code that will retry a request or abandon the attempted communications. The TCP protocol is much more elaborate. It establishes a reliable bidirectional data stream between client and server. The code in the TCP libraries deals with all the problems of communications; problems such as lost packets, timeouts, repeated packets and flow control requirements. Most client–server systems use TCP layered over IP.

The Berkeley sockets API allows programs to bind ‘sockets’ to ports. A normal socket is just like a connection to an input/output file that supports standard Unix read-byte and write-byte operations, along with Unix’s other more specialized control options. Such data sockets are usually wrapped inside classes that support higher-level I/O operations. A server will use a ‘server socket’; this is activated differently than an ordinary data socket. The operating system (OS) deals with the initial input arriving at such sockets, interpreting the data as requests by new clients seeking to establish communication. When a client connects, the OS creates a new data stream socket, and returns this to the server process. The server can then read data from the client and write responses back to the client through this data socket. There can be multiple sockets associated with a single port used by a server process; these would be the ‘server socket’, and various data stream sockets created for concurrent clients. The OS keeps them separated, using different I/O buffers for each socket.

I’ll keep on posting about servers, but at the same time I eagerly await further comments.