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…
Server-Sent Events: an alternative to WebSockets
181–190 of 266 posts
Re: Server-Sent Events: an alternative to WebSockets
#182I 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
#183Earlier 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?
Re: Server-Sent Events: an alternative to WebSockets
#184I also had no problems with HAProxy, it worked with websockets without any issues or extra handling.
Re: Server-Sent Events: an alternative to WebSockets
#185I 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…
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
#186One 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?
Re: Server-Sent Events: an alternative to WebSockets
#187Re: Server-Sent Events: an alternative to WebSockets
#188Earlier 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.
"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
#189Question for those of you who build features on web using things like SSE or web sockets, how do you build those features in native mobile apps?
Re: Server-Sent Events: an alternative to WebSockets
#190Earlier 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?