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

231–240 of 266 posts

Re: Server-Sent Events: an alternative to WebSockets

#231

Post by coder543 »

xg15 wrote: post #230
coder543 wrote: post #229

Earlier quoted context omitted.

> Wasteful, but ensures that no head-of-line blocking can occur. That’s not how head-of-line blocking works. Just having a single stream doesn’t guarantee no blocking. It’s not really about unrelated requests getting in the way and sucking up bandwidth (that’s a separate issue, and arguably applies regardless of how many TCP connections you have), head-of-line blocking is about how TCP handles retransmission of lost…

> Certainly, if you have other requests in flight, you could have head-of-line blocking because of a packet that was dropped in a response stream that isn’t related to your SSE stream, but this only applies if there’s packet loss, and the packets that were lost could just as easily be SSE’s or websocket’s. That was what I meant. Yes, head-of-line blocking can occur everywhere there is TCP, but with HTTP2, the impact…

Yep, makes sense

Re: Server-Sent Events: an alternative to WebSockets

#232

Post by pier25 »

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.

WebSockets are also quite unreliable but Socket IO hides all this from you.

Re: Server-Sent Events: an alternative to WebSockets

#233

Post by mst »

bullen wrote: post #183
notreallyserio wrote: post #110

Earlier quoted context omitted.

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

Just enough to trigger the buffer... 1024-8192 bytes or something like that... a fart in space since it's just once per session!

Reminds me of needing to do similar things to convince browsers to render e.g. a custom 404 response.

Mildly annoying, but hardly onerous.

Re: Server-Sent Events: an alternative to WebSockets

#234

Post by lelanthran »

bullen wrote: post #200
rlabrecque wrote: post #155

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…

> - Java's memory model with atomic concurrency parallelism over shared memory which needs a VM and GC to work

Do you have a link that explains this bit?

Re: Server-Sent Events: an alternative to WebSockets

#235

Post by bullen »

lelanthran wrote: post #234
bullen wrote: post #200

Earlier quoted context omitted.

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…

> - Java's memory model with atomic concurrency parallelism over shared memory which needs a VM and GC to work Do you have a link that explains this bit?

Not other than the one linked in the comment above. I have been reaching out to EVERYONE, and nobody can explain this to me, but I'll implement it myself soon so I can explain it.

Re: Server-Sent Events: an alternative to WebSockets

#236

Post by gmfawcett »

hamburglar wrote: post #156
dragonwriter wrote: post #130

Earlier quoted context omitted.

> FOSS FOSS or F/OSS is a combination of Free (as defined by the FSF) and Open Source (as defined by the OSI) (the last S is Software), which recognizes that the two terms, while they come from groups with different ideological motivations, refer to approximately the same substantive licensing features and almost without exception the same set of licenses.

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 find it obnoxious that FOSS idealists think they can dictate the usage of the generic phrase “open source”

Since when was "open source" generic? These obnoxious idealists you're complaining about are the people who invented the term in the first place.

Re: Server-Sent Events: an alternative to WebSockets

#237

Post by vlovich123 »

klabb3 wrote: post #223
homarp wrote: post #188

Earlier quoted context omitted.

https://www.youtube.com/watch?v=J4fR5aztSwQ - Securing the Next Version of HTTP: How QUIC and HTTP/3 Compare to HTTP/2 "QUIC is a new always-encrypted general-purpose transport protocol being standardized at the IETF designed for multiplexing multiple streams of data on a single connection. HTTP/3 runs over QUIC and roughly replaces HTTP/2 over TLS and TCP. QUIC combines the cryptographic and transport handshakes in…

I think the common definition of e2e encryption covers user-to-user communication, so I'm confused how a transport protocol can offer e2e encryption at all (it would only do so if Quic is used over p2p between users, but that's a property of the application). But even if the definition were different, http+tls would also be e2e encrypted (if used in conjunction which it pretty much always is). I appreciate Quic but f…

The difference is that the protocol itself is also encrypted (not just the application layer). In other words middleware can’t ossify the QUIC protocol and you’re not reliant on middleware to do anything other than route UDP (which lets you do whatever you want to the protocol itself).

Re: Server-Sent Events: an alternative to WebSockets

#238

Post by dnautics »

bullen wrote: post #224
dnautics wrote: post #220

Earlier quoted context omitted.

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

Ok, what security regressions?

I am sure you can figure it out. I'm not bullshitting you.

Re: Server-Sent Events: an alternative to WebSockets

#239

Post by lelanthran »

bullen wrote: post #235
lelanthran wrote: post #234

Earlier quoted context omitted.

> - Java's memory model with atomic concurrency parallelism over shared memory which needs a VM and GC to work Do you have a link that explains this bit?

Not other than the one linked in the comment above. I have been reaching out to EVERYONE, and nobody can explain this to me, but I'll implement it myself soon so I can explain it.

The links upthread don't actually explain why a VM + GC can do shared-memory concurrency faster[1].

I don't understand what particular piece of magic makes shared-memory concurrency under a VM+GC faster than a CAS implementation.

[1] I'm assuming a shared-memory threaded model of concurrency, not a shared-nothing message passing model of concurrency.

Re: Server-Sent Events: an alternative to WebSockets

#240

Post by rawoke083600 »

coder543 wrote: post #79
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…

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

>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

Very interesting ! I honestly didn't know that, or even think about it like that ! #EveryDayYouLearn :)

Post reply on HN