Working with a Stateless Protocol
By Tony Marston2006-08-13
The Differences
|
|
Statefull
This requires the user to create an instance of the application on the client device, which then connects to the central server where it creates an associated instance. Both these instances, on the client and the server, are allocated a portion of memory which may expand or contract. Both instances remain active until terminated by the user, which means that any resources (e.g. memory) which has been allocated to an instance are treated as "locked" and cannot be used by other instances. This usually means that the number of concurrent users is limited by the total number of resources which are available on the server.
During the processing of an application the user may perform many actions, such as navigating through menus, selecting transactions, jumping from one transaction to another, et cetera. Because the application instance does not die until the application is terminated, anything which is stored in memory during one action is instantly available to any subsequent actions. In other words the condition or "state" that the application was in at the end of one action is automatically carried forward into the next action.
It is also possible for the application to send information to the client at any time, without that information being requested.
Stateless
This does not require the user to start an instance of the application as all access to the application is via a web browser. The application, which is running under a web server, knows nothing about any particular client until it receives an HTTP request. When it receives a request the following happens:
- The web server creates and activates a child process to deal with the request, or it may reactivate an existing process which is currently "sleeping".
- The child process deals with the request and generates a response, which the web server will send back to the client device.
- The child process then dies, or puts itself in a "sleep" condition.
The idea behind a child process going to sleep instead of dying is to avoid the overhead of creating and activating a brand new process each time. With this method a process is created just once, and while it is not actively dealing with a request it sits in a queue of sleeping processes which are waiting to be reactivated.
It should be noted here that even if a child process does not die but merely goes to sleep it loses all memory of the request it just processed and the response which it generated. Even if the next request from the same client is given to the same child process there is no memory of any state left by the previous request. This is the stateless nature of the HTTP protocol.
- The HTTP protocol does not allow a process on the web server to be permanently allocated to a particular client.
- After dealing with a request from one client a child process may deal with many requests from many other clients before it receives the next request from the original client.
- When the web server receives a request from a client there is no way to guarantee that it will allocate the same child process that dealt with the previous request from that client.
- If that website is operating a server farm there is no way to guarantee that a subsequent request from a client will be allocated to the same server that dealt with any previous request.
This means that a client is only consuming resources on the web server during the processing of a request-response cycle. When a client receives a response there is usually a time delay before the next request is issued (if any), and during this time the web server can deal with many other requests from many other clients.
The advantage of this approach is that although there is a limit on the number of child processes which can be active at any one time, the number of active clients can be considerably greater due to the fact that the requests are usually staggered instead of transmitted all at the same instant.
The disadvantage of this approach is that the web server does not maintain any memory of the activities of any particular client, so each request is treated as a new request and not as a follow-up to a previous request.
There is no state maintained at the server end, but what about at the client end? It is true that the browser maintains a history, but this is nothing more than a history of requests that have been sent. If a request is re-transmitted it is treated as if it were a new request. The responses may be cached, but while stepping through the browser's cache there is no communication with the server, so what is being viewed is from the browser's memory on the client, not the server's memory.
Tutorial Pages:
» Introduction
» The Differences
» Maintaining State manually
» Other points to consider
