PacketPriority.h File Reference

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

This graph shows which files directly or indirectly include this file:

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 is part of RakNet Copyright 2003 Jenkins Software LLC

Usage of RakNet is subject to the appropriate license agreement.

Definition in file PacketPriority.h.

---

Enumeration Type Documentation

enum PacketPriority

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 13 of file PacketPriority.h.

{
    IMMEDIATE_PRIORITY,

    HIGH_PRIORITY,

    MEDIUM_PRIORITY,   

    LOW_PRIORITY,

    NUMBER_OF_PRIORITIES
};

enum 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 UNRELIABLE_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. 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(). 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 38 of file PacketPriority.h.

{
    UNRELIABLE,

    UNRELIABLE_SEQUENCED,

    RELIABLE,

    RELIABLE_ORDERED,

    RELIABLE_SEQUENCED,

    UNRELIABLE_WITH_ACK_RECEIPT,

    // UNRELIABLE_SEQUENCED_WITH_ACK_RECEIPT,

    RELIABLE_WITH_ACK_RECEIPT,

    RELIABLE_ORDERED_WITH_ACK_RECEIPT,

    // RELIABLE_SEQUENCED_WITH_ACK_RECEIPT,

    NUMBER_OF_RELIABILITIES
};