[ros-users] MD5 digest issue

Eric Perko wisesage5001 at gmail.com
Mon Aug 6 15:50:49 UTC 2012

On Mon, Aug 6, 2012 at 5:39 AM, Anthony Mallet <anthony.mallet at laas.fr>wrote:

> 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 at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20120806/9015fff7/attachment-0004.html>

More information about the ros-users mailing list