Hi,
To make a long story short, I have an issue with MD5 digest of messages (and
services, and actions from actionlib).
Consider the following to messages:
% cat a.msg
string a
% cat b.msg
string b
They end up having a different MD5 digest because the MD5 computation considers
the field name (here `a' or `b'), so they are not interchangeable.
I am trying to figure out a way to make them still appear compatible in every
possible context. Is it possible to do this in C++, for :
- topics?
- services?
- actionlib?
Why I want to this is because I am trying to make a client able to dynamically
talk to different, unrelated servers. The client does not know at compile time
which of the message a or b it will use. Also, the two messages (or services,
or actions) are generated at compile time from another definition, so they
cannot be 'shared' by the different servers (of course, the messages `a' and
`b' are guaranteed to be compatible by other means).
If you have other means of guaranteeing that the messages are compatible, can you also guarantee that fields with the same semantics have the same names? Without that, how would the ROS system know those messages, even though they have different names, are "compatible"?
What I am trying to achieve could be compared to function pointers. Consider
the two C functions.
int a(int a);
int b(int b);
You can define a generic function pointer int (*x)(int x) than can dynamically
be bound to `a' or `b', while still having the compiler check for
compatibility and reject non matching prototypes.
I am wondering if the MD5 computation isn't too constraining here, since the
two messages `a' and `b' are clearly compatible. The parameter names is, in
general, not relevant for the interface compatibility checks, as you can see
from the C function pointer example. Since there is a serialization between
clients and servers, the parameter names don't have to match on both sides.
MD5 sums are used to identify unique message types. Messages with parameters with the same types but different names are not necessarily "compatible" at anything other than a data-on-the-wire level. For example,
$ cat velocity.msg
float64 velocity # units: m/s
$ cat battery_level.msg
float64 battery_pct # units: percentage, 0-1
While those two messages contain the same amount of bytes and those bytes are ordered the same way, their meanings are wildly different - all based on the parameter name, not the type. The MD5 sum has to include the parameter names in order to differentiate those two messages (or others like them).
- Eric
So, would the MD5 digest not consider parameters names but just parameter
types, then I my issues would go away :)
Any thoughts on how to solve this issue?
_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users