Packet Layout

Header (Packet ID)

 +-+-+-+-+----+--------+--------+--------+--------+--------+-----...-----+
 |Z|R|R|A|    |                                   |        |  Extra      |
 |E|E|E|C|    |    Sequence number (4 bytes)      | Extra  |  Header     |
 |R|L|S|K|    |                                   | (byte) | (N bytes)   |
 +-+-+-+-+----+--------+--------+--------+--------+--------+-----...-----+

• Byte 0: Flags
  • 0x80 LL_ZERO_CODE_FLAG -- zeroes in packet body are run-length encoded, such that series of 1 to 255 zero-bytes are encoded to take 2 bytes (first the zero, then the count). See Zerocode for example implementations.
  • 0x40 LL_RELIABLE_FLAG -- This packet was sent reliably (meaning "please acknowledge this packet")
  • 0x20 LL_RESENT_FLAG -- This packet is a resend from the source.
  • 0x10 LL_ACK_FLAG -- This packet contains appended ACKs.
  • The 4 least significant bits of byte 0 are currently unused.
• Bytes 1-4: Sequence number as a big-endian unsigned integer
• Byte 5: How many bytes of extra header is available.

If byte 5 is non-zero, then there is some extra header information. Clients which are not expecting that header information may skip it by jumping forward 'Extra' bytes into the message payload.

The term "Packet ID" is sometimes used to refer to all 4 bytes and sometimes just the sequence number.

For further discussion of the bits in the header, see Messages and Packet Accounting

Body

• Bytes (6 + extra) to (6 + extra + (data length))
  • Message number. This is a numeric encoding of the message types defined in the message_template.msg file. It may be 1, 2 or 4 bytes in length, depending on the message frequency (High, Medium, Low or Fixed). Multi-byte message numbers (for medium, low and fixed frequencies) are formatted in the packet as big-endian numbers.
    • High frequency messages are assigned (from the template file) numbers 0x01 - 0xFE.
    • Medium frequency messages are assigned (derived from numbers in the template file) numbers 0xFF01 - 0xFFFE.
    • Low frequency messages are assigned (derived from numbers in the template file) numbers 0xFFFF0001 and up.
    • Messages with "Fixed" frequency are really those with fixed message numbers, i.e. the numbers are assigned in the message_template.msg file itself. There are currently 6 of these, 0xFFFFFFFA - 0xFFFFFFFF. Even though all messages have numbers assigned to them in the template file, the Fixed frequency is kept around for legacy reasons.
  • Message data. This is different for each message type, and is defined in the message_template.msg file. A message template defines one or more blocks. The block names in the template are for human readers; they are not encoded in the message. If a block is marked Variable, one byte is stored in the message indicating how many times that block has been repeated. For blocks marked single or multiple, no block header bytes are added.

Each packet contains exactly one message. Thus, the length of the message is known before message decoding.

Extensions for backwards compatibility

Some features were added in 2023-2024 to allow extensions to the message format while retaining backwards compatibility.

1. Messages with excess bytes beyond what the template calls for are accepted and decoded, not rejected as errors. This allows old message recipients to process newly expanded messages.
2. Messages with fewer bytes than expected are allowed for a specific special case. If the last block in the message is "Variable", indicating zero or more repeats of the following block, the decoder expects a one-byte count of the number of repeats of the block. If the message body ends just before that byte, the message should be interpreted as a "Variable" block with zero repeats.

An example of such a message is "AvatarAppearance". Compare these versions of the message template:

• Old: [1]

• New: [2]

Newer versions of the message template entry for AvatarAppearance contain the section

{
    AttachmentBlock	Variable
    {	ID              LLUUID  }
    {	AttachmentPoint U8 }
}

The first extended parsing rule above allows a reader working from the old template to parse a message generated with the new template, ignoring the new fields. The second rule allows a reader working from the new template to parse a message generated with the old one, treating the new fields as not present.

Appended Acks

• Bytes (6 + extra + (data length)) through acks
  • Rest of packet is filled with as many acks from previous reliable messages as will fit.
  • The last byte of the packet is a count of how many acks are included (if LL_ACK_FLAG is set).

See also:

libopenmetaverse documentation

AW Groupies documentation