>>> gwsocket is a simple, standalone, language-agnostic, RFC6455 compliant WebSocket Server, written in C. It sits between your application and the client's browser, giving fast bidirectional communication between these two with ease and flexibility
Do any of these options support communicating via an http API instead of stdin/out?
Ideally I'd like to have a standalone websocket service that handles long-running connections and then calls my specified API eg. `POST <my-http-service>/websocket/client/<client_id>`. Then the service can respond by sending a `POST <my-websocket-service>/websocket/client/<client>`, like an opensource https://pusher.com? I realise it'd be fairly easy to build myself, just wondering if there is something off the shelf that achieves this?
I like the stdin/stdout idea from an ease of use POV, but doesn't having each connection in a separate process pose a rather significant constraint on scalability, considering also that WebSocket connections are generally considered to be long-lived?
How much do you need to scale before scaling up is not viable?
As far as memory goes, a few thousand identical processes shouldn't be too much, add memory to your computer/VM/droplet/etc until it is enough. You can also rewrite the websocket program from Python to Go (and then to C) to fit more processes into the available memory.
As far as number of processes goes, Linux can probably handle more active processes than the computer's memory can handle.
As far as file handles goes, by default I think you're limited to a few tens of thousands, but there's knobs you can turn to raise that limit.
I would guess (thumbsuck) that you might run into scale-up walls once you have more than 100k active connections on a single Linux instance[1]. At that point you have paying customers that will allow you to spend money on switching from a scale-up-based architecture to a scale-out-based architecture.
[1] My $5/m Digital Ocean droplet once handled ~50k long-lived TCP connections over a two day period without much configuration necessary. ISTR that I had to turn some knobs in /proc/... to raise the limits on file handles.
I think you are right but this is a tool explicitly designed for convenience and not for scalability. The target is more like, I need a websocket on my VPS to connect to my own app that is used only by me. Or to hack together a quick demo, which is basically the same thing.
Exactly. As a concrete example, I used websocketd a few years ago when I was debugging some geometry-heavy code and wanted to use D3 as a quick way to make a visual debugging UI. I was just running a single process locally; scale was not a concern. https://twitter.com/paulgb/status/914495701119365121
A modern Linux system can scale to a large number of processes just fine. (With a bit more configuration, it can even merge identical memory across processes, with ksm.) And if you find yourself running tens of thousands of connections that are all active, you can always move to something more scalable. In practice, something else may end up being your bottleneck. Meanwhile, this seems easy to get up and running with.
I think people vastly underestimate how much modern linux can scale on a decent computer. I had systems in the field connecting via SSH into a single VM with over 9000 concurrent connections it was fine on a KVM with about 24G of RAM and a couple cores. My WAN connection was only 250Mbps which was far more limiting in terms of traffic than SSH & KVM.
This is awesome! Websocketd occupies a similar niche to—and might pair well with—my user friendly, single-binary webserver with CGI-like capabilities called QuickServ. When I released that here, one of the comments was that it would be nice to have WebSocket support. Now, I can just point people to Websocketd!
>>> gwsocket is a simple, standalone, language-agnostic, RFC6455 compliant WebSocket Server, written in C. It sits between your application and the client's browser, giving fast bidirectional communication between these two with ease and flexibility
[1] https://gwsocket.io/man