8 ms·
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 packag
by 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 agoWebsockets 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.