On the lookout for a Rust implementation of something that vaguely resembles DDS/RTPS, I found nothing more than a few crates that wrap around the C interfaces of other libraries, and a few people trying to build a fully DDS-compatible Rust implementation.
So what do you do in situations like this? I need at least reliable UDP multicast or something to get good high-performance data distribution across all devices, maybe with a little QoS, but I don’t need full DDS support.
Or, what is much more likely, I don’t think I need it now, but later I probably will.
So let’s build a wrapper around some existing library or use one of those crates.
“NO!,” an old raspy voice sounds in my head.
“We’re building this!” it continues, “because we already built stuff like this before DDS even existed!”.
Ah, so it gets even more complicated… Here we have code veteran instinct, a proud member of team Reinvent The Wheel – Not Invented Here, that is convinced that this can be made fast. And he’s not wrong, I did build stuff like this a long time ago.
Earlier this month, for data serialization, because serde takes too long to compile, my RTW-NIH veteran helped me out by completely rebuilding a much more lightweight serialization stack in a few days. It works like a charm, compiles really fast, and Rust clearly is the language for solving this kind of problem.
For asynchronous processing the decision was also quite easy. tokio takes too long to compile, so RTW-NIH kicked in and offered to redevelop most of that stuff too. However, elsewhere in the world, someone was already doing exactly the same thing, and it turns out smol really captures the essence of a really good solution. Ever since, smol finds itself firmly in my dependency list.
For now, for data distribution, let’s see what the RTW-NIH veteran has to say. It might be good. But, I’ll design it in such a way that if a good DDS implementation or similar pops up, it can be a plugin replacement with zero effort.