Hacker News Reader

Comment by kreetx | Hacker News Reader

Server 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...

View on HN

That's just over HTTP/1. For HTTP/2 (which most people should be using anyway), the limit is 100.

I've never worked with Web Workers, but the doc page mentions them at the very top. Isn't that the intended workaround? Have a background thread that receives the events & coordinates, rather than having each page deal with them?

Yes, that's `ShardedWorker`.

I wanted so use these in a project recently, only to find out that they aren't supported on Chrome for Android. This makes them non-usable for me, since there is no drop-in polyfill available yet.

If you are doing websocket in there, you could fall back to main thread, but it comes at the cost of code duplication.

You can do leader election[1] in that case

[1] https://greenvitriol.com/posts/browser-leader

Sophisticated services that offer SSE will have many different endpoint domains to get around browser limits on simultaneous connections to the same service.

endpoint-00.example.com endpoint-01.example.com endpoint-02.example.com

etc. It isn't specific to SSE. It's any HTTP request. SSE is just the most obvious because the connections stay open for long periods.

And that's an easy workaround, with wildcard DNS entries and certs.

That's what I'm saying: it's not that good for non-sophisticated services, you need workarounds to make this "great technology" work. Might as well switch to websockets and not worry about this.

Another "workaround" is to enable HTTP/2, which should be already enabled if the system is managed by a competent admin who cares about his work.

Right, but with websockets you wouldn't have to think about this at all.

You'd also need to ensure http2 for local development, proxies in between, etc. You _can_ do all this, but you can also avoid putting any thought into this matter.

This problem is fixed by using HTTP/2.

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.

This is simply not true, it's negotiated between the client and server and defaults to 100 usually. 6 is the limit for http 1.1 not http/2.

Source: https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...

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

Thanks. Last time I checked I still saw them consuming connections, but I suppose that's probably the far end not supporting it.

Reply on news.ycombinator.com