In this article, we have explored How Clients and Servers Communicate and Types of Client Server Communication such as HTTP Push and Pull, Long Polling and much more.

Table of contents:

1. Introduction to Clients and Servers Communication
2. HTTP Push and Pull
3. Ajax Polling
4. Long Polling
5. Server sent events
6. Websockets
7. Message queues
8. Conclusion

Introduction to Clients and Servers Communication

The main purpose of the internet is to provide an avenue (infrastructure) for one computer A to send a message to another computer B, and for that computer B to be able to respond appropriately. This process allows for the sharing of resources and exchange of data, this implies the presence of one computer or set of computers who own the resource(s) and serve them (a.k.a. servers) and other computers who need to access those resources (a.k.a. clients). Keep in mind that the roles can be reversed from time to time i.e. a computer might own some resources but sometimes it might need (request) other resources from others, in which case it acts as a client. This method of network organisation is commonly reffered to as the client-server architecture. The major mode of communication in this architecture is the Hepertext Transfer Protocol (HTTP).

Types of Client Server Communication are:

• HTTP Push and Pull
• Ajax Polling
• Long Polling
• Server sent events
• Websockets
• Message queues

HTTP Push and Pull

Hypertext transfer protocol (http) is a communication protocol used for fetching resources such as HTML documents, images, video files etc. It is the most common client-server protocol on the internet. HTTP communication can be divided into two types: HTTP pull and HTTP push.

HTTP pull is a style of communication whereby a client sends a message to a server (usualy called a request) and the server sends back a reply (called response) after which the connection is closed. Anytime the client needs more information the process is repeated over and over again. Application developers are responsible for deciding how often to make requests for data from the server. The dilema with polling is that making continous requests at short intervals means you get the most up to date information from the server immediately its available but this risks overloading the server with too many requests and most of the time the responses are empty because there's no new info to display which means unnecessary traffic is created on the network. On the other hand, making requests on longer intervals means that there's less traffic but with the downside of possibly missing important updates from the server.

In the case of HTTP push the connection is not broken after the initial request, meaning the client initiates a request to the server and after the server responds the connection is kept in place. Using this established connection, the server can send any new updated down to the client as soon as they are available. The client does not need to repeatedly request for updates from the server, the updates are sent as soon as they are available. This helps to reduce the load on the network with the advantage that the updates are received in a timely manner. A drawback to this style is that the server has to maintain connection to the client which creates certain overhead on the server.

Having looked at the two styles of client-server communication through HTTP we will now look and some examples of the implementation of both types of communication styles in the following sections.

Ajax Polling

AJAX stands for Asynchronous JavaScript And XML. The last part (XML) is a little misleading as nowadays Ajax is used along with other data formats such as JSON. This is a technique in which a client, usually a web browser sends a request to a web server and the server responds. Before requests can be sent the client has to establish a connection to the web server. After the connection has been successfully established, then requests can be sent. On receiving a request a server performs some processing and sends back a response after which the connection is closed. This process is repeated continously to exchange data between the client and server. The process is always initiated by the client. This means that even if the server has updates which the client might be interested in, the updates can't be sent unless the client explicitly requests updates. This mode of communication is not ideal for real-time applications such as stock trading apps or chat apps where updates come frequently and users require the most up to date information as soon as possible.
An advantage of polling is that it has almost universal support. It is used in traditional web applications which do not require real time updates to clients e.g a weather app.

Long Polling

This is more efficient than AJAX polling. In traditional polling, there's allot of overhead due to the fact that the connection has to be created repeatedly any time the client needs to make a request. Also the fact that a client has to make requests repeatedly in order to check for new data creates alot of unnecessary traffic, and adds to the load on the server processing such requests. Considering the server is required to serve several other clients, this repeated polling could become a problem.

With long polling, a client connects to a server makes a request and waits for a response. After receiving the request, the server checks if it has any new data which has not been already sent to the client. If there is, it sends the data to the client in its response but if there isn't it does not send a response but rather it keeps the connection open and waits till there is new data to be sent. Only then will a response be sent down to the client. After receiving the response, the client then immediately sends another request to the server and the process is repeated over and over again.

Long polling is like a simulation of http push communication because the client still has to make the request but unlike normal polling the server does not have to respond if it does not have any data to send. Doing this helps prevent clogging up the network with uneccessary requests and responses and also saves the server from having to keep processing requests even if there's nothing new to show. While this method frees up the network it creates alot of overhead in the server as it dedicates some of its resources in order to keep the request connection open.

Server sent events

This is a mode of communication whereby, a server can automatically send updates (data) or events to a client without the client explicitly making requests for it. The client has to subscribe for those events though, which means an initial connection is first established. After which the clients continously receives updates in the form of events from the server. Server sent events are suitable in apps like stock market applications where the server receives alot of updates in a short period of time.

Websockets

Websocket is a communication protocol just like HTTP. They are both compatible with each other i.e. websockets was designed to work with HTTP proxies and a HTTP connection can be upgraded to use websockets using the upgrade header. A websocket connection provides the ability for two-way (full-duplex) communication between the client and the server unlike HTTP which is one way (half-duplex). What this means is that the client and server can send and reveive messages at the same time on the same connection, whereas in HTTP the server waits for the client to send a request and then it sends its reponse (communication is done one at a time). An advantage of websockets is they allow for bi-directional communication i.e. both client and server can send messages at the same time. Websockets are suitable for chat apps and online games.

Message queues

As mentioned earlier, the internet has to do with the sharing of data and resources. Sometimes, several users, micro-services or clients may request the same resource at the same time. Lets take the example of an application broken up into several services i.e. the email service, password recovery, marketing, registration etc. In such an application it is possible that the password recovery service, marketing service and registraion service may each need the email service to send several emails at the same time but the email service can only send the emails one at a time. Message queues are software designed to handle such situations.
Message queues allow for asynchronous communication between several components or services. When using message queues, there are two types of components: the producers which create messages or send requests and the consumers which process those requests.

In the example we discussed above, the password, marketing and registration services are the producers making requests while the email service is the consumer whose job it is to process those requests i.e. send the emails.
In such a system, a delay by the consumer will not affect the producers as they send their messages to the queue and continue processing other tasks. The message queue ensures that the consumer receives the messages. Even if the consumer is down for one reason or the other, the message is kept in the queue until the consumer is back up and able to process the messages meant for it. This ensures reliability and asynchronicity. Some examples of message queues include RabbitMQ, Apache Kafka, Axon etc.

Conclusion

In conclusion, the mode of communication is a very important factor in the client server-architecture as it determines how interactive applications will be and how much resources are consumed on the network and on the server. Nowadays, users want to be able to view the latest information as soon as it is available. For example on facebook feeds, stock applications and chat apps. In such applications, pull communication won't be the most effective form of communication as data changes quickly and there is potential to miss some updates. Which is why server push methods have become increasingly popular that is apart from the fact that push methods are also less resource intensive than pull methods. That is not to say that pull communication is completely useless as there are still situations where it is a better option just like the weather aplication mentioned.

In situations where communication can be asynchronous, it's useful to add message queues as they help ensure reliability, and also act as a buffer when a particular part of the system is being overloaded with alot of requests.

With this article at OpenGenus, you must have the complete idea of Types of Client Server Communication.