I need to decode/deserialized an upstream and downstream control messages in a
custom shim that sits above the EMANE MAC layer.
I initially attempted to deserialize the custom messages by including the
Google Protobuf .proto generated files in the custom shim, where the .proto
file was a duplicate of the .proto used in the message generation layer.
Implementing the same deserialization .proto and Google Protobuf generated
files in a different software components leads to a runtime error as a fatal
exception. This issue is described in the following URL.
A proposed solution to this problem is to implement the .proto serialization
files in a shared library used by both components. The other is to use static
linking, which is less desirable.
One solution I came up with was to simply rename the .proto in the different
layer to avoid the collision. This was not the most desirable solution.
Instead, I was able to place the common .proto deserialization into a common
library, and use the deserialization in two different layers without any issue.
For the benefit of other EMANE developers, it thought it was useful to describe
this issue and the possible solutions to the broader audience.
The solution suggests that EMANE best practices for custom NEM stack
development is such that if serialization for messages is to be used in
different NEM stack elements, then the .proto generated content (and perhaps a
wrapper class) need to be placed into a shared library.
So a question I have related to message deserialization in EMANE layers, is to
gain some understanding of when the message id indicates it is a serialized
control message (via pmsg->getId() ==
EMANE::Controls::SerializedControlMessage::IDENTIFIER), and when it is not.
Both use protobuf based serialization of content.
Is the distinction that a serialized control message id is used when the
message migrates across process boundaries via the transport, and the id is not
serialized control message when it exists only within the EMANE NEM stack
emane-users mailing list