PacketPriority.h File Reference

This file contains enumerations for packet priority and reliability enumerations. More...

Go to the source code of this file.

Enumerations

enum  PacketPriority {
  IMMEDIATE_PRIORITY, HIGH_PRIORITY, MEDIUM_PRIORITY, LOW_PRIORITY,
  NUMBER_OF_PRIORITIES
}
 These enumerations are used to describe when packets are delivered. More...
 
enum  PacketReliability {
  UNRELIABLE, UNRELIABLE_SEQUENCED, RELIABLE, RELIABLE_ORDERED,
  RELIABLE_SEQUENCED, UNRELIABLE_WITH_ACK_RECEIPT, RELIABLE_WITH_ACK_RECEIPT, RELIABLE_ORDERED_WITH_ACK_RECEIPT,
  NUMBER_OF_RELIABILITIES
}
 

Detailed Description

This file contains enumerations for packet priority and reliability enumerations.

Enumeration Type Documentation

◆ PacketPriority

These enumerations are used to describe when packets are delivered.

Enumerator
IMMEDIATE_PRIORITY 

The highest possible priority. These message trigger sends immediately, and are generally not buffered or aggregated into a single datagram.

HIGH_PRIORITY 

For every 2 IMMEDIATE_PRIORITY messages, 1 HIGH_PRIORITY will be sent. Messages at this priority and lower are buffered to be sent in groups at 10 millisecond intervals to reduce UDP overhead and better measure congestion control.

MEDIUM_PRIORITY 

For every 2 HIGH_PRIORITY messages, 1 MEDIUM_PRIORITY will be sent. Messages at this priority and lower are buffered to be sent in groups at 10 millisecond intervals to reduce UDP overhead and better measure congestion control.

LOW_PRIORITY 

For every 2 MEDIUM_PRIORITY messages, 1 LOW_PRIORITY will be sent. Messages at this priority and lower are buffered to be sent in groups at 10 millisecond intervals to reduce UDP overhead and better measure congestion control.

◆ PacketReliability

These enumerations are used to describe how packets are delivered.

Note
Note to self: I write this with 3 bits in the stream. If I add more remember to change that
In ReliabilityLayer::WriteToBitStreamFromInternalPacket I assume there are 5 major types
Do not reorder, I check on >= UNRELIABLE_WITH_ACK_RECEIPT
Enumerator
UNRELIABLE 

Same as regular UDP, except that it will also discard duplicate datagrams. RakNet adds (6 to 17) + 21 bits of overhead, 16 of which is used to detect duplicate packets and 6 to 17 of which is used for message length.

UNRELIABLE_SEQUENCED 

Regular UDP with a sequence counter. Out of order messages will be discarded. Sequenced and ordered messages sent on the same channel will arrive in the order sent.

RELIABLE 

The message is sent reliably, but not necessarily in any order. Same overhead as UNRELIABLE.

RELIABLE_ORDERED 

This message is reliable and will arrive in the order you sent it. Messages will be delayed while waiting for out of order messages. Same overhead as UNRELIABLE_SEQUENCED. Sequenced and ordered messages sent on the same channel will arrive in the order sent.

RELIABLE_SEQUENCED 

This message is reliable and will arrive in the sequence you sent it. Out or order messages will be dropped. Same overhead as UNRELIABLE_SEQUENCED. Sequenced and ordered messages sent on the same channel will arrive in the order sent.

UNRELIABLE_WITH_ACK_RECEIPT 

Same as UNRELIABLE, however the user will get either ID_SND_RECEIPT_ACKED or ID_SND_RECEIPT_LOSS based on the result of sending this message when calling RakPeerInterface::Receive(). Bytes 1-4 will contain the number returned from the Send() function. On disconnect or shutdown, all messages not previously acked should be considered lost.

RELIABLE_WITH_ACK_RECEIPT 

Same as RELIABLE. The user will also get ID_SND_RECEIPT_ACKED after the message is delivered when calling RakPeerInterface::Receive(). ID_SND_RECEIPT_ACKED is returned when the message arrives, not necessarily the order when it was sent. Bytes 1-4 will contain the number returned from the Send() function. On disconnect or shutdown, all messages not previously acked should be considered lost. This does not return ID_SND_RECEIPT_LOSS.

Same as UNRELIABLE_SEQUENCED, however the user will get either ID_SND_RECEIPT_ACKED or ID_SND_RECEIPT_LOSS based on the result of sending this message when calling RakPeerInterface::Receive(). Bytes 1-4 will contain the number returned from the Send() function. On disconnect or shutdown, all messages not previously acked should be considered lost. 05/04/10 You can't have sequenced and ack receipts, because you don't know if the other system discarded the message, meaning you don't know if the message was processed

RELIABLE_ORDERED_WITH_ACK_RECEIPT 

Same as RELIABLE_ORDERED_ACK_RECEIPT. The user will also get ID_SND_RECEIPT_ACKED after the message is delivered when calling RakPeerInterface::Receive(). ID_SND_RECEIPT_ACKED is returned when the message arrives, not necessarily the order when it was sent. Bytes 1-4 will contain the number returned from the Send() function. On disconnect or shutdown, all messages not previously acked should be considered lost. This does not return ID_SND_RECEIPT_LOSS.

NUMBER_OF_RELIABILITIES 

Same as RELIABLE_SEQUENCED. The user will also get ID_SND_RECEIPT_ACKED after the message is delivered when calling RakPeerInterface::Receive(). Bytes 1-4 will contain the number returned from the Send() function. On disconnect or shutdown, all messages not previously acked should be considered lost. 05/04/10 You can't have sequenced and ack receipts, because you don't know if the other system discarded the message, meaning you don't know if the message was processed