Websocketd – It's like CGI, twenty years later, for WebSockets

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?

Will you need to scale?

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.

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.

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.

if you're using a heavy runtime then maybe; a lightweight process - maybe not; most importantly, maybe you don't need to scale.

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.

> Does it reconnect when the connection breaks? Does it keep track of missing packets?

Isn't this something tcp itself does? So any protocol on top of tcp would inherit the same.

If the client goes offline for longer durations, they should attempt to reconnect after coming online.

The 'about' section on their Github page says "Like inetd, but for WebSockets", so... maybe.