forked from avaraline/Avara
-
Notifications
You must be signed in to change notification settings - Fork 0
Technical: Packets: UDP Header
Tom Anderson edited this page Sep 3, 2021
·
1 revision
The UDP Header is the small structure (4 or 8 bytes) that appears at the top of every packet sent by Avara. Here is the basic structure of the UDP Header.
Field | Size (bytes) |
Required | Description |
---|---|---|---|
CRC/Version |
2 | Yes | On transmission this contains a CRC16 checksum of the entire packet with this field replaced by the software version number. This means that, before the checksum is calculated, this field contains the version number. Upon calculating the checksum this field is then replaced with the checksum value before transmission. When unpacking a received packet this checksum is extracted and replaced with the version number and the checksum is re-calculated to verify that the packet is valid (matches the checksum). As such, instances of Avara with different version numbers will fail the checksum and not be able to communicate with each other. |
LastReceivedSerial |
2 | Yes | The last serial number, in sequence, received by the sender, plus 1 if there is an AckMap field to follow (this is why serial numbers in Avara are always even, the first bit is used as a flag). This LastReceivedSerial value is the handshake mechanism by which Avara communicates which serial numbers have been received by the sending client. The receiving client then knows that it can release held messages that have serial numbers less than or equal to this value (i.e. it will not need to resend them). If the LastReceivedSerial stops increasing (or the client stops receiving messages from this sender), then this is a hint to the receiving client that it may need to resend some older previously-sent messages. Notice that the sending client will only increase this value if it has received every message in sequence before this value. If it receives messages that have serial numbers that are 4 or more greater than this value, it will hold onto those message until it receives the missing message(s). |
AckMap |
4 | if LastReceivedSerial is odd |
If LastReceivedSerial is odd, then the AckMap field is present and it contains a 32-bit bitmap showing which messages have been received AFTER LastReceivedSerial . This is used in the case where the client has received most of its intended messages but there is at least one missing message.For example, if LastReceivedSerial is 1000, that indicates that the client has received all messages in sequence up to serial number 1000. Then, if this bitmap is set to 0x0006, that would indicate that the client has received messages with serial numbers 1004 (bit 2) and 1006 (bit 3) but is missing message 1002 (bit 1). Notice that this means the value of the AckMap will always have a zero in bit 1 (be an even number) because if the client had actually received that message it would have sent 1006 as LastReceivedSerial in the example above (and no AckMap would have been sent). |