Archive talk:TmwAthena Packets

Thoughts on organizing

The table I currently have is too unwieldy. My best thought for now is a separate page for each, with special format, and create this page (perhaps in differently sorted versions) via transclusion. Does this wiki support subpages in the main namespace?

Packet Alignment

The alignment of the data within the packet payload can cause additional overhead if the data is not properly aligned to word boundaries. For example, in a 32-bit application, a word is a sequence of four eight-bit bytes. Any data that occupies 4 bytes or larger on this platform should always start at a (4 * n) offset (0, 4, 8, etc). Any data that is less than 4 bytes can start at any offset, so long as it does not span multiple words. A 16-bit integer could start at offset 0, 2, or 4, but not at 3, 7, or 11 because the first byte would be in one word and the second byte would be in the next word. Single byte words will always fall on word boundaries. The last piece of data should end on a word boundary as well.

To leverage the maximum efficiency, padding can be added between pieces of data to force subsequent data to be aligned to word boundaries. For example, if a packet contains a word, a half word, and a quarter word, either the data should be ordered as word, half word, quarter word, and a quarter word of padding that will be discarded by the recipient. The same data, ordered as quarter word, half word, word, then quarter word of padding would take up the same amount of space, but the word would span two different words of the packet and cause inefficient processing of that packet.

The following colors are used to indicate the alignment of the packets:

The packet is properly aligned.

The packet may or may not be properly aligned, depending on the length of variable length data.

The packet is properly aligned, but does not end on a word boundary.

The packet is not properly aligned on word boundaries and can cause additional processing overhead.