|
The term server models means the collection of different programming models or architectures that can be used to implement a server program; in this context we intend a server program as a network server program waiting for network connections made by clients. Introduction Computer programmers can choose among several programming techniques and program models (detailed below) when they have to write source code to implement a network server program. Programming techniques Depending on the requirements that a server program has to satisfy to reach desidered performances and/or to meet specific constraints (low memory usage, etc.), several programming techniques can be used, such as: Above techniques can be combined and used along with one of the following server models in order to: Server Models A server program, as any other server, can be implemented by using one of these server models: The following sub-chapters summarize pros and contras of the main various models. Single process and blocking I/O This model allows to serve only one connection at a time and it is often used in small systems to ensure serialized accesses to a resource. Finite state machine servers To minimize the context switches and to maximize the scalability, many small server programs are implemented as a single process (or at most as a process per CPU) and a finite state machine. Every task is split into two or more small steps that are executed as needed (typically on demand); by keeping the internal state of each connection and by using non-blocking I/O or asynchronous I/O, it is possible to implement ultra fast server programs. Threaded-based servers Many server programs are multithreaded. This means that inside each server's process, there are two or more threads, each one able to execute its own task independently from the others. A server program will use a thread per connection or per connection group to serve the requests coming from clients. Threads are often used to serve requests that may require a relatively long idle or computational time. For better performance, threads used by servers are typically pooled and reused to eliminate even the small overhead associated with creating a thread. Process-based servers For reliability and security reasons, servers using multiple processes (rather than multiple threads within a single process) are often the preferred choice. A pool of processes are used, and reused, until a certain threshold of requests have been served by a process before it is replaced by a new one. Because threads share a main process context, a crashing thread may more easily crash the whole application, and a buffer overflow can have more disastrous consequences. Moreover, a memory leak in system libraries which are out of the control of the application programmer cannot be dealt with using threads, but are appropriately dealt with using a pool of processes with a limited life time (because OS automatically frees all the allocated memory, requested by a process, when the process dies). Another problem relates to the wide variety of third party libraries which might be used by an application which might not be thread safe. Using multiple processes also allows to deal with situations which can benefit from privilege separation techniques to achieve better security and to work around some OS limits which very often are per-process. Mixed model servers To leverage the advantages of finite state machines, threads and processes, many servers implement a mixture of all these programming techniques, trying to use the best model for each task (i.e. for serving static or dynamic content, etc.). See also | |||||||
|
| ||||||||
 |
|
| |