Live data from Hacker News

Server-Sent Events: an alternative to WebSockets

germano.dev

71–80 of 266 posts

Re: Server-Sent Events: an alternative to WebSockets

#71
post #63

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.

long-polling are blocked to almost exactly the same extent as comet-stream and SSE. The only thing you have to do is to push more data on the response so that the proxy is forced to flush the response!

Since IE7 is no longer used we can bury long-polling for good.

Re: Server-Sent Events: an alternative to WebSockets

#72
post #16

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?

Re: Server-Sent Events: an alternative to WebSockets

#74
post #49

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.

Aha, ok yes then you would need to have many subdomains?

Or make your own tab system inside one browser tab.

I can see why that is a problem for some.

Re: Server-Sent Events: an alternative to WebSockets

#75

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.

In my case I was aiming for low latency with a dynamically generated image. To send a url to a saved image, I would have to save it first to a location for the browser to download it form. That would add at least 400ms, probably more.

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.

Re: Server-Sent Events: an alternative to WebSockets

#76
post #72
post #16

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?

Probably not, since I dont know what RoD is.

Re: Server-Sent Events: an alternative to WebSockets

#77
post #16

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…

Your license makes some sense, but it seems to include a variable perpetual subscription cost via gumroad. Without an account (assuming I found the right site), I have no idea what you would be asking for. I recommend making it a little clearer on the landing page.

That's said, it's very cool. Do you have a development blog for Meadow?

Re: Server-Sent Events: an alternative to WebSockets

#79

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 HTTP/2, the browser holds a TCP connection open that has various streams multiplexed on top. One of those streams would be your SSE stream. When the client makes an AJAX call to the server, it would be sent through the already-open HTTP/2 connection, so the latency is very comparable to websocket — no new connection is needed, no costly handshakes.

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.

Re: Server-Sent Events: an alternative to WebSockets

#80
post #40

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…

> Browsers also limit the number of websocket connections

True but the limit for websockets these days is in the hundreds, as opposed to 6 for regular HTTP requests.

Post reply on HN