4 ms·

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 updat

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

by jraph 3y ago

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.