Ok that sounds too strange to ask, but pulling can be done using any of the methods I mentioned, including websockets.

Can be done, but not simply. For example, if you consider sending a pull-based time-boxed request for data (similar to long poll) across web socket. Since web socket is bidirectional async, the response is in no way connected to the request, could arrive at any time (or never) and in another thread. So you have to setup a state machine to track the state of each request, timeouts to give up on a response. And there is a potential for a lot of byzantine problems like out-of-order responses due to GC pauses, lost packets + network buffers, and whatnot. Not to mention dealing separately with connection interruption events. A lot of these problems are already handled by using a regular HTTP request. A good library on top of websockets could abstract this away from you like HTTP libs do for TCP. Let me know if you know of any good ones.

Oh, I think I see what you are saying. Create a web socket connection and automatically close it after a certain period of time, then reconnect and go again when the client is done processing. It would be an interesting scenario to test. Standard HTTP requests by now have mitigations for short-lived connections, but I'm not sure if they apply to web sockets. Need to test to be sure. Thanks for bearing with me. :)

I think you have in mind a specific usage that is not so popular and have rather complex requirements.

You mentioned threads, and requests and out-of-order responses, and streams, I can't think at a scenario involving all these.

You usually only need to refresh some non-real time data and make requests, you do not send a new request until you received a response from the last one.

Or have a stream of data and it can keep coming, usually you do not process them on the front end so you do not end up having a lag, and more you do not have different requests. Also JS is single threaded. No need for a request, you have a connection open so you need the latest data, otherwise it would not require a websocket.

Yeah, the experience where I wished I had a long-poll capability was on the back-end processing events. Maintaining an open connection requires a surprising amount of coding to handle failure cases. Whereas a long poll can give you realtime-stream-like behavior in normal cases and a nice protective fallback behavior in spiky cases without worrying too much about the underlying connection. I think it is probably abnormal for web-socket users to run into throughput constrained situations where they need to protectively disconnect. It's not our normal usage pattern either, but it was a possibility I had to code for.

code of conduct - report abuse