# 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

enum 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.

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. This adds an additional 13 bits on top what is used for UNRELIABLE.
  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.
  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.
  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. 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.
  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