Webtide
SitePen Support

More on Long-Polling

by Michael CarterNovember 16th, 2007

Recently, Dylan talked about the long-polling technique. This method has become fairly well-disseminated, but there are some misconceptions as to the trade-offs between long-polling and streaming transports. Hopefully I can clear a couple of them up.

One of the big criticisms of long-polling is that it introduces additional latency and bandwidth costs. While these are valid concerns, they are not as pressing as they may seem. Bandwidth isn’t that big of a deal. We’re talking a few hundred bytes of overhead per event. If there are 100 events a second minute then that’s maybe 0.5k/second overhead. Even 33.6kbps modems can handle that overhead, besides the fact that 100 events is an extreme example. As for latency, the most commonly cited cause of latency for this transport is the TCP setup/tear-down cost for each connection. But HTTP/1.1 codified the concept of Connection: Keep-alive, which allows multiple HTTP requests to be sent over the same TCP connection, so we end up with a transport very similar to streaming transports.

But there is another actual latency issue. That is, the latency of each long-polling event includes the round trip time between the browser and the server. On the other hand, the latency in streaming is equivalent to the latency of a one-way trip from the server to the browser. This has to do with how the HTTP protocol works. There are only two real states, 1) The server is waiting for a request (and cannot send data) or 2) The browser is waiting for a response (and cannot send data.) Given the confines of this protocol, a full request response cycle is necessary for any data exchange. Streaming transports step slightly outside the bounds of the protocol to achieve a latency of roughly half that of long-polling.

The benefits of long-polling though are twofold:

  • First, the browser and server interact in a standards compliant manner. That’s not to say that HTTP streaming doesn’t work in standards compliant browsers, just that the strict definition of HTTP only has room for a long-polling style implementation of Comet. Some firewalls are keyed not just to particular ports but also certain protocols, particularly HTTP. If the interaction doesn’t seem to be HTTP, then these firewalls just may block the connection. Using long-polling will ensure that firewalls do not block any requests.
  • The second benefit is that network resilience is built in. HTTP servers hide the details of Keep-alive versus HTTP/1.0 style interaction from the app. This means the application doesn’t care and doesn’t even know whether or not a TCP connection is interrupted, so long as requests keep coming (from a re-opened connection.) Therefore, the most basic implementation of long-polling will survive brief network outages. Recently I was using a long-polling based IRC client as well as a traditional desktop IRC client. I had a brief (about 5 seconds) network outage and my desktop IRC client lost its connection and I had to reconnect, re-authenticate, and join all my channels again. On the other hand, my web-based client was perfectly fine. That’s because the Comet server maintained the actual TCP connection to the IRC server, and it didn’t mind that my browser was disconnected for a few seconds.
[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]
Lightstreamer

8 Responses to “More on Long-Polling”

  1. Martin Tyler Says:

    Michael, I’m not sure that some of your figures are correct. In the case you state, 100 events/sec with ‘a few hundred bytes’ overhead per event is a lot more than 0.5K/s. Of course, in reality the roundtrip time between events would mean a server implementation most likely has a batch of events to send by the time the next long poll request comes in, so your bandwidth is dependant on the roundtrip time. 250ms roundtrip would mean only 4 requests per second and 25 batched events per request in your example, which is more like the 0.5K/s overhead you state.

    On latency, with streaming. Long polling adds the whole roundtrip time to the latency, not half. If a server has just send 1 event and has another one to send 1ms later, in streaming it can be sent immediately so latency to the client is your one way trip time (125ms for example), with long polling you have the time for your previous event to get to the client and the time for the request to get back, plus the time of the event itself.. therefore 375ms. So streaming can be 1/3 of the latency of long polling in the best case.

    Streaming is very important for some applications, and when done through HTTPS i’m not aware of any proxies that interfere with the stream.

  2. Kris Zyp Says:

    I want to see if I understand this correctly: When there is a long poll currently open, the server can send information to the client (with a response) and the client will receive the data in a single one way trip. The full round trip is required to rebuild the long poll after getting the response, but the client has received the data and can act on it after only a single trip, the next long poll request can happen afterwards. With the long poll open, the client also still has the ability to send a message to the server with a single trip as well with a request on a new connection (assuming the HTTP keep alive still has a TCP connection open and available). Therefore when the browser is in the state of a long poll open and no other connections are being used, both client and server can deliver a message in one-trip time. However, after a long poll request is responded to (server sends message), there is (hopefully brief) time in which the server must wait for a long poll to be rebuilt, in which communication is “down”. Latency issues caused by this down time (and connection count/XHR cross domain limitations) and increased bandwidth are where long-poll is less effective compared to streaming.
    Is this correct? I am not sure if I misunderstanding an aspect of HTTP/long poll, or if the latency as described in the post just wasn’t clear to me.

  3. Jacob Rus Says:

    Kris: yep, that’s about right. The latency discussed here is worst-case, when events are very frequent, and the additional slow-down over streaming is the time to make the next long poll request.

    (though when you mention cross-domain limitations, keep in mind that xhr long-polling is in the same boat as every streaming transport, only working across different sub domains; only script tag long polling works across domains)

  4. Michael Carter Says:

    Martin:

    100 events/sec is actually a typo. I meant to put down 100 events per minute. The calculation for 0.5k a second is as follows: 100 events per minute * 300 bytes = 30000 bytes (approx 30k) a minute. 30k/60 seconds = 0.5k/sec.

    As for the latency, you raise a good point. This could be mitigated somewhat by having two XHR requests pending, but you’re still correct, 3x the latency is the worst case.

    In regards to encryption as a method to get past firewalls with streaming transports, that would work. But I think that many Comet applications have no inherent need for encryption, and adding it simply to get by firewalls wouldn’t be worth the overhead. I’ve found no problem with just restarting the unencrypted streaming connection every 30 seconds though.

  5. Martin Tyler Says:

    Hi Michael,

    It comes down to what applications are being used. The applications I have experience of need the lowest latency possible with fast update rates.. they also generally need HTTPS, which is a happy coincidence since that provides a more stable streaming platform.. although I dont find many issues these days with proxies batching data over HTTP, but that could be because most of the applications I have experience of are using HTTPS now.

    The bandwidth overhead can be a big issue, but again its application dependant. Your post states it is fine for even a modem, but what about the servers bandwidth? I know of a number of large institutions where this is a major issue as they are dealing with 10’s of thousands of concurrent clients where the extra bandwidth overhead of the HTTP headers and the CPU hit of the extra requests would be a killer.

  6. Comet Daily » Blog Archive » The Future of Comet: Part 1, Comet Today Says:

    [...] opens another connection, ensuring that the server can pass it events in real time. This is less effective than streaming transports with respect to bandwidth overhead and throughput; it works, however, in [...]

  7. Comet Daily » Blog Archive » TCP Overhead Says:

    [...] less than the keep-alive value of that the web server could be substantially less efficient than long polling would be on that same server, because with long polling all but the initial request would be sent [...]

  8. Starting Out With Comet (Orbited) Part 1 « Things I Learned Says:

    [...] is another Comet technique.  Michael Carter, one of Orbited’s main contributors has a nice article on the advantages of the two [...]

Leave a Reply



Copyright 2014 Comet Daily, LLC. All Rights Reserved