Life on the Internet revolves around processes called servers. Accordingly, this chapter introduces the facilities now built into SETL for creating, communicating with, and governing servers. SETL proves to be well suited for expressing servers and their corresponding clients, and indeed the main goal of this dissertation is to show how convenient it has become for SETL servers to manage fluctuating sets of clients in data processing over the Internet.
The client-server conceptual model has been a huge success, to the point where for any pair of processes communicating over the Internet, it is helpful to label one as client and the other as server. Of course, we are speaking of relationships here, so a server can play client to other servers. In SETL, these relative roles are reflected in the names of the open I/O modes that create Internet sockets.
The usual job of a server is to wait for client requests and respond to them in some way. In the spirit of using processes as the fundamental modules of a data processing system, a server will typically define an interface consisting of some set of commands (or methods, in object-oriented terms) that is independent of the host operating system, hardware, and source programming language.
A server is in an ideal position to synchronize access to a resource, and will often be a long-lived process that consumes no CPU time and little memory while passively waiting for clients.
In order to remain available and responsive to client requests at all times, and to remain immune to client-induced crashes, a server will usually deal with each client through a pump stream (see Section 2.2.3 [Pumps]). If the child process associated with that stream goes down due to a network failure or unhandled data exception, the server then merely sees an end-of-file condition on the stream.