WebsocketD

WebSockets are easy now

get it
There are no images or videos added to the gallery.
Add to gallery

Reviews

Discussion

You need to become a Contributor to join the discussion - Find out how.
Greg Gilbert
Greg Gilbert@gregoiregilbert · I make products and run companies.
Great tool and good job on the website! Looks clean and the tutorial is really clear.
Joe Walnes
Joe WalnesMaker@joewalnes · Inventor. novaphotos.com. @joewalnes
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
Olivier El Mekki
Olivier El Mekki@oelmekki · maker
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.
Joe Walnes
Joe WalnesMaker@joewalnes · Inventor. novaphotos.com. @joewalnes
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.
Joshua Frattarola
Joshua Frattarola@jfrattarola · Chief Architect & Co-Founder
This looks very useful. Any benchmarks you can share?
★ Karan Goel ☂
★ Karan Goel ☂@karangoel · Engineer @ Google
@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.
Joe Walnes
Joe WalnesMaker@joewalnes · Inventor. novaphotos.com. @joewalnes
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!
Joe Walnes
Joe WalnesMaker@joewalnes · Inventor. novaphotos.com. @joewalnes
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!
Joe Walnes
Joe WalnesMaker@joewalnes · Inventor. novaphotos.com. @joewalnes
@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.