Morph MORPH
SIGN IN SIGN UP
javascript-tutorial / en.javascript.info UNCLAIMED

Modern JavaScript Tutorial

25219 0 0 HTML
Normal View History Raw
updates
2019-07-03 17:19:00 +03:00
# Long polling
Long polling is the simplest way of having persistent connection with server, that doesn't use any specific protocol like WebSocket or Server Side Events.
Being very easy to implement, it's also good enough in a lot of cases.
## Regular Polling
minor
2019-08-14 20:30:36 +03:00
The simplest way to get new information from the server is periodic polling. That is, regular requests to the server: "Hello, I'm here, do you have any information for me?". For example, once in 10 seconds.
updates
2019-07-03 17:19:00 +03:00
In response, the server first takes a notice to itself that the client is online, and second - sends a packet of messages it got till that moment.
That works, but there are downsides:
improvements
2019-07-16 19:23:00 +03:00
1. Messages are passed with a delay up to 10 seconds (between requests).
minor
2019-08-14 20:30:36 +03:00
2. Even if there are no messages, the server is bombed with requests every 10 seconds, even if the user switched somewhere else or is asleep. That's quite a load to handle, speaking performance-wise.
updates
2019-07-03 17:19:00 +03:00
improvements
2019-07-16 19:23:00 +03:00
So, if we're talking about a very small service, the approach may be viable, but generally, it needs an improvement.
updates
2019-07-03 17:19:00 +03:00
## Long polling
improvements
2019-07-16 19:23:00 +03:00
So-called "long polling" is a much better way to poll the server.
updates
2019-07-03 17:19:00 +03:00
It's also very easy to implement, and delivers messages without delays.
The flow:
1. A request is sent to the server.
minor
2019-08-14 20:30:36 +03:00
2. The server doesn't close the connection until it has a message to send.
3. When a message appears - the server responds to the request with it.
updates
2019-07-03 17:19:00 +03:00
4. The browser makes a new request immediately.
The situation when the browser sent a request and has a pending connection with the server, is standard for this method. Only when a message is delivered, the connection is reestablished.
images to svg
2019-07-28 15:42:37 +03:00
![](long-polling.svg)
updates
2019-07-03 17:19:00 +03:00
improvements
2019-07-16 19:23:00 +03:00
If the connection is lost, because of, say, a network error, the browser immediately sends a new request.
updates
2019-07-03 17:19:00 +03:00
improvements
2019-07-16 19:23:00 +03:00
A sketch of client-side `subscribe` function that makes long requests:
updates
2019-07-03 17:19:00 +03:00
```js
async function subscribe() {
let response = await fetch("/subscribe");
if (response.status == 502) {
minor
2019-08-14 20:30:36 +03:00
// Status 502 is a connection timeout error,
// may happen when the connection was pending for too long,
// and the remote server or a proxy closed it
updates
2019-07-03 17:19:00 +03:00
// let's reconnect
await subscribe();
} else if (response.status != 200) {
minor
2019-08-14 20:30:36 +03:00
// An error - let's show it
updates
2019-07-03 17:19:00 +03:00
showMessage(response.statusText);
// Reconnect in one second
await new Promise(resolve => setTimeout(resolve, 1000));
await subscribe();
} else {
minor
2019-08-14 20:30:36 +03:00
// Get and show the message
updates
2019-07-03 17:19:00 +03:00
let message = await response.text();
showMessage(message);
minor
2019-08-14 20:30:36 +03:00
// Call subscribe() again to get the next message
updates
2019-07-03 17:19:00 +03:00
await subscribe();
}
}
subscribe();
```
improvements
2019-07-16 19:23:00 +03:00
As you can see, `subscribe` function makes a fetch, then waits for the response, handles it and calls itself again.
updates
2019-07-03 17:19:00 +03:00
```warn header="Server should be ok with many pending connections"
The server architecture must be able to work with many pending connections.
Certain server architectures run a process per connect. For many connections there will be as many processes, and each process takes a lot of memory. So many connections just consume it all.
minor
2019-08-14 20:30:36 +03:00
That's often the case for backends written in PHP, Ruby languages, but technically isn't a language, but rather implementation issue. Most modern language allow to implement a proper backend, but some of them make it easier than the other.
updates
2019-07-03 17:19:00 +03:00
Backends written using Node.js usually don't have such problems.
```
## Demo: a chat
minor
2019-08-14 20:30:36 +03:00
Here's a demo chat, you can also download it and run locally (if you're familiar with Node.js and can install modules):
updates
2019-07-03 17:19:00 +03:00
[codetabs src="longpoll" height=500]
minor
2019-08-14 20:30:36 +03:00
Browser code is in `browser.js`.
updates
2019-07-03 17:19:00 +03:00
## Area of usage
Long polling works great in situations when messages are rare.
If messages come very often, then the chart of requesting-receiving messages, painted above, becomes saw-like.
Every message is a separate request, supplied with headers, authentication overhead, and so on.
So, in this case, another method is preferred, such as [Websocket](info:websocket) or [Server Sent Events](info:server-sent-events).
Reference in New Issue Copy Permalink