4 ms·
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-time
by btown 3y 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-dropbox-file-changes https://dropbox.tech/developers/low-latency-notification-of-...
- tsimionescu 3y agoThat's typically called HTTP long polling, and it's a commonly used alternative to things like WebSockets.
- hamandcheese 3y agoThis is just long-polling, right?
- smarx007 3y 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 https://en.wikipedia.org/wiki/Server-sent_events [2]: https://en.wikipedia.org/wiki/Comet_(programming) https://en.wikipedia.org/wiki/Comet_(programming)
- TeMPOraL 3y agoWait, 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.