Hacker News Reader

Comment by sb8244 | Hacker News Reader

Long polling can work great as a bidirectional communication layer (send and receive messages over 1 connection). A few things that it would be worse with:

* Request headers are processed on each request. Even with keep-alive connections the request headers are sent/processed

* Message latency can be much higher in poor conditions because multiple requests have to complete to complete a loop (I think it's 3 connections and each connection can potentially be re-sent which means it can take several round trips)

* Not fully duplex connection, you can't send and receive data at the same time on 1 connection

* Domain limits imposed by browsers apply

* edit: binary message protocol can't be used

It's better for some use cases:

* Easier to implement (standard HTTP). WS is definitely much more complex to implement

* Easier to deploy (standard load balancers / proxies should work well)

* Takes advantage of keep-alive

View on HN

If i understand long polling right, then it one request which does not end (not connectio) and keeps receiving or sending information. So processing of multiple headers does not apply.

Keep-alive connections still require processing a full HTTP request for every request. This is documented in RFC6202 https://tools.ietf.org/html/rfc6202#section-2.2

The connection overhead is removed but that is only one of the various overheads that exist.

edit: I understand your question a bit differently after reflecting on it more. I think you may be saying that 1 connection never ends in long-polling. This is not the case and is only this way if keep-alive is used.

Each server->client data exchange happens by "completing" the request and the client is configured to immediately make a new request. This means every message (or groups of messages depending on your tolerances) is a completed HTTP request.

As sb8244 explained, long-polling typically refers to the server waiting before responding, and then responding with a complete response in one shot.

What you're thinking of, an HTTP response that the server keeps appending to and the client is expected to read and process incrementally, is also a real thing though. This is typically referred to as HTTP streaming. Examples of this would be SSE (text events) or MP3 streaming (audio).

(Not to be confused with HTTP Live Streaming (HLS) which is typically not based on any long lived requests at all!)

Long polling doesn't allow for multiple polls on one connection. What it gives you is an reply only when there is something to reply with. Otherwise it just keeps connection open and waiting. It's a mechanism that mimics push, from the point of view of a client.

Here more info: https://stackoverflow.com/questions/12555043/my-understandin...

To send data using long polling, a new http request has to be made, since long polling is basically just a regular http request with a (possibly) very slow server reply.

The client can either terminate the connection and make a new one, or make a second parallel request for sending and leave the first waiting for a new server response. I'm actually not sure which is more common (despite implementing apps that can do long polling, I've never paid attention at that level), nor am I entirely sure how this works with keep-alive connections (eg, can you stop waiting and issue a new http request without closing the TCP session?).

In all cases, each request from the client involves sending http headers, and if the client is a web browser, there's going to always be a few hundred bytes at least (cookie, referer, accept, user-agent, etc).

Reply on news.ycombinator.com