Streaming ChatGPT via SSE in Elixir: https://github.com/wojtekmach/mix_install_examples/pull/22#i...
Server-sent events
61–70 of 111 posts
Re: Server-sent events
#62Server Sent Events infamously have low global connection limit per origin[1], so if you have multiple tabs open for a single site you'll run into it pretty quickly. If it weren't for that, they would be great. [1] https://stackoverflow.com/questions/18584525/server-sent-eve...
You can do leader election[1] in that case
Re: Server-sent events
#63I know alot of websites and engineers use Websocket for push only data. SSE is tailored made for real time one sided updates! In fact, I think it made a better chat protocol, when we built a chat system at a previous job, similar to Slack. We ended up leveraging SSE to push updates to channels and traditional HTTP requests to send data to the server, resulting in lower latency and less overhead on the server side. We…
The big problem i've run into with SSE is the connection limit [1]: > Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum number of open connections, which can be specially painful when opening various tabs as the limit is per browser and set to a very low number (6). The issue has been marked as "Won't fix" in Chrome and Firefox. This limit is per browser + domain, so that means that you…
> The natural way to use SSE is to create an EventSource on each page. If you do this, and your user opens six tabs, they can now no longer make HTTP requests to your site. Not just SSE requests, any HTTP requests at all!
You can use EventSource in a singleton worker and use postMessage to forward messages to all open browser tabs for the same origin.
Re: Server-sent events
#64Earlier quoted context omitted.
You pretty much just have to listen for and handle premature closing of the underlying TCP connection. It's the only form of dead peer detection you'll get if someone just abrubtly closes their browser tab.
Do server frameworks really require you to think of the TCP connection?
Not TCP specifically, but ASP.NET Core binds your controller/action methods' CancellationToken parameter (if present) to HttpContext.RequestAborted - so assuming one uses it correctly (e.g. tying it to things like SQL TRANSACTION/ROLLBACK) then that helps prevent inadvertent changes if the user clicked their browser's Stop button after a POST, or gracefully handle long file upload failures, and so on.
Re: Server-sent events
#65Server Sent Events infamously have low global connection limit per origin[1], so if you have multiple tabs open for a single site you'll run into it pretty quickly. If it weren't for that, they would be great. [1] https://stackoverflow.com/questions/18584525/server-sent-eve...
That's just over HTTP/1. For HTTP/2 (which most people should be using anyway), the limit is 100.
Re: Server-sent events
#66What is the advantage of SSE over streaming ndjson?
Built-in client API for parsing and event dispatching. Data doesn't have to be JSON encoded. But fundamentally nothing that Comet, steaming XHR, etc, WebSockets, can't do.
A streaming XHR is more wasteful in that it constantly has to renegotiate TLS. This is unlike EventSources and WebSockets, which do not.
Re: Server-sent events
#67Earlier quoted context omitted.
No, the browser's HTTP connection limits still apply on HTTP2, each `EventSource` per tab counts against this limit of I think 6 (?) connections. Websockets to my knowledge have no such limit because they are not HTTP requests.
I believe you have it essentially backward. Websockets consume a connection no matter what, as the protocol does not work with HTTP2 (there was an attempt, but I believe it wasn't adopted and abandoned). The SSE requests do work with HTTP2, as do some other old methods like long polling. All the tabs will generally share one connection to that domain.
> Websockets consume a connection no matter what, as the protocol does not work with HTTP2 (there was an attempt, but I believe it wasn't adopted and abandoned).
Are you thinking of RFC 8441? https://www.rfc-editor.org/rfc/rfc8441
If so, then it's already implemented by Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1434137
...and by Chrome/Chromium since 91: https://chromestatus.com/feature/6251293127475200
Re: Server-sent events
#68I know alot of websites and engineers use Websocket for push only data. SSE is tailored made for real time one sided updates! In fact, I think it made a better chat protocol, when we built a chat system at a previous job, similar to Slack. We ended up leveraging SSE to push updates to channels and traditional HTTP requests to send data to the server, resulting in lower latency and less overhead on the server side. We…
The big problem i've run into with SSE is the connection limit [1]: > Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum number of open connections, which can be specially painful when opening various tabs as the limit is per browser and set to a very low number (6). The issue has been marked as "Won't fix" in Chrome and Firefox. This limit is per browser + domain, so that means that you…
Just create more subdomains if you really need more sockets.
Or move away from the browser. Browsers are toxic now.
Re: Server-sent events
#69Love to see stuff like this on the HN front page, when I know tons of web devs that have never even heard of SSE. Tangentially, I’m having a massive problem with SSE datastreams erroring out about two minutes in for “ERR: Network chunk encoding” reasons, anyone else seen this before?
You need to send "keep-alive" "noop" to keep the routers happy, I do it ever 5 seconds.
Re: Server-sent events
#70I know alot of websites and engineers use Websocket for push only data. SSE is tailored made for real time one sided updates! In fact, I think it made a better chat protocol, when we built a chat system at a previous job, similar to Slack. We ended up leveraging SSE to push updates to channels and traditional HTTP requests to send data to the server, resulting in lower latency and less overhead on the server side. We…
I used both WebSockets and SSE. In one project, I even support WebSockets and a fallback working like what you describe. I'm sold on using SSE for pushed updates. But how is regular requests + SSE easier on the server compared to WebSockets? It seems like an open connection to maintain in both cases plus additional http request for the SSE+requests case.
You need to multi-thread your server on shared memory to build many-to-many solutions. The simplest way to get that working is Java + NIO with concurrent package, I have done it for you: http://github.com/tinspin/rupy
My web server outperforms everything on the planet for multiplayer.
Websockets are notoriously hard to parallelize if you want shared memory which you need for many-to-many, mostly because JavaScript and C++ have very poor atomic concurrency, or atleast I never found any Websocket server that could do it.