[wewewedxfgdf]

I wrote a subsystem the other day that used websockets for a server to distribute video conversion tasks.

After futzing with silly things like file transfers and communication protocols I chucked it out and rewrote it so the client does HTTP long polling of the server and uploads its renders via hTTP POST.

So much easier.

[ricardobeat]

That used to be called “Comet” back in the early 2000s.

Did you try using an established library like socket.io, connectRPC etc? They handle a lot of the complexity.

[wewewedxfgdf]

Long polling is easy - all it means is your server does not immediately respond - nothing more to it than that.

[ricardobeat]

Not really the case for user-facing applications. Proxies can time out, detecting stalls is hard, reconnection is expensive, TCP slow start means higher latency, the overhead is huge for small messages. Implementing it properly is not trivial, the WebSocket standard was created precisely to improve on those shortcomings. Good for you that it works for your case, though if all you need is to listen to a stream you might also be better served by SSE.

I was asking since Socket.io, for example, takes care of file uploads, reconnection, the whole HTTP upgrade flow, and is extremely easy to use, both on client and server. On top of that it can fall back to long-polling if WS is not available.

Here's a link for educational purposes: https://en.wikipedia.org/wiki/Comet_(programming)

[noduerme]

Long polling is great for most things that don't need a realtime push. It just gets to be a strain on a server if you've got to set up and tear down lots of those connections from lots of users. Keeping a socket alive is a lot less resource intensive. Maybe it sounds stupid, but I've even converted PHP code that responded to long polling to handle the same polling over a socket to save resources. Most of my apps that need some kind of lazy updates actually work this way, and fall back to REST polling the same services if the socket is down.