Very cool. Is there any need to wait until after pushing to rethinkdb before updating the websockets? I'd look for I/O concurrency here and block until they're all complete.
Possibly, that might make it faster and eliminate further blocking.
The entire convert/save/push to websockets activity though, is done on a separate _fibre_ in Crystal - essentially a spawned background thread. So even if one packet went awry, it shouldn't really block subsequent packets from coming through. I suppose I could go further, and within the spawned fibre, I could spawn another fibre for the write ops so it didn't get in the way of the web socket push op.
But then again, when I checked the Crystal CPU and memory footprint, it was really low, and even at the highest UDP telemetry rate of 60Hz, I don't think I lost any packets due to Crystal's sheer speed of handling them.
I believe most of the Codemasters racing games do have this feature. Documentation is a little scarce though, and we have to rely on their forum for information.
I was actually surprised by the number of third party racing wheels and displays that took advantage of this telemetry though. There are a lot of them that are now virtually indistinguishable from the real hardware in how they operate.
