Live data from Hacker News

Server-Sent Events: an alternative to WebSockets

germano.dev

181–190 of 266 posts

Re: Server-Sent Events: an alternative to WebSockets

#181

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…

Checkout nchan.io

Re: Server-Sent Events: an alternative to WebSockets

#182
ESPHome (an easy to use firmware for ESP32 chips) uses SSE to send sensor data to subscribers.

I made use of that in Lunar (https://lunar.fyi/#sensor) to be able to adjust monitor brightness based on ambient light readings from an external wireless sensor.

At first it felt weird that I have to wait for responses instead of polling with requests myself, but the ESP is not a very powerful chip and making one HTTP request every second would have been too much.

SSE also allows the sensor to compare previous readings and only send data when something changed, which removes some of the complexity with debouncing in the app code.

Re: Server-Sent Events: an alternative to WebSockets

#183
post #71

Earlier quoted context omitted.

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?

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

Re: Server-Sent Events: an alternative to WebSockets

#185
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!

Re: Server-Sent Events: an alternative to WebSockets

#186

One problem I had with WebSockets is you can not set custom HTTP headers when opening the connection. I wanted to implement a JWT based authentication in my backend and had to pass the token either as a query parameter or in a cookie. Anyone knows the rationale behind this limitation?

The workaround/hack is to send your token via the "Sec-WebSocket-Protocol" header, which is the one header you're allowed to set in browser when opening a connection. The catch is that your WebSocket server needs to echo this back on a successful connection.

Re: Server-Sent Events: an alternative to WebSockets

#188
post #149

Earlier quoted context omitted.

HTTP/3 is E2E encrypted and built on UDP. What does “most routers don’t play nice with it yet” mean in that context? Do you mean middleware boxes/routers rather than end user routers?

> HTTP/3 is E2E encrypted Please elaborate.

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 a way to allow connecting to a new server in a single round trip and to allow establishing a resumed connection in zero round trips, with the client sending encrypted application data in its first flight. QUIC uses TLS 1.3 as the basis for its cryptographic handshake.

This talk will provide an overview of what the QUIC protocol does and how it works, and then will dive deep into some of the technical details. The deep dive will focus on security-related aspects of the protocol, including how QUIC combines the transport and cryptographic handshakes, and how resumption, including zero-round-trip resumption works. This will also cover how QUIC’s notion of a connection differs from the 5-tuple sometimes used to identify connections, and what QUIC looks like on the wire.

In addition to covering details of how QUIC works, this talk will also address implementation and deployment considerations. This will include how a load balancer can be used with cooperating servers to route connections to a fleet of servers while still maintaining necessary privacy and security properties. It will also look back at some of the issues with HTTP/2 and discuss which ones may need to be addressed in QUIC implementations as well or are solved by the design of QUIC and HTTP/3."

Re: Server-Sent Events: an alternative to WebSockets

#190
post #14

Earlier quoted context omitted.

See my comment below: https://news.ycombinator.com/item?id=30313403

Been reading all your comments on this thread (thank you) with interest. Can you recommend some resources for learning SSE in depth?

https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...
Post reply on HN