http long polling is still one of the most funniest hackiest invention ever
Conversation
this is up there with, live stream over gif
1
19
ter explaination
http long polling works by sending a request, and the server only responding once it got a notification, so you would have a http request open for like ages
live stream over gif is just,, keep responding with new gif frames to a gif http request
5
22
Replying to
It was 100% legitimate before WebSockets. HTTP/2 obsoletes WebSockets outside the browser since you can multiplex bidirectional streams over the same persistent connection. WebSockets are now essentially just a workaround for not having access to that from JS in a browser.
2
saying http/2 obsoletes websockets sounds like a bit of a stretch, but look at what people actually used it and pushed others to use it for I can see why that can be a conclusion
2
It has bidirectional binary streams. It essentially has a more flexible equivalent to WebSockets at the protocol level instead of built on top of it. It's a separate thing from the push feature. They essentially built the WebSocket functionality into it.
2
Replying to
SCTP sockets, sure, since it's a message-based protocol. HTTP/2 isn't actually a good implementation of this for real-time use due to being implemented on top of TCP. It's awkward. HTTP/3 fixes it by moving to a more modern take on SCTP with baseline authenticated encryption.
2
1
HTTP/2 has all the issues tied to TCP along with messages and streams blocking each other since TCP has no clue that isn't a bunch of separate streams. Still way friendlier to servers, routers, etc. than opening a dozen TCP connections to server as was done for HTTP/1.1 though.
1
1
Normally, an HTTP/2 connection gives you ~128 concurrent streams and each of those is message-based. The problem is that it's all being done through a TCP connection oblivious to messages and streams. It might have made more sense to just skip right to the HTTP/3 approach.