Universal Packet Format
General Packet Format
Ping Protocol comprises a binary packet format. All packets have the same structure which is defined in the table below.
| Byte index | Data Type | Name | Description |
|---|---|---|---|
0 | u8 | 'B' | decimal value 66, hex 0x42 |
1 | u8 | 'R' | decimal value 82, hex 0x52 |
2-3 | u16 | N | number of bytes in the payload |
4-5 | u16 | packet_id | unique id for each packet type |
6 | u8 | reserved | set to 0 |
7 | u8 | reserved | set to 0 |
8 to (8+N-1) | u8[] | payload | payload specific to each packet_id |
(8+N) to (8+N+1) | u16 | checksum | sum of all the bytes in the packet from 0 to n, truncated to 16 bits |
Payload Conventions
Individual fields within the payload are aligned on their appropriate boundaries. So 32 bit fields are aligned on 4 byte boundaries, 16 bit fields are aligned on 2 byte boundaries and 8 bit fields can be on any byte alignment. Note that the checksum field is not necessarily aligned on a 2 byte boundary however.
Parsing Unknown Packet IDs
Note that a packet parser can easily skip over packets that it doesn't understand or need to handle by just advancing the stream beyond the payload and the checksum. It is to be expected that there could be unknown packet types in any live stream or replayed log file.
Future Proofing
It is allowed for future fields to be added to any particular packet payload. Therefore parsers should check to see that the packet length is sufficient for any fields that will be used, but should not be alarmed if the payload length is longer than expected.
Last updated