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

Message Number

This is a variable-length numeric encoding (big-endian) 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.

        [   header   ] [ msg num ] [ data ]
Fixed:  .. .. .. .. .. FF FF FF XX .. .. ..
Low:    .. .. .. .. .. FF FF XX XX .. .. ..
Medium: .. .. .. .. .. FF XX .. .. .. .. ..
High:   .. .. .. .. .. XX .. .. .. .. .. ..

0xFFFFFFFA - 0xFFFFFFFF are Fixed frequency messages.

0xFFFF0001 - 0xFFFFFFF9 are Low frequency messages.

0xFF01 - 0xFFFE are Medium frequency messages.

0x01 - 0xFE are High frequency messages.

Messages with "Fixed" frequency are those with truly fixed message numbers, i.e. the numbers are assigned in the template file itself, for example PacketAck is assigned 0xFFFFFFFB. 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 template 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:

• 5 bytes for the header.
• 1 byte for High frequency message number.
• N extra bytes denoted by the 5th byte. (see above)
• M bytes for message data. (see template)

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