undefined | Better HN

0 pointswfunction9y ago0 comments

> At a minimum, long-polling requires a server round-trip per message. Among other problems, this limits throughput to (message size / latency).

I don't see why? Just have N multiple outstanding requests to the server (with N being large enough to achieve whatever communication rate you can accept). When the server wants to send you something, it picks one and replies to it. While you're busy processing it the server can still reply to anther one and send more data. When you're done you send more outstanding requests to the server to reach N again.

And if you ever run out of outstanding requests, then that's equivalent to your socket not being able to accept a new connection because there are too many pending already, which can always happen.

0 comments

1 comments · 1 top-level

jkarneges9y ago

Yeah, you could have multiple requests hanging open with the server to enable faster server sends (and if a client wants to send data rapidly it could make multiple parallel POST requests).

The downside is you end up with a complex stateful protocol, with multiple sockets, and need the ability to handle out-of-order data. If you're targeting a platform that can't do HTTP streaming, then sure, but otherwise this is a pretty gnarly road to go down.

My personal preference for long-polling is to use it for stateless / RESTful APIs that have infrequent updates. Super clean, easy to use from the client's perspective, and efficient enough. I would not use it for stateful communication (IMO SockJS and Engine.IO are gross but I understand why they exist).

j / k navigate · click thread line to collapse