This file contains enumerations for packet priority and reliability enumerations.
More...
Go to the source code of this file.
|
| 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
} |
| |
This file contains enumerations for packet priority and reliability enumerations.
Definition in file PacketPriority.h.
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.
|
| NUMBER_OF_PRIORITIES |
|
Definition at line 21 of file PacketPriority.h.
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
|
Definition at line 46 of file PacketPriority.h.
1.8.2 
