polling vs long polling

Question

I got onto these examples showing polling vs long-polling in javascript, however I do not understand how they differ from one another. Especially regarding the long polling example, how does it keep its connection open?

This is what the traditional polling scenario looks like:

(function poll(){
  setTimeout(function(){
    $.ajax({ url: "server", success: function(data){
      //Update your dashboard gauge
      salesGauge.setValue(data.value);

      //Setup the next poll recursively
      poll();
    }, dataType: "json"});
  }, 30000);
})();

and this is the long polling example:

(function poll(){
  $.ajax({ url: "server", success: function(data){
    //Update your dashboard gauge
    salesGauge.setValue(data.value);

  }, dataType: "json", complete: poll, timeout: 30000 });
})();

Thanks!

Answer 1

The difference is this: long polling allows for some kind of event-driven notifying, so the server is able to actively send data to the client. Normal polling is a periodical checking for data to fetch, so to say. Wikipedia is quite detailed about that:

With long polling, the client requests information from the server in a way similar to a normal polling; however, if the server does not have any information available for the client, then instead of sending an empty response, the server holds the request and waits for information to become available (or for a suitable timeout event), after which a complete response is finally sent to the client.

Long polling reduces the amount of data that needs to be sent because the server only sends data when there really IS data, hence the client does not need to check at every interval x.

If you need a more performant (and imho more elegant) way of full duplex client/server communication, consider using the WebSocket protocol, it's great!

Answer 2

The most important thing hasn't been explicitly described here: Long polling is implemented server-side.

That's why the Javascript code for long polling and polling looks about the same - the client doesn't really do anything different. The actual implementation of "Does this endpoint respond immediately or wait until it has a non-empty response?" is server-side code that resides on your webserver.

Your server is the one that decides when to respond. If it decides it may sometimes wait, then it's a long poll.

• Endpoint code that makes some changes in-memory and returns is a regular poll.

• Endpoint code that makes a slow SQL query and returns right after is a regular poll.

• Endpoint code that checks a message queue, sees it's empty, sleeps the thread a bit, and checks it again until the queue has something is a long poll.

The client just waits in any case.

• In "regular" polling, the response often comes back quickly - determined by latency and how long the server needs to process the request.

• In "long" polling, the response may still come back quickly, if the server only needs to wait briefly until it has something to respond with. But it may also take a while, because the server is willing to procrastinate its response so that it can respond with something useful.

From the client's perspective, it's basically the same. It sends a request, and at some point it gets a response. With long-polling it may be a little longer, but not necessarily.

Note that connections may timeout, so the example code wouldn't be used in production. You'd want some handling for timeouts and error responses, usually just retrying the request.

Answer 3

So just my one cent, I think you should view option 2 as a better way of doing any form of polling. It's much cleaner/performant to only poll the server only after a response (success/failure). Which is pretty much-using recursion and timeout not setTimeout