WebSockets are easy now

Would you recommend this product?
No reviews yet
Great tool and good job on the website! Looks clean and the tutorial is really clear.
Yeah I shamelessly posted my own product. :) I think this will be useful as an alternative to hosted push services for those building web apps with streaming content (chatrooms, collaboraton, games, news feeds, stock tickers, etc). AMA
Simple, unobtrusive and agnostic, love it :) I can see other uses than pure web, for that, by the way. For example, it would make it damn easy to plug arbitrary scripts to allow data to stream across some docker containers, without having to think of a tcp binded api.
Yeah! I often use websocketd as part of a larger toolkit for duct-taping things together. For example, combine websocketd and netcat/nc/socat to bridge existing TCP services to the web-browser via WebSockets $ websocketd --port 80 nc otherhost 1234 Some people do "websocketd bash" to create a remote console. But I really really don't recommend that unless you want to get totally p0wned.
This looks very useful. Any benchmarks you can share?
@jfrattarola I'd be interested in this too. Also, how efficient/performant is a new process for each connection? Seems like the overhead of switching context will not make it worthwhile.
I don't have any benchmarks. I would like to have an independent party test it for performance. One concern many users have when first encountering it is the overhead required to launch a new process per connection. In reality (I've been running this for nearly 2 years in production) I've not found it to be a problem so long as your underlying programs start reasonably quickly. The runtime profile of a typical WebSocket connection is very different to a typical HTTP request. HTTP servers are optimized for high volumes of short requests whereas WebSockets are typically much lower volumes but longer lived connections. Also, Linux has got really good at handling large numbers of concurrent processes in recent years. tl;dr - it's good!
I've been running this on a production server which peaked at just over 10K concurrent WebSocket connections and it's been fine. The biggest constraint is memory. My server had 256GB RAM and only 30% of that was used. Assuming your programs startup reasonably quickly and don't use too much memory, all is good. Typical Python and Ruby programs are fine. Anything involving the JVM is more problematic.
@joewalnes I'm hoping you meant 256MB!
@mfkp Nope - it was a beefy server. If you're planning on scaling 10K concurrent connections on 256MB, then admittedly websocketd is not for you and you should use a single process multi-threaded architecture. Node, Go, Rust, Elixir are all excellent choices.