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

Reply via email to