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. :)
Striving to become a master Go/Cloud developer; Father ๐จโ๐งโ๐ฆ; ๐ค/((Full Stack Web|Unity3D) + Developer)/g; Science supporter ๐ฉโ๐ฌ; https://coder.today
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.