The most compatible technique is long polling (with a re-established connection after X seconds if no event). Works suprisingly well in many cases and is not blocket by any proxies.
Since IE7 is no longer used we can bury long-polling for good.
71–80 of 266 posts
The most compatible technique is long polling (with a re-established connection after X seconds if no event). Works suprisingly well in many cases and is not blocket by any proxies.
Since IE7 is no longer used we can bury long-polling for good.
I made the backend for this MMO on SSE over HTTP/1.1: https://store.steampowered.com/app/486310/Meadow/ We have had a total of 350.000 players over 6 years and the backend out-scales all other multiplayer servers that exist and it's open source: https://github.com/tinspin/fuse You don't need HTTP/2 to make SSE work well. Actually the HTTP/2 TCP head-of-line issue and all the workarounds for that probably make it hard…
Earlier quoted context omitted.
It used to be 2 sockets per client, so now it's 6? Well it's a non-problem, if you need more bandwith than one socket in each direction can provide you have much bigger problems than the connection limit; which you can just ignore.
the problem is multiple tabs. if you have, e.g. a bunch of Grafana dashboards open on multiple screens in different tabs (on same domain), you will exhaust your HTTP connection limit very quickly with SSE. in most cases this is not a concern, but in some cases it is.
Or make your own tab system inside one browser tab.
I can see why that is a problem for some.
I have used SSEs extensively, I think they are brilliant and massively underused. The one thing I wish they supported was a binary event data type (mixed in with text events), effectively being able to send in my case image data as an event. The only way to do it currently is as a Base64 string.
Send an event that tells the browser to request the binary image.
Ultimately what I did was run an SSE request and long polling image request in parallel, but that wasn’t ideal as I had to coordinate that on the backend.
I made the backend for this MMO on SSE over HTTP/1.1: https://store.steampowered.com/app/486310/Meadow/ We have had a total of 350.000 players over 6 years and the backend out-scales all other multiplayer servers that exist and it's open source: https://github.com/tinspin/fuse You don't need HTTP/2 to make SSE work well. Actually the HTTP/2 TCP head-of-line issue and all the workarounds for that probably make it hard…
Probably not the same person, but did you ever play on RoD by any chance?
I made the backend for this MMO on SSE over HTTP/1.1: https://store.steampowered.com/app/486310/Meadow/ We have had a total of 350.000 players over 6 years and the backend out-scales all other multiplayer servers that exist and it's open source: https://github.com/tinspin/fuse You don't need HTTP/2 to make SSE work well. Actually the HTTP/2 TCP head-of-line issue and all the workarounds for that probably make it hard…
That's said, it's very cool. Do you have a development blog for Meadow?
I like them, they surprisingly easy to use.. One example where i found it to be not the perfect solution was with a web turn-based game. The SSE was perfect to update gamestate to all clients, but to have great latency from the players point of view whenever the player had to do something, it was via a normal ajax-http call. Eventually I had to switch to uglier websockets and keep connection open. Http-keep-alive was…
With the downsides of HTTP/1.1 being used with SSE, websockets actually made a lot of sense, but in many ways they were a kludge that was only needed until HTTP/2 came along. As you said, communicating back to the server in response to SSE wasn’t great with HTTP/1.1. That’s before mentioning the limited number of TCP connections that a browser will allow for any site, so you couldn’t use SSE on too many tabs without running out of connections altogether, breaking things.
SSEs had a severe connection limit, something like 4 connections per domain per browser (IIRC), so if you had four tabs open then opening new ones would fail.
Browsers also limit the number of websocket connections. But, if you're using HTTP/2, as you should be, then the multiplexing means that you can have effectively unlimited SSE connections through a limited number of TCP connections, and those TCP connections will be shared across tabs. (There's one person in this thread who is just ridiculously opposed to HTTP/2, but... HTTP/2 has serious benefits. It wasn't develope…
True but the limit for websockets these days is in the hundreds, as opposed to 6 for regular HTTP requests.