Bugs item #1667244, was opened at 2007-02-24 03:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=723099&aid=1667244&group_id=132078
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: protocol
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tim Ansell (mithro)
Assigned to: Nobody/Anonymous (nobody)
Summary: 4 byte alignment guarantee filter?
Initial Comment:
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 reasonin 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.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=723099&aid=1667244&group_id=132078
_______________________________________________
tp-bugs mailing list
[email protected]
http://mail.thousandparsec.net/cgi-bin/mailman/listinfo/tp-bugs
