Introducing Long-Polling, Websockets, Server-Sent Events, Comet

Currently the web application has grown far from the first day it appeared, along with numerous new techniques applied to serve this process to bring a new experience, full of excitement and equally handy for users.

In order for you to have a clearer view of modern web technology, today I will introduce to you some current techniques commonly used in real-time web applications.

( In the examples below, the client will be the user's browser, the server will be the website's webserver hosting, on the left is the client and on the right is the server ). However, I will first introduce the access model according to the traditional http protocol.

Regular HTTP:

1. The user sends a request for a website from a server.
2. The server (server) calculates the return data (response).
3. The server sends the return data (response) to the user (client).

~> Client proactively sends requests to the server, there will be a response response for the client, but if there is no request from the client, the server will not do anything.

AJAX Polling:

1. Client requests a web page from server using "Regular http" (mentioned above).
2. The website that the client has requested will use javascript to make requests continuously to a file on the server for a regular period of time (for example, every 2 seconds will send a request to the server).
3. The server will calculate the response for each request and return the response to the client like the traditional http protocol.

~> Client does not actively send requests to the server but the website's javascript will still alternately send requests to the server and the client will receive a response from the server in a passive way.

AJAX Long-Polling:

1. Client requests a web page from server using "Regular http" (mentioned above).
2. The website that the client requested will use javascript to make a request to a file on the server.
3. The server will not send the response immediately to the client (for the sent request) but will wait until there is new data.
4. When there is new data, the server sends that new data (response) to the client.
5. After receiving new data from the server, the client will immediately continue with another request to the server to start the whole process again (steps 3 to 5).

~> Client will send the request to the server, the server proceeds to check the data and when there is new data, it will send the response to the client. Then the client continues to automatically send a new request and wait for the new data to return.

HTML5 Server Sent Events (SSE) / Event Source:

1. Client requests a web page from server using "Regular http" (mentioned above).
2. The website that the client requested will use javascript to open a connection to the server.
3. From this time the server sends a response response to the client whenever new data is available.

~> It means that the client always receives new data in real time from the server with only 1 request (1-way data from server to client). At this time, the server will execute an event loop (steps 1 to 3) to redo this process many times, but you cannot connect to the server from another domain (domain).

HTML5 Websockets:

1. Client requests a web page from server using "Regular http" (mentioned above).
2. The website that the client requested will use javascript to open a connection to the server.
3. Now both the server and the client can send and receive different data together when new data is available (like the type of two parties chatting with each other rather than following any rules).

~> That means the client and server always receive new data in real time (2-way: server to client or client to server). At this time, the server will execute an event loop (steps 1 to 3) to redo this process repeatedly and you can connect to the server from another domain (domain). You can also use the 3rd party websocket server provided (eg http://pusher.com/ ) and the rest is that you only need to code on the client (much easier because you had to code both server and client side.

To make it easier to understand, I would like to explain more about the above figure, which illustrates many possible situations when applying web socket:

• Case 1: create connect with server ~> receive 2 response from server.
• Case 2: create connect with server ~> receive a response from server ~> client sends another request to server.
• Case 3: create connect with server ~> receive 2 responses from server ~> server returns another reponse to client (although there is no new request).

Comet:

Comet is a generic term that describes the server sending the data response to the client without a clear request. It is also known as Ajax push, Reverse Ajax, Two-way-web, HTTP Streaming, HTTP server push. In fact, the comet application can use one of two techniques: Streaming or Long-Polling.

Comet has a preeminence that the request from the client to the server can be kept for a long time (until the time-out limit is reached) to wait for the response from the server to return (see image above), and after that will continue to send new requests to wait for another response from the server.

Another great advantage of Comet is that there is always a communication link between the client and server, the server can send the response as soon as the request is sent or accumulate response to send once. But because the requests exist for a long-lived request, a special mechanism is needed to handle all of these requests.

The Long-Polling technique I introduced earlier is not repeated, but with streaming you can understand this simple: the form is similar to long polling technology, but the other is that we only initiate the connection. server once and send and receive data through this connection, not create a new connection. (The actual streaming technique can be applied to make the web watch movies online, download it to see where it is and only request the movie file once).

ITZone via Techmaster