Hello,
After writing a C protocol decoder for TP03 the most annoying feature
is the fact that messages are not necessarily aligned internally on any
boundary. The only data type thing that breaks this (at the 32bit
level) is strings. Otherwise I could assume that, and remove a lot of
stupid memcpy()s.
It would be nice if strings of (length % 4) != 0 where padded to next 4
bytes. This gives two benefits:
- Faster code - pulling members out using:
x = ntohl(data[offset]);
is faster then:
memcpy(&tmp, data + offset, sizeof(int32_t));
x = ntohl(tmp);
[Yes, data is a different type in both examples - not relevant
here]
[Cost of data[offset] == *(data + offset) by definition, so
yes the first is always faster]
- Simpler code - see above. This is probably the bigger reason
in my book. Simple code == maintainable code.
This affects no other type in tp03, so existing code can continue to be
used for everything _but_ strings. Newly written code can take
advantage of the stronger guarantees.
Downsides:
Larger messages. For the 'object' message it is about a 1.5% extra
size. Considering the same message has 8% reserved overhead... I can't
see it as a major issue. If the size of the data over the network
becomes a major concern, compression would be a better solution.
Note that the string format has changed since tp01, and tp02, so it's
obviously not a huge issue to have it changed.
One thing to note, this allows direct access for 32bit members - which
are the bulk of the message types. 64bit (or larger!) members still
need to be copied out. For TP23 (when 64bit machines are the norm ;-)
maybe I'll suggest an 8 byte padding rule.
Other advantages are allowing better use of data in the message - it
can be read and directly responded too, which is particularly useful for
smaller messages in certain cases. Essentially at the moment the entire
message needs to be copied out piece-by-piece. This allows either block
copying or direct access to relevant pieces. Also processing the header
of message can now be done in place (since fragmentation won't happen
below a 4bytes).
And to head of an argument at the pass: No this doesn't encourage use
of dumping structs on the network. Any message with a variable length
field can't use that technique anyway, and forcing packing is the same
for both 1 and 4 ie If you want to write unportable code, this doesn't
help or hinder you.
Regards,
nash
_______________________________________________
tp-devel mailing list
[email protected]
http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
