Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Server-Sent Events: an alternative to WebSockets

germano.dev

Post reply on HN
Print view View original

101–110 of 266 posts

Re: Server-Sent Events: an alternative to WebSockets

#101

Post by Aeolun »

HWR_14 wrote: post #77
bullen wrote: 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?

> MIT but [bunch of stuff]

Not MIT then. The beauty of MIT is that there is no stuff.

Re: Server-Sent Events: an alternative to WebSockets

#102

Post by pornel »

mmzeeman wrote: post #31

Did research on SSE a short while ago. Found out that the mimetype "text/event-stream" was blocked by a couple of anti-virus products. So that was a no-go for us.

It's not blocked. It's just that some very badly written proxies can try to buffer the "whole" response, and SSE is technically a never-ending file.

It's possible to detect that, and fall back to long polling. Send an event immediately after opening a new connection, and see if it arrives at the client within a short timeout. If it doesn't, make your server close the connection after every message sent (connection close will make AV let the response through). The client will reconnect automatically.

Or run:

    while(true) alert("antivirus software is worse than malware")

Re: Server-Sent Events: an alternative to WebSockets

#103

Post by coder543 »

leeoniya wrote: post #47

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.…

This isn’t a problem with HTTP/2. You can have as many SSE connections as you want across as many tabs as the user wants to use. Browsers multiplex the streams over a handful of shared HTTP/2 connections.

If you’re still using HTTP/1.1, then yes, this would be a problem.

Re: Server-Sent Events: an alternative to WebSockets

#105

Post by dnautics »

ricardobeat wrote: post #95
szastamasta wrote: post #33

My experience with sse is pretty bad. They are unreliable, don’t support headers and require keep-alive hackery. In my experience WebSockets are so much better. Also ease of use doesn’t really convince me. It’s like 5 lines of code with socket.io to have working websockets, without all the downsides of sse.

Mind expanding on your experience and how are websockets more reliable than SSE? one of the main benefits of SSE is reliability from running on plain HTTP.

I've done both. One big one is Sse connections will eventually time out, and you WILL have to renegotiate, so there will be a huge latency spike on those events. They are easier in elixir than most pls, but honestly if you're using elixir, you might as well use phoenix's builtin we socket support.

Re: Server-Sent Events: an alternative to WebSockets

#106

Post by waylandsmithers »

I had the pleasure of being forced to use in SSE due to working with a proxy that didn't support websockets.

Personally I think it's a great solution for longer running tasks like "Export your data to CSV" when the client just needs to get an update that it's done and here's the url to download it.

Re: Server-Sent Events: an alternative to WebSockets

#107

Post by bullen »

Aeolun wrote: post #101
HWR_14 wrote: post #77

Earlier quoted context omitted.

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?

> MIT but [bunch of stuff] Not MIT then. The beauty of MIT is that there is no stuff.

We already discussed this in an earlier thread, and however bad this looks it's better than my own license.

Here it's clear, you can either use the code without money involved and then you have MIT (+ show logo and some example code is still mine).

If you want money then you have to share some of it.

Re: Server-Sent Events: an alternative to WebSockets

#108

Post by julianlam »

This is really interesting! I wonder why it never really took off, whereas websockets via Socket.IO/Engine.io did.

At NodeBB, we ended up relying on websockets for almost everything, which was a mistake. We were using it for simple call-and-response actions, where a proper RESTful API would've been a better (more scalable, better supported, etc.) solution.

In the end, we migrated a large part of our existing socket.io implementation to use plain REST. SSE sounds like the second part of that solution, so we can ditch socket.io completely if we really wanted to.

Very cool!

Re: Server-Sent Events: an alternative to WebSockets

#109

Post by bullen »

dnautics wrote: post #105
ricardobeat wrote: post #95

Earlier quoted context omitted.

Mind expanding on your experience and how are websockets more reliable than SSE? one of the main benefits of SSE is reliability from running on plain HTTP.

I've done both. One big one is Sse connections will eventually time out, and you WILL have to renegotiate, so there will be a huge latency spike on those events. They are easier in elixir than most pls, but honestly if you're using elixir, you might as well use phoenix's builtin we socket support.

Not if you send "noop" messages.

Re: Server-Sent Events: an alternative to WebSockets

#110

Post by notreallyserio »

bullen wrote: post #71
havkom wrote: 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.

How much more data do you have to send? Is it small enough you aren't concerned about impacting user traffic quotas?
Post reply on HN