Live data from Hacker News

Server-Sent Events: an alternative to WebSockets

germano.dev

211–220 of 266 posts

Re: Server-Sent Events: an alternative to WebSockets

#211
post #203

Earlier quoted context omitted.

Personally, while I appreciate the difference from a promotion-of-FOSS point of view, I find it obnoxious that FOSS idealists think they can dictate the usage of the generic phrase “open source” and start these kinds of arguments in threads where non-completely-free software whose source is open comes up. We haven’t all agreed on your terminology, and the argument is not “settled” except in the minds of the folks who…

I agree, but let's give them "source available" and maybe they'll be more inclined to help? We all need to get out of the current legal/monetary system soon enough.

You give ‘em whatever you want. :) I think I’ll publish my next open source project with a license that permits no use whatsoever. Code provided for entertainment purposes only.

Re: Server-Sent Events: an alternative to WebSockets

#212
post #45

Earlier quoted context omitted.

Can you explain how H2 would make it harder to scale SSE?

The mistake they did was to assume only one TCP socket should be used; the TCP has it's own head-of-line limitations just like HTTP/1.1 has if you limit the number of sockets (HTTP/1.1 had 2 sockets allowed per client, but Chrome doesn't care...) it's easily solvable by using more sockets but then you get into concurrency problems between the sockets. That said if you, like SSE on HTTP/1.1; use 2 sockets per client (…

Sorry, what do you mean by "one for upstream and one for downstream"? You can't send messages back to the server with SSE.

Re: Server-Sent Events: an alternative to WebSockets

#214
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…

Not just great for games but for large scale webrtc signaling for p2p.

Re: Server-Sent Events: an alternative to WebSockets

#215
post #204

Earlier quoted context omitted.

Your write-up sounds like your issues with SSE stemmed from the framework/platform/server-stack you're using rather than of any problems inherent in SSE. I haven't observed any latency or scaling issues with SSE - on the contrary: in my ASP.NET Core projects, running behind IIS (with QUIC enabled), I get better scaling and throughput with SSE compared to raw WebSockets (and still-better when compared to SignalR), tho…

Isn't QUIC for IIS still being tested https://techcommunity.microsoft.com/t5/networking-blog/enabl...

Huh - that article is weird, I've been using QUIC in IIS on Windows Server "2004" (2020-04) for almost 2 years now, see https://serverfault.com/questions/824278/can-iis-serve-my-ne...

Maybe it's still in testing in Server 2022 but fine in 2004?

Re: Server-Sent Events: an alternative to WebSockets

#216
post #42

We use SSE for our APIs Server Events feature https://docs.servicestack.net/server-events with C#, JS/TypeScript and Java high-level clients. It's a beautifully simple & elegant lightweight push events option that works over standard HTTP, the main gotcha for maintaining long-lived connections is that server/clients should implement their own heartbeat to be able to detect & auto reconnect failed connections which wa…

Though in JS an EventSource does automatically try to reconnect once it notices the connection is dropped, unlike a WebSocket.

Re: Server-Sent Events: an alternative to WebSockets

#217
post #200

Earlier quoted context omitted.

Agreed, I'm curious as well. We load tested with real-clients faux-users, up to 1 million concurrent. And only stopped at 1 million because the test was becoming cost prohibitive.

The data is here: http://fuse.rupy.se/about.html Under Performance. Per watt the fuse/rupy platform completely crushes all competition for real-time action MMOs because of 2 reasons: - Event driven protocol design, averages at about 4 messages/player/second (means you cannot do spraying or headshots f.ex. which is another feature in my game design opinion). - Java's memory model with atomic concurrency parallelism ov…

This is fantastic information.

Re: Server-Sent Events: an alternative to WebSockets

#218

the biggest drawback with SSE, even when unidirectional comm is sufficient is > SSE is subject to limitation with regards to the maximum number of open connections. This can be especially painful when opening various tabs as the limit is per browser and set to a very low number (6). https://ably.com/blog/websockets-vs-sse SharedWorker could be one way to solve this, but lack of Safari support is a blocker, as usual.…

Another way to solve it could be using a BroadcastChannel to communicate between tabs, do some kind of leader election to figure out which one should start the EventSource, and then have the leader relay the events over the channel.

Re: Server-Sent Events: an alternative to WebSockets

#219
post #60

Earlier quoted context omitted.

While 350k simultaneous connections is nice, I'd be extremely skeptical of that being any kind of world record

The world record is not the 1.100 concurrent users per machine (T2 small then medium on AWS) we had at peak, but the 99.6% connections we managed. All other multiplayer games have ~80% if they are lucky! 350.000 was the total number of players during 6 years.

Two nines and a world record, get this man a trophy!

Re: Server-Sent Events: an alternative to WebSockets

#220
post #197

Earlier quoted context omitted.

In my experience, sse times out way more than ws, even if you are always sending (I was streaming jpegs using sse).

I think it might be your ISP. For example one of my ISPs cut off my SSH connections no matter what I do. They simply dislike hanging SSH connections. It's just random that your ISP like WebSockets more than long HTTP responses, and it can change in a heartbeat and for most people it will be different. As I said before 99,6% successful networking is an unheard of number for real-time multiplayer games. I only care abo…

It's not random. Having limited timeouts for http is policy set at often time several layers to prevent certain types of security regressions.
Post reply on HN