bitmask endiannes in 0.6
Ákos Maróy
Just to confirm, is the bitmask endiannes little endian in MXP 0.6?
just want to be sure to understand the following field in the packet
header right, from here:
file:///home/maroy/src/mxp/doc/MXP%20UDP%20Transport%20Draft%200.6.html
1 : bitmask : flags /* Bitmask containing packet type flags and
guaranteed flag. */
/* Type bit being set is that of packet type index. */
/* 7th bit is guaranteed flag. 8th bit not used. */
how would this look like exactly, given an 8 bit byte? which bits are
the packet type flag (I understand this would be a number of bits),
which is the guaranteed flag, etc?
Akos
Tommi Laukkanen
--
You received this message because you are subscribed to the Google Groups "Metaverse eXchange Protocol" group.
To post to this group, send email to metaverseexc...@googlegroups.com.
To unsubscribe from this group, send email to metaverseexchangep...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/metaverseexchangeprotocol?hl=en.
Ákos Maróy
> I would say we can use either as network level bit ordering is handled
> by data link layer in OSI model? So we just have to define which index
> is least significant bit and rest of the bit indexes can be deduced.
> Would you rather see 0 as lsb?
actually, bit fields / bit masks are a tricky issue, and usually not
really portable. so my suggestion would be to be totally specific in the
spec, and instead of specifying a 'bitmask' type, I'd specify the
integral type (say, an 8-bit byte), and then specifically a bitmask on
how it is used. the endianness is already handled by how we encode 8-bit
bytes. as for the fields, I'd have some documentation like:
bits: 76543210
values: xGTTTTTT
where:
x: not used
G: guaranteed flag, 1 if the packet is guaranteed, 0 otherwise
TTTTTT: the packet type, 6 bits in total (I don't know how many bits you
wanted to allocate for the packet type, maybe less than 6)
what do you think?
Akos
Tommi Laukkanen
Akos