PacketPriority.h File Reference

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


Enumerations

enum  PacketPriority { IMMEDIATE_PRIORITY, HIGH_PRIORITY, MEDIUM_PRIORITY, LOW_PRIORITY }
 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.

This file is part of RakNet Copyright 2003 Jenkins Software LLC

Usage of RakNet is subject to the appropriate license agreement.


Enumeration Type Documentation

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.

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


Generated on Wed Feb 1 13:33:46 2012 for RakNet by  doxygen 1.5.7.1