Video demo: https://www.youtube.com/watch?v=AyCkmbqB7ko
1,236 karma · joined August 23, 2010
The hardware is now shipping and now I'm working on improving the iOS app, which I've made open source: https://github.com/nova-device/nova-ios-app
It helped me build this: https://github.com/joewalnes/websocketd/
Author here.
Are you referring to the ping/pong message frames in the WebSocket transport protocol, or just a general heartbeating protocol layered on top of WebSockets?
If it's the former, then there's nothing ReconnectingWebSocket can do here as this is not exposed by through the standard JavaScript API. Even if it was exposed, I'm not entirely sure what it would do.
The latter requires a custom protocol built on top of the user's WebSocket messages. This would require additional code on the server to process the messages. Libraries would have to be created for the various server side WebSocket implementations. It's a much messier abstraction, and I'd prefer this library to stick to one thing and do it well.
> no mention of what happens to messages in > transit when the connection drops
In this regard it behaves exactly like a regular WebSocket connection - the message is lost. All this library care of is ensuring that a new connection is opened.
I've been using this in production for over 2 years and my load levels have not caused any usability issues (even without backoff). But no doubt for heavier sites, this will be an excellent feature, so thanks for suggesting it. If you have other feature requests, please add them to the issue tracker as I'm more likely to notice them: https://github.com/joewalnes/reconnecting-websocket/issues
In answer to your question - the use of an abstraction is to allow new features (like the one you suggested) to be added in one place so individual users can easily make use of the additions.
Like CGI, websocketd will pass additional URL path and query parameters as environment variables.
So you could access something like ws://somehost/?a=b and you'd access the QUERY_STRING environment variable in your script (which contains "a=b"). Virtually every scripting language already has a library for parsing CGI environment variables so you can do that.
Basically, websocketd tries to emulate CGI as much as possible, but provide WebSocket streams instead of HTTP responses.
huhtenberg: You're right. It's very similar to inetd - that's why the first sentence in the websocketd description is "Like inetd, but for WebSockets".
The thing it adds on top of inetd is it takes care of the protocol so the underlying app doesn't need to. Namely HTTP WebSocket handshaking and data framing.
1. So developers can do a clean checkout and it will just work. No external dependencies needed (e.g. manually installing Go, setting GOPATH etc).
2. To ensure that anyone who builds and releases it always uses the exact same version of Go.
The reason I switched to Go was to make distribution/installation for end users easier.
If you use this on top of programs like bash, well ermm, you get what you deserve ;).
Here's an example of how I used websocketd to create a little dashboard for monitoring Linux CPU/memory/IO stats. It basically uses websocketd to stream the output of vmstat to a web-page that plots the numbers: https://github.com/joewalnes/web-vmstats
Other useful examples: tailing log files, executing long running job and monitoring output, or interactive querying of datasets that require a long running 'cursor'.
This is not for everyone or everything. Remember that like CGI, a process is forked for each connection so it's not the kind of thing if you want to handle a million concurrent connections on a single server.
However for dashboards, admin tools, quick mashups, visualizations, etc - it's a pretty handy tool.
PHP has similarities to Bash scripting. Language sucks. Syntax is awful. You wouldn't want to build anything big with it. You feel dirty and ashamed every time you use it.
But... if you just want to get shit done, it's often the path of least resistance. I can live with the shame.
By the way, Mike isn't just talking about PHP here. It also applies to CGI, ColdFusion, ASP, JSP and lots of other old technologies that make you want to cry. Basically anything where you have a web server and you can just drop executable scripts in a directory.
Even though I rarely use PHP any more, I still write a lot of my Python and Ruby web-apps using classic CGI instead of the popular frameworks because it's just so quick and easy (and dirty). Deployment is a breeze, managing servers is simple and it's ideal for quick mashups. Been meaning to write more about this: http://helpmewrite.co/people/joewalnes/ideas#idea-1978
OSHPark now sells the bare PCB for $4.60: http://store.oshpark.com/products/pi-crust-v4
There's a Google Group to discuss ideas, etc: https://groups.google.com/forum/?fromgroups#!forum/picrust
I should probably add a little guide explaining what you can do (and more importantly what you shouldn't do). Thanks for bringing this up.
While I'm plugging... It has a big brother in the works over at http://quick2wire.com/ which is pimped out with a regulator, level shifters and protection diodes. This means to address the issues you raise to make it easier to tinker and reduce the chance of damage.
Note that this was a research project. It works, but there's no security, so once installed, any malicious web-page could use your browser to connect to TCP/UDP end-points.
An initial version of SmoothieCharts used SVG, but I switched to Canvas because I got slightly better performance (which actually surprised me).
That's not strictly true - for very large charts, the SVG ones performed better, but I optimized for the common case.
Recently I've been experimenting with a WebGL version - it gives MUCH better performance than both Canvas (2D) and SVG, but only works on the most recent browsers.