Hacker News new | ask | show | jobs
by btown 793 days ago
Dropbox's approach here in the early 2010s (not sure if still used) was actually quite clever. Both official clients and third parties could open up a long-timeout HTTP connection that wouldn't be responded to until the web server was delivered a message in their internal message queue. Avoided the overhead of polling and allowed for extremely low latency, while letting clients still use their favorite HTTP library.

https://dropbox.tech/developers/low-latency-notification-of-...
3 comments
smarx007 793 days ago
> long-timeout HTTP connection that wouldn't be responded to

This open connection IS the overhead. Some approaches have more overhead, some less. Long-polling these days is not needed and can be replaced by SSE [1] (if you are OK with unidirectional communication), websockets (bidirectional), or callback URIs in the request. The latter is a per-request webhook, essentially, and would have the lowest overhead at the cost of ceremony (the client now needs to have a running web server).

By the way, long polling was popularized by Comet [2] around 2006.

[1]: https://en.wikipedia.org/wiki/Server-sent_events

[2]: https://en.wikipedia.org/wiki/Comet_(programming)

link
TeMPOraL 792 days ago
Wait, how is having the client run its own http(s) server and accept regular HTTP(S) requests the lowest overhead option? Sounds like the highest overhead one, with all the protocol statelessness.
link
tsimionescu 793 days ago
That's typically called HTTP long polling, and it's a commonly used alternative to things like WebSockets.
link
hamandcheese 793 days ago
This is just long-polling, right?
link