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

191–200 of 266 posts

Re: Server-Sent Events: an alternative to WebSockets

#191

Post by johnny22 »

rawoke083600 wrote: post #9

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…

I think it comes down to whether your your communication is more oriented towards sending than receiving. If the clients receive way more than they send, then SSE is probably fine, but if it's truly bidirectional then it might not work as well.

Re: Server-Sent Events: an alternative to WebSockets

#192

Post by justinsaccount »

hishamp wrote: post #179

We moved away from WebSockets to SSE, realised it wasn't makings thing any better. In fact, it made things worse, so we switched back to WebSockets again and worked on scaling WebSockets. SSE will work much better for other cases, just didn't work out for our case. First reason was that it was an array of connections you loop through to broadcast some data. We had around 2000 active connections and needed a less than…

As the other comment says, there's nothing inherent to SSE that would have made it slower than websockets. Ultimately they are both just bytes being sent across a long lived tcp connection.

Sounds like the implementation you were using was introducing the latency.

Re: Server-Sent Events: an alternative to WebSockets

#193

Post by etimberg »

hishamp wrote: post #179

We moved away from WebSockets to SSE, realised it wasn't makings thing any better. In fact, it made things worse, so we switched back to WebSockets again and worked on scaling WebSockets. SSE will work much better for other cases, just didn't work out for our case. First reason was that it was an array of connections you loop through to broadcast some data. We had around 2000 active connections and needed a less than…

Do you have any good resources on making websockets scale / stable?

Re: Server-Sent Events: an alternative to WebSockets

#194

Post by tehbeard »

88913527 wrote: post #97
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.

HTTP headers must be written before the body; so once you start writing the body, you can't switch back to writing headers. Server-sent events appears to me to just be chunked transfer encoding [0], with the data structured in a particular way (at least from the perspective of the server) in this reference implementation (tl,dr it's a stream): https://gist.github.com/jareware/aae9748a1873ef8a91e5#file-s... [0]: https…

More so the issue is the "native" browser client, EventSource [1] is pretty much just url and "withCredentials" (send/don't send cookies)

You can kludge it with fetch(...) and the body stream

1. https://developer.mozilla.org/en-US/docs/Web/API/EventSource>

Re: Server-Sent Events: an alternative to WebSockets

#195

Post by bullen »

dkersten wrote: post #169
bullen wrote: post #107

Earlier quoted context omitted.

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.

While I get and support the intent, I don't like this usage of the name of the MIT license. I personally like the license because it tells me at a glance that I can use it for any purpose, commercial or otherwise, as long as the copyright and license is included and that there is no warranty. That's it, no complications, no other demands, no "if it makes X money or not", just I include the copyright and license terms…

Ok, I agree but then I also have less time to work on real things and honestly I feel the whole legal/money part of our civilization is a huge waste of time in the face of energy problems that can't go away (2nd law of thermodynamics and sunlight + photosyntesis) and that my platform tries to help with elegantly by being the most efficient solution for MMO networking.

I'm also sad that nobody has solved this license problem yet, there is obviously a need for it. Sometimes time solves all problems though, so I probably just have to wait a while and somebody makes exactly the right license.

But I'm going to allocate some time if somebody who is willing to pay approaches me with the same concerns (it's actually why I switched to MIT in the first place, Unreal does not allow you to use client plugins that are LGPL)...

Small steps, we'll get there!

Re: Server-Sent Events: an alternative to WebSockets

#196

Post by bullen »

smashah wrote: post #185
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…

Love your hybrid model via gumroad! I do something similar for my own open-source project https://github.com/open-wa/wa-automate-nodejs There should be some sort of support group for those of us trying to monetize (sans donations) our open source projects!

I just found out gumroad pays VAT on recurring payments a couple of weeks ago.

We probably need a new license though because piggybacking on MIT (or any other license) like I try to do is rubbing people the wrong way.

But law and money are my least favourite passtimes, so I'm going to let somebody else do it first unless somebody is willing to force this change by buying a license and asking for a better license text.

Re: Server-Sent Events: an alternative to WebSockets

#197

Post by bullen »

dnautics wrote: post #160
bullen wrote: post #109

Earlier quoted context omitted.

Not if you send "noop" messages.

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 about that number, until you proove with hard stats and 350.000 real users from everywhere on the planet that WebSocket has 99,7% success rate, I'm not even going to flinch.

Re: Server-Sent Events: an alternative to WebSockets

#199

Post by sleepydog »

bullen wrote: post #67
jupp0r wrote: post #56

Earlier quoted context omitted.

The issues with TCP head-of-line blocking are resolved in HTTP/3 (QUIC).

Sure but then HTTP/3 is still binary and it's in flux meaning most routers don't play nice with it yet and since HTTP/1.1 works great for 99.9% of the usecases I would say it's a complete waste of time, unless you have some new agenda to push. Really people should try and build great things on the protocols we have instead of always trying to re-discover the wheel, note: NOT the same as re-inventing the wheel: http:/…

TCP is not perfect. There is ambiguity between the acknowledgement of a segment and the retransmission of a segment that we have tried to address with extensions and heuristics. It can introduce latency for upper protocols which are comprised of fixed-length messages. SACK reneging is a crime against humanity.

It's amazing that we've been able to adapt the protocol in a backwards-compatible fashion for over 30 years, but QUIC addresses problems with TCP in ways that could not be done in a backwards-compatible fashion. Personally I wish the protocol were simpler, but I lack the expertise to say what should be removed.

Re: Server-Sent Events: an alternative to WebSockets

#200

Post by bullen »

rlabrecque wrote: post #155
jayd16 wrote: post #144

Earlier quoted context omitted.

>backend out-scales all other multiplayer servers Can you explain what you mean here? What was your peak active user count, what was peak per server instance, and why you think that beats anything else?

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 over shared memory which needs a VM and GC to work (C++ copied that memory model in C++11, but it failed completely because they lack both VM and GC, but that model is still to this day the one C++ uses), you can read more about this here: https://github.com/tinspin/rupy/wiki

These keep the internal latency of the server below maybe 100 microseconds at saturation, which no C++ server can handle even remotely, unless they copy Java's memory model and add a VM + GC so that all cores can work on the same memory at the same time without locking!

You can argue those points are bad arguments, but if you look at performance per watt with some consideration for developer friendlyness, I'm pretty sure in 100 years we will still be coding minimalist JavaSE (or some copy without Oracle) on the server and vanilla C (compiled with C++ compiler gcc/cl.exe) on the client to avoid cache misses.

Energy is everything!

Post reply on HN