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_ i

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.