In this article, we will go through the concept of how server management is done in Distributed Systems in detail.
Server Management:
The implementation of a distributed file service is carried out by Stateful or Stateless file servers.
- Stateful Servers: Maintains the state of the client from one Remote Procedural Call (RPC), which can then be utilized to execute other calls. Stateful servers are able to give a higher performance to clients than stateless servers. The size of messages to and from the server can be greatly reduced because clients do not have to send entire file metadata every time they execute an operation. In addition, the client also gets features like file locking and remembering read and write positions. The advantage of stateful architecture is that a security layer is added to systems due to which online banking systems prefer to use it for managing transactions. On the other side, its complex server design, poor crash recovery, and a lot of dependency between client and server make developers move on to a stateless approach. Examples- FTP (File Transfer Protocol), Telnet, TCP (Transmission Control Protocol).
- Stateless Servers: It doesn’t keep track of the client’s current state. To effectively carry out the requested operation, each request must be accompanied by all relevant parameters. Easier programming paradigm, removing the need for clients to maintain track of state data. A significant benefit in the event of failure. A failed server can simply restart after a crash and deliver services to clients as if nothing had happened because there is no state to recover. Furthermore, in case of a client’s crash, the server is not left with abandoned open or closed files. Another advantage is that the server implementation is simplified because the state accounting-related with file opening, closing, and locking are not required. One disadvantage, it might be possible that poor network performance on a regular basis. This could happen if the amount of redundant data in each request is raised. Examples- HTTP (HyperText Transfer Protocol), UDP (User Datagram Protocol), DNS (Domain Name System), SMTP (Simple Mail Transfer Protocol), etc.
The selection of a Stateful Server or Stateless Server relies on the application.
Difference between Stateless and Stateful Servers:
| Sr. No. | Parameters | Stateless Server | Stateful Server |
|---|---|---|---|
| 1. | Definition | The server does not need to maintain the state of a process in stateless protocols. | The server must save the status of a process in stateful protocols. |
| 2. | Examples | HTTP (HyperText Transfer Protocol), UDP (User Datagram Protocol), DNS (Domain Name System), SMTP (Simple Mail Transfer Protocol), etc. | FTP (File Transfer Protocol), Telnet, TCP (Transmission Control Protocol). |
| 3. | Server Constraints | The server is not required to maintain information. | The server must maintain the status as well as session information. |
| 4. | Dependency | The client and server are independent as no state is required to be maintained and hence, loosely coupled. | The client and server are bound together as they rely on each other. |
| 5. | Design | It is simple to design. | It is complex to design as the server handles a lot of functionality and moreover, data also needs to be retained. |
| 6. | Handling of Requests | Requests in Stateless contain everything they need and are processed in a “request” and a “response” pair. | Requests are constantly dependent on the server-side status while using Stateful. |
| 7. | Architecture Scaling | Scaling of stateless architecture is easy. | Scaling stateful architecture is difficult. |
| 8. | Transaction Handling | The handling of transactions is quicker in stateless servers. | The handling of transactions is relatively slower in stateful servers. |
| 9. | Crash Management | Stateless protocols operate better in the event of a crash since there is no state that needs to be restored. It is simple to restart a server that failed during the crash. | The crash management is difficult here because the server maintains the status and session information and when a crash occurs, all of the information is lost. So, it is difficult to recover after a crash. |
| 10. | Server Usage | Different servers can handle different information at a given time. | Every request must be processed by the same server. |
Why Use Stateless Servers?
There are many reasons for opting for stateless servers as discussed above in differences also:
- They make server design easier because most functionality is performed on the client-side.
- It is dependable because it swiftly recovers from partial failures. Because the server does not need to save any specific state or session, it can resume or move the client’s request to another system if it fails.
- Scalability is simple to acquire. Because the servers don’t have to keep track of session states. As a result, the server’s resources can be freed up to accommodate other incoming requests.
- Because each request is isolated, they can handle numerous sessions at the same time.
- The request handling information is not stored that is the reason usage of memory is reduced on the server-side.
- During a crash, stateless protocols frequently perform better as no state needs to be restored after a crash.
- There is no overhead involved in creating/using sessions.
- It ensures consistency in a variety of applications.
- The lack of state in an application makes it easier to work with and maintain.
- Reduces the amount of memory used by the server.
- Session expiry is no longer an issue – Expiring sessions can sometimes produce issues that are difficult to locate and test. Because stateless applications do not require sessions, they are immune to these issues.
Server Creation Semantics:
A server process is independent that makes a Remote Procedure Call to a client because client and server processes have different lifespans, run on different computers, and have different address spaces. On-demand server processes are created or maybe created and installed before their client processes. The following are the RPC servers based on the life span:
- Instance -per-call Server: It remains active for the duration of a single call. It is created when a call message is received and removed when the call is completed. The Servers of this kind possess no state i.e. stateless and are expensive too as the same type of service is invoked multiple times.
- Instance -per-session Server: It exists for the duration of the session in which the client and server interact. The inter-call status information is tracked in order to diminish the overhead associated with the server creation and destruction for a client-server session. Each sort of service has its own server manager. That’s why server managers are registered with the binding agent. The binding agent provides the client with the address of the server management. The server manager creates a new server and provides its address to the client. When the execution is finished, the server is destroyed by the server management. It services only a single client and thus manages a single state of information at a time.
- Persistent Server: As the name implies, it exists indefinitely. A large number of clients share this server. It enhances overall performance and dependability. Load balancing and failure resilience can be achieved by installing servers that provide the same sort of service. Each server needs to register with a binding agent to export its services.
The stateful model, in which clients rely on servers for the majority of computing operations. Its difficulty to scale is the reason for this. Furthermore, technological advancements, paired with the development of powerful client computers, aided in the transition to a stateless preferred environment. This freed up developers’ time and energy to focus on product development rather than technical difficulties like server software implementation, which are frequent in stateful systems.