I've been playing around with WebSockets. Apparently they're the new hotness. They're basically a distributed whiteboard, think of them as a realtime command-and-control IRC channel that you can access from Javascript.But since this is the Stupidest Timeline, the received wisdom for how you spin up a WebSocket server involves installing libraries that will pull in 100k lines of code from whatever the singing-est dancing-est toolkit du jour is, and do you have time to audit that crap? I don't. All this just to let you burp out literally 20 lines of on-the-wire protocol.
Enter Net::WebSocket::Server, which gets my vote. It's tiny and very low level. The documentation was confusing and functional examples nonexistent. However, I eventually figured out how to make it go, and so now you can too:
-
dna-websock.pl -- It runs separate rooms for each "path" part of the wss: URL. You have access to cookies, so you can plug in your authentication mechanism that way. -
websock-post.pl -- It lets you connect, post a notification, disconnect; or sit there and wait for a response for a little while.
Not sure what you’re trying to do with this but you might also look at MQTT. Might not be in line with what you want and it does have a bunch more overhead but there’s a lot of IoT libraries and devices and things that speak it out of the box. And the server software keeps a history of all the shit posted to it if you want to do reporting/graphing/analysis.
Or I might be majorly misreading what you’re up to in my quick skim
Common wisdom around the web says that in order to use WebSockets with nodejs, you need to use socket.io.
Don't listen. Common wisdom is crap. The JS ecosystem is riddled with cargo cultists who perpetuate library-itis without even realizing why they're using them. If you're targeting any browsers newer than IE7, pure WS is the best WS.
I know you're a perl guy and you've already found your solution so this doesn't apply to you, but you know, just in case one of the cultists jumps on here to defend how easy it is to follow a 10 year old Socket.io tutorial, I wanted to head them off at the pass.
Out of curiosity, what DNA Lounge functionality are you websocketizing? I'm intrigued :D
Working on converting our will-call lists from paper to mobile devices, with the eventual goal of not needing to cut off ticket sales when doors open. That requires updates of sensible latency.
If you just need one-way notifications, you may want to take a look at the Server-Sent Events spec. It's much simpler to implement -- you can even deliver SSEs from a CGI script, if you're so inclined -- at the expense of having no upstream data channel and potentially having bad interactions with some proxies.
Please don't. Server-Side Events have a very annoying problem. Each SSE connection counts against a small per-domain limit of how many HTTP connections you can have opened. Have 6-8 tabs (depends on the browser) and addional tabs would fail weirdly. For this reason production use of SSE requires convoluted and unreliable cross-tab communication set-up with a single master tab holding SSE connection. Example: https://fastmail.blog/2012/11/26/inter-tab-communication-using-local-storage/
(WebSocket connections do not count against HTTP per-domain limit.)
Yes, this.
When I needed websockets last from C/C++ I took a look at the available libraries for it and I couldn't for the life of me work out why they were all multi-file, many tens of thousand line monsters. Eventually I just decided to roll my own websocket server, which was 616 file lines of C++ including comments and white space.
I really should clean that up for public consumption, wrap it in some CMake and call it libtinywebsocket or something.
how will you make any money as a consultant for it then?
Oh! I did not know that's what WebSockets are. I have my own shared-state system dating back to 2011, I wonder if I could adapt it to be usable via WebSocket.