Packet Layout

Packet Layout Visualization

 +-+-+-+-+-------+---------------+---------------+---------------+
 |Z|R|R|A|                                                       |
 |E|E|E|C|                   Packet ID (28 bits)                 |
 |R|L|S|K|                                                       |
 +-+-+-+-+-------+---------------+---------------+---------------+
 |                                                               |
 :                                                               :

Header

• Byte 0, 4 most significant bits: Packet Information
  • LL_ZERO_CODE_FLAG 0x80 -- Packet data is run length encoded, such that series of 1 to 255 zero bytes are encoded to take 2 bytes.
  • LL_RELIABLE_FLAG 0x40 -- This packet was sent reliably (implies please ack this packet)
  • LL_RESENT_FLAG 0x20 -- This packet is a resend from the source.
  • LL_ACK_FLAG 0x10 -- This packet contains appended acks.
• Byte 0, 4 least significant bits: currently unused
• Bytes 1 - 3: (for a total of 24 bits) Packet ID, assigned by circuit
• Everything up to ACKs is potentially zerocoded for compression
• Bytes n thru n+(frequency size)
  • 1/2/4 byte ID of the message the packet contains

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

Body

• Bytes 4 to 4 + (data length)
  • Message number. This may be 1, 2 or 4 bytes in length, determined by the message priority
    • High priority messages are assigned (at run time) numbers 0x00 - 0xFE
    • Mediume priority messages are assigned (at run time) numbers 0xFF00 - 0xFFFE
    • Low priority messages are assigned (at run time) numbers 0xFFFF0000 and up
    • "Fixed" priority messages are assigned numbers in the message_template.msg file, and are currently in the range 0xFFFFFFFA - 0xFFFFFFFF

Appended Acks

• Bytes n+(data length) thru acks
  • Rest of packet is filled with as many acks from previous reliable messages as will fit.

See also: libsecondlife documentation