Live data from Hacker News

Server-Sent Events: an alternative to WebSockets

germano.dev

51–60 of 266 posts

Re: Server-Sent Events: an alternative to WebSockets

#51
Is it worth upgrading a long polling solution to SSE? Would I see much benefit?

What I mean by that is client sends request, server responds in up to 2 minutes with result or a try again flag. Either way client resends request and then uses response data if provided.

Re: Server-Sent Events: an alternative to WebSockets

#52

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.

They don't support headers in javascript, that is more a problem with javascript than SSE.

Read my comment below about that.

Re: Server-Sent Events: an alternative to WebSockets

#54

Is it worth upgrading a long polling solution to SSE? Would I see much benefit? What I mean by that is client sends request, server responds in up to 2 minutes with result or a try again flag. Either way client resends request and then uses response data if provided.

Yes, since IE7 is out of the game long-polling is no longer needed.

Comet-stream and SSE will save you alot of bandwidth and CPU!!!

Re: Server-Sent Events: an alternative to WebSockets

#55

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.

They don't block it, they cache the response until there is enough data in the buffer... just push more garbage data on the first chunks...

Re: Server-Sent Events: an alternative to WebSockets

#56
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 (…

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

Re: Server-Sent Events: an alternative to WebSockets

#57

I’m a huge fan of SSE. In the first chapter of my book Fullstack Node.js I use it for the real-time chat example because it requires almost zero setup. I’ve also been using SSE on https://rambly.app to handle all the WebRTC signaling so that clients can find new peers. Works great.

Rambly looks sick, thanks for sharing!

Re: Server-Sent Events: an alternative to WebSockets

#58
post #6

Earlier quoted context omitted.

Absolutely not, HTTP/1.1 is the way to make SSE fly: https://github.com/tinspin/rupy/wiki/Comet-Stream Old page, search for "event-stream"... Comet-stream is a collection of techniques of which SSE is one. My experience is that SSE goes through anti-viruses better!

> My experience is that SSE goes through anti-viruses better! Hmm, another commenter says the opposite: https://news.ycombinator.com/item?id=30313692

He just needs to push more data on the reply to force the anti-virus to flush the data. Easy peasy.

Re: Server-Sent Events: an alternative to WebSockets

#59
post #17

Earlier quoted context omitted.

I managed to get through almost all middle men by using 2 tricks: 1) Push a large amount of data on the pull (the comet-stream SSE never ending request) response to trigger the middle thing to flush the data. 2) Using SSE instead of just Comet-Stream since they will see the header and realize this is going to be real-time data. We had 99.6% succes rate on the connection from 350.000 players from all over the world (e…

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

[deleted]

Re: Server-Sent Events: an alternative to WebSockets

#60
post #17

Earlier quoted context omitted.

I managed to get through almost all middle men by using 2 tricks: 1) Push a large amount of data on the pull (the comet-stream SSE never ending request) response to trigger the middle thing to flush the data. 2) Using SSE instead of just Comet-Stream since they will see the header and realize this is going to be real-time data. We had 99.6% succes rate on the connection from 350.000 players from all over the world (e…

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.

Post reply on HN