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
- Message number. This may be 1, 2 or 4 bytes in length, determined by the message priority
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