5 ms·

I 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

I 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 did this because we found the following to be true: - At any given time, there are far more people reading chat messages than writing them - What matters is that updates after being sent to everyone else is that their pretty close to instantaneous but you had a 500ms window to allow for the server to receive a new message and then propagate it out. Therefore, for the sender, you update the UI optimistically so they aren't waiting for a response, and everyone else will get it in ~500ms and its imperceptible - one downside: its harder (we never figured it out before I left) to do indicators for when someone is typing. That really does seem to require two way real time connections

stevenguh 3y ago
Slack does use websocket for “someone is typing” event: https://slack.engineering/real-time-messaging/ https://slack.engineering/real-time-messaging/
franky47 3y ago
One major issue I encountered with SSE is dealing with reconnection. WebSocket makes it very easy to detect differences between a loss of network connectivity, a server dying, and a client exiting properly (eg: closing the tab), on either side of the socket. Maybe there are facilities to do so with SSE that I don't know of, but my experience in reliable server-to-client-only comms with it has been a bit rough.
- VWWHFSfQ 3y ago
  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.
  - teaearlgraycold 3y ago
    Do server frameworks really require you to think of the TCP connection?
    - VWWHFSfQ 3y ago
      High performance servers and frameworks will always have to think about the underlying sockets
    - DaiPlusPlus 3y ago
      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.
- dontlaugh 3y ago
  This also matters for load balancers. With SSE or chunked encoding long polling, it's possible to lose the client connection without the load balancer closing the connection to the server, at least for a while. WebSockets make it easy to do periodic heartbeats from the server, which puts an upper bound on how long a client connection can be in an uncertain state. This also enables client presence data, even if the client only ever receives messages.
marcellus23 3y ago
What was the challenge in typing indicators? My naive idea is that it's basically sending `typing_started` and `typing_ended` messages.
- VWWHFSfQ 3y ago
  I'm guessing that since it's not a full-duplex connection you have to send those messages out-of-band, ie, with a separate POST request API
  - hamandcheese 3y ago
    But messages themselves are already sent out-of-band as a POST request, if I understand correctly. Don't see why that couldn't be extended to include typing indicators.
- yamtaddle 3y ago
  You can skip the "typing ended". You're gonna need a shortish timeout anyway, may as well just let the "typing is happening" messages all terminate by timeout.
  - marcellus23 3y ago
    That really depends on the UX you want.
    - yamtaddle 3y ago
      What do you have in mind? I can't think of a case where you'd want "X is typing" to persist more than a second or maybe two past the last-received message that affirmed X is, in fact, still typing. I can think of cases in which a short timeout might break down in bad ways (making the notice really jittery on high-latency connections, say) but I think those are probably just situations in which any "... is typing" message is simply gonna be bad in one way or another.
      - 3y ago
jraph 3y ago
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.
- bullen 3y ago
  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 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.
  - jraph 3y ago
    > You need to multi-thread your server on shared memory to build many-to-many solutions Not necessarily, it depends on the needs, but in any case I would not expect SSE and WebSockets to be different in this regard. I'm not sure what's specifically hard to parallelize with WebSockets. Shared memory may be hard to handle but that does not seem specific to WebSockets which are just regular two way communication channels that happen to start with an HTTP request from the client.
    - bullen 3y ago
      Websockets use one TCP socket for starters with SE you use separate sockets from ingress and egress which is much simpler to scale from an infrastructural point of view. I clearly said many-to-many, everything else is trivial to scale because only many-to-many requires strictly shared memory atomic parallelization. You could write a better server in Java than javascript/c(++) but I haven't found any, and to be honest the extra complication of the binary protocol doesn't even make me curious enough to waste 5 seconds to google it. SSE over HTTP/1.1 is the final solution. Everything else is a waste of time for eternity.
twic 3y ago
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 can open 6 SSE connections across all of the tabs to www.example1.com and another 6 SSE connections to www.example2.com. (from Stackoverflow). When using HTTP/2, the maximum number of simultaneous HTTP streams is negotiated between the server and the client (defaults to 100). 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! It's also quite natural, i think, to want to use multiple separate streams. It's very convenient to write separate endpoints for various kinds of data that a page might want, for example one for streaming numerical data, one for control messages, and one for descriptive events; or one for each panel on a dashboard. Here, you can hit the limit on a single page. I wrote a thin layer over my HTTP server's APIs which lets me write a single handler which can send events via either SSE or a websocket. Then, when i build a page, i use websockets, but if i want to debug, i can still use curl to make a normal HTTP request. Also, other apps can use SSE to pull data, which only requires an HTTP client, not a websocket client. [1] https://developer.mozilla.org/en-US/docs/Web/API/EventSource https://developer.mozilla.org/en-US/docs/Web/API/EventSource
- chii 3y ago
  > It's also quite natural, i think, to want to use multiple separate streams. i dont think i'd call it natural per se - i'd say it's just "easy" to do so, and especially if each of these separate streams are managed by different teams, and it makes business sense to separate the responsibility. There should be a framework, perhaps, to allow "multiplexing" of multiple streams of events into one actual tcp connection. Of course, this requires some work, but i dont think it's actually that much extra work. It just needed to be planned out as a need, as it might be a tad hard to tack it on after the fact (tho that's not impossible either).
  - deleted 3y ago
mort96 3y ago
I don't think I understand. Both WebSockets and server-sent events are just a long lived TCP socket, right? Why would SSE be lower overhead? Why wouldn't it be more overhead to go through the whole HTTP request handling machinery for EVRY chat message everyone sends? You already have an underlying 2-way connection in the TCP socket, why not use it? And why would latency be lower with HTTP requests + SSE than with websockets?
- jongjong 3y ago
  It's not. SSE has higher overhead and there are browser limits as to how many concurrent channels a single client can consume. Also, SSE encourages you to shift complexity to the back end where it would be more appropriate on the front end. For example, the client knows which channels it needs, so why not let the client decide which channels to subscribe to over a single WebSocket connection? With SSE, you end up having to do this channel management and keep track of which user is associated with what SSE connections on the back end since the user cannot just open any number of new channels on-demand (due to limits in number of concurrent SSE connections; it's better to multiplex over a single SSE connection). If your system runs on multiple processes or hosts, figuring out which process/host a particular user is connected to is a nightmare and forces you to create clients on the back end to aggregate messages for specific users and then publish to the correct SSE connection which uses extra memory and exposes your server to potential DoS vulnerabilities. It creates the need for a bunch of complex user-connection-matching and cleanup logic on the back end and it complicates access control. I have no idea why this "let's micromanage data streams for each user individually on the back end" approach became so popular while the alternative approach of end-to-end pub/sub is rarely used when it results in a much simpler, more secure system. With end-to-end pub/sub, you can multiplex multiple channels over a single bidirectional connection in a way which conveniently and cleanly allows you to couple multiple subscriptions over that single WebSocket connection... No complex cleanup on the back end on disconnection, no risk of stale channels on the back end, no need to poll for user activity to check for subscription liveness. As soon as the WebSocket is disconnected, the client can be fully unsubscribed from all their channels on the server-side.
  - cassepipe 3y ago

stevenguh 3y ago

Slack does use websocket for “someone is typing” event: https://slack.engineering/real-time-messaging/ https://slack.engineering/real-time-messaging/

franky47 3y ago

One major issue I encountered with SSE is dealing with reconnection. WebSocket makes it very easy to detect differences between a loss of network connectivity, a server dying, and a client exiting properly (eg: closing the tab), on either side of the socket. Maybe there are facilities to do so with SSE that I don't know of, but my experience in reliable server-to-client-only comms with it has been a bit rough.

VWWHFSfQ 3y ago
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.
- teaearlgraycold 3y ago
  Do server frameworks really require you to think of the TCP connection?
  - VWWHFSfQ 3y ago
    High performance servers and frameworks will always have to think about the underlying sockets
  - DaiPlusPlus 3y ago
    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.
dontlaugh 3y ago
This also matters for load balancers. With SSE or chunked encoding long polling, it's possible to lose the client connection without the load balancer closing the connection to the server, at least for a while. WebSockets make it easy to do periodic heartbeats from the server, which puts an upper bound on how long a client connection can be in an uncertain state. This also enables client presence data, even if the client only ever receives messages.

marcellus23 3y ago

What was the challenge in typing indicators? My naive idea is that it's basically sending `typing_started` and `typing_ended` messages.

VWWHFSfQ 3y ago
I'm guessing that since it's not a full-duplex connection you have to send those messages out-of-band, ie, with a separate POST request API
- hamandcheese 3y ago
  But messages themselves are already sent out-of-band as a POST request, if I understand correctly. Don't see why that couldn't be extended to include typing indicators.
yamtaddle 3y ago
You can skip the "typing ended". You're gonna need a shortish timeout anyway, may as well just let the "typing is happening" messages all terminate by timeout.
- marcellus23 3y ago
  That really depends on the UX you want.
  - yamtaddle 3y ago
    What do you have in mind? I can't think of a case where you'd want "X is typing" to persist more than a second or maybe two past the last-received message that affirmed X is, in fact, still typing. I can think of cases in which a short timeout might break down in bad ways (making the notice really jittery on high-latency connections, say) but I think those are probably just situations in which any "... is typing" message is simply gonna be bad in one way or another.
    - 3y ago

jraph 3y ago

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.

bullen 3y ago
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 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.
- jraph 3y ago
  > You need to multi-thread your server on shared memory to build many-to-many solutions Not necessarily, it depends on the needs, but in any case I would not expect SSE and WebSockets to be different in this regard. I'm not sure what's specifically hard to parallelize with WebSockets. Shared memory may be hard to handle but that does not seem specific to WebSockets which are just regular two way communication channels that happen to start with an HTTP request from the client.
  - bullen 3y ago
    Websockets use one TCP socket for starters with SE you use separate sockets from ingress and egress which is much simpler to scale from an infrastructural point of view. I clearly said many-to-many, everything else is trivial to scale because only many-to-many requires strictly shared memory atomic parallelization. You could write a better server in Java than javascript/c(++) but I haven't found any, and to be honest the extra complication of the binary protocol doesn't even make me curious enough to waste 5 seconds to google it. SSE over HTTP/1.1 is the final solution. Everything else is a waste of time for eternity.

twic 3y ago

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 can open 6 SSE connections across all of the tabs to www.example1.com and another 6 SSE connections to www.example2.com. (from Stackoverflow). When using HTTP/2, the maximum number of simultaneous HTTP streams is negotiated between the server and the client (defaults to 100). 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! It's also quite natural, i think, to want to use multiple separate streams. It's very convenient to write separate endpoints for various kinds of data that a page might want, for example one for streaming numerical data, one for control messages, and one for descriptive events; or one for each panel on a dashboard. Here, you can hit the limit on a single page. I wrote a thin layer over my HTTP server's APIs which lets me write a single handler which can send events via either SSE or a websocket. Then, when i build a page, i use websockets, but if i want to debug, i can still use curl to make a normal HTTP request. Also, other apps can use SSE to pull data, which only requires an HTTP client, not a websocket client. [1] https://developer.mozilla.org/en-US/docs/Web/API/EventSource https://developer.mozilla.org/en-US/docs/Web/API/EventSource

chii 3y ago
> It's also quite natural, i think, to want to use multiple separate streams. i dont think i'd call it natural per se - i'd say it's just "easy" to do so, and especially if each of these separate streams are managed by different teams, and it makes business sense to separate the responsibility. There should be a framework, perhaps, to allow "multiplexing" of multiple streams of events into one actual tcp connection. Of course, this requires some work, but i dont think it's actually that much extra work. It just needed to be planned out as a need, as it might be a tad hard to tack it on after the fact (tho that's not impossible either).
- deleted 3y ago

mort96 3y ago

I don't think I understand. Both WebSockets and server-sent events are just a long lived TCP socket, right? Why would SSE be lower overhead? Why wouldn't it be more overhead to go through the whole HTTP request handling machinery for EVRY chat message everyone sends? You already have an underlying 2-way connection in the TCP socket, why not use it? And why would latency be lower with HTTP requests + SSE than with websockets?

jongjong 3y ago
It's not. SSE has higher overhead and there are browser limits as to how many concurrent channels a single client can consume. Also, SSE encourages you to shift complexity to the back end where it would be more appropriate on the front end. For example, the client knows which channels it needs, so why not let the client decide which channels to subscribe to over a single WebSocket connection? With SSE, you end up having to do this channel management and keep track of which user is associated with what SSE connections on the back end since the user cannot just open any number of new channels on-demand (due to limits in number of concurrent SSE connections; it's better to multiplex over a single SSE connection). If your system runs on multiple processes or hosts, figuring out which process/host a particular user is connected to is a nightmare and forces you to create clients on the back end to aggregate messages for specific users and then publish to the correct SSE connection which uses extra memory and exposes your server to potential DoS vulnerabilities. It creates the need for a bunch of complex user-connection-matching and cleanup logic on the back end and it complicates access control. I have no idea why this "let's micromanage data streams for each user individually on the back end" approach became so popular while the alternative approach of end-to-end pub/sub is rarely used when it results in a much simpler, more secure system. With end-to-end pub/sub, you can multiplex multiple channels over a single bidirectional connection in a way which conveniently and cleanly allows you to couple multiple subscriptions over that single WebSocket connection... No complex cleanup on the back end on disconnection, no risk of stale channels on the back end, no need to poll for user activity to check for subscription liveness. As soon as the WebSocket is disconnected, the client can be fully unsubscribed from all their channels on the server-side.
- cassepipe 3y ago