I've read through http://wiki.ros.org/msg. I have the following questions:

• the wire format for integer values - big vs little endian (assume: big endian, two's complement - correct?)
• is there any type widening from in-memory -> wire format (eg char->int)?
• float format (assume: IEEE754 single, double - correct?)
• any field padding/alignment requirements (assume: none - dense packing - correct?)
• size field for strings (assume uint32 - correct?)

Example - assume:

int8 small
float64[] values
string text

An in-memory POD representation would have:

<int8: 1 byte>
<padding: 3 bytes for minimum uint32 alignment>
<uint32 count of values>
<values[0]>
<values[1]>
....
<uint32 text strlen>
<uint8*  "content of text">

under the above assumptions we'd have on the wire:

<1 byte int8>
<4 bytes little-endian, count>
<8 bytes IEEE754 double, repeated <count> times>
<4 bytes little-endian, strlen(text)>
<uint8 *  "content of text">

is this correct?

[thanks Gijs! that helps with the padding/alignment/byte-order questions

If I may add to my question:]

There seems to be a handshaking mechanism involving a checksum of the message descriptor - looks like it is part of the setup phase. Is it possible to derive the message type from the checksum offered by a peer at runtime? (background: runtime introspection)

example - use case would be a generic client which could "do the right thing" subject to what it learns in the connection establishment phase:

• say a message-format-agnostic client connects to a ROS instance
• this client then uses the checksum offered to infer which message format was used to encode the stream and acts accordingly?

Is the message type fixed at connection establishment time (my guess), or is there any provision to convey different message formats over a given stream?

thanks in advance, Michael