Refactor COMMS Library into Rust for Custom Binary Protocols

[DonavanMartin]

Description

This issue proposes refactoring the COMMS Library, a C++11 headers-only library for implementing custom binary communication protocols, into Rust. The goal is to create a Rust-native implementation (comms-rs) that preserves COMMS’s functionality (e.g., declarative protocol definitions, embedded system support) while leveraging Rust’s memory safety, concurrency, and modern ecosystem to enhance reliability and developer experience in industrial and embedded applications.

Motivation

• No Rust Equivalent: As of June 2025, there is no direct Rust library matching COMMS’s declarative, embedded-focused approach for custom binary protocols.
• Safety: Rust eliminates C++ issues like undefined behavior, memory leaks, and buffer overflows, critical for reliable protocol implementation in embedded systems.
• Performance: Rust’s performance is comparable to C++, suitable for resource-constrained environments.
• Ecosystem: Integration with Rust crates (e.g., byteorder, nom) can modernize COMMS for IoT and industrial use cases.

Goals

• Develop a Rust-native comms-rs library supporting core COMMS features (e.g., message/field definitions, serialization/deserialization, transport framing).
• Ensure compatibility with embedded systems using no_std for minimal resource usage.
• Provide idiomatic Rust APIs that are safe and easy to use.
• Support cross-platform use (Linux, Windows, RTOS).

Non-Goals

• Replacing the C++ implementation (Rust version can coexist).
• Adding new features beyond the current COMMS functionality.

Proposed Approach

Setup:

• Create a new repo (comms-rs) or Rust submodule in comms.
• Use cargo and Creative Commons Attribution-NonCommercial-ShareAlike 4.0 license (matching COMMS).

Implementation:

• Port COMMS’s declarative protocol framework to Rust using macros or DSL-like APIs (e.g., inspired by nom or serde).
• Implement message parsing, serialization, and transport framing with safe abstractions.
• Ensure no_std compatibility, avoiding RTTI and exceptions.

Testing:

• Unit tests with cargo test for protocol logic.
• Integration tests with sample protocols (e.g., from COMMS examples).

Documentation:

Rustdoc and examples for defining custom binary protocols (e.g., IoT sensor data).

[arobenko]

The COMMS library in its current state is a result of many years of C++ development experience in general and template meta-programming in particular. At the same time my knowledge of and experience with Rust is basically zero. Based on the very superficial knowledge I have about Rust, its core features are insufficient to implement the existing flexibility of the COMMS library features. Maybe different paradigms and patterns should be used when developing with Rust, but again I have zero experience with it to do a decent job. If you're an experienced Rust developer, take up the challenge and implement something yourself using the existing COMMS library as inspiration.

The bottom line: probably it's not going to happen in the observable future.

[TimonTerBraak]

Partially related, I was investigating the possibilities to use the protocol generated by the CommsDSL specification in Rust. Since that seems tricky, I was looking for alternatives that support more languages than C++ [1]. But I found nothing matching the human readability and features of the CommsDSL schema. @arobenko: what is your opinion on the feasibility of creating a Rust-specific codegenerator, e.g. commsdsl2rust?

Specifically I am looking into a system using Zenoh (data agnostic) with CommsDSL as the communication protocol (https://github.com/eclipse-zenoh/roadmap/blob/main/rfcs/ALL/Serialization.md).

[1] Bindings for C# were great, the type hinting for Python no so, making use somewhat difficult, especially for the 'users' of the protocol.

[arobenko]

Complexity can neither be created nor destroyed, just moved from one place to another. The CommsChampion Ecosystem originated as a C++ based solution for embedded systems. The complexity is spread and somewhat balanced between the COMMS Library, and generated code produced by the commsdsl code generators. The complexity spread is not even, the COMMS Library takes a very significant portion of it and the heavy lifting is done by the C++ built-in meta programming support.

As I mentioned earlier my Rust knowledge is virtually zero, but if I'm not mistaken it's still no match for the C++ capabilities in this regard. The Rust based solution needs to be designed from scratch (not to mentioned a necessity to spend years gaining the required Rust experience to produce such a solution). Once started, it will take years to produce something tangible. I don't think it's feasible.

The more feasible solution I think is to produce "C" wrapping for the generated C++ code, say commsdsl2c_wrap code generator, and once C interface for the protocol definition is available, maybe then it would be easier to integrate the solution into the Rust (or other programming languages) based project.

[arobenko]

The release v7.3 of the commsdsl has new commsdsl2c code generator, which provides "C" interface to the "C++" code generated by the commsdsl2comms. Having a "C" interface can make it easier to integrate with other programming languages like Rust.