The priority of this message for sending.
Higher priorities are sent first (when managing the transmit queue).
This field is never sent over the air, it is only used internally inside of a local device node.
API clients (either on the local node or connected directly to the node)
can set this parameter if necessary.
(values must be <= 127 to keep protobuf field to one byte in size.
Detailed background on this field:
I noticed a funny side effect of lora being so slow: Usually when making
a protocol there isn’t much need to use message priority to change the order
of transmission (because interfaces are fairly fast).
But for lora where packets can take a few seconds each, it is very important
to make sure that critical packets are sent ASAP.
In the case of meshtastic that means we want to send protocol acks as soon as possible
(to prevent unneeded retransmissions), we want routing messages to be sent next,
then messages marked as reliable and finally 'background' packets like periodic position updates.
So I bit the bullet and implemented a new (internal - not sent over the air)
field in MeshPacket called 'priority'.
And the transmission queue in the router object is now a priority queue.
Ack/naks are sent with very high priority to ensure that retransmission
stops as soon as possible
Generated
from enum value: ACK = 120;
BACKGROUND
BACKGROUND:10
Background position updates are sent with very low priority -
if the link is super congested they might not go out at all
Generated
from enum value: BACKGROUND = 10;
DEFAULT
DEFAULT:64
This priority is used for most messages that don't have a priority set
Generated
from enum value: DEFAULT = 64;
HIGH
HIGH:100
Higher priority for specific message types (portnums) to distinguish between other reliable packets.
Generated
from enum value: HIGH = 100;
MAX
MAX:127
TODO: REPLACE
Generated
from enum value: MAX = 127;
MIN
MIN:1
TODO: REPLACE
Generated
from enum value: MIN = 1;
RELIABLE
RELIABLE:70
If priority is unset but the message is marked as want_ack,
assume it is important and use a slightly higher priority
Generated
from enum value: RELIABLE = 70;
RESPONSE
RESPONSE:80
If priority is unset but the packet is a response to a request, we want it to get there relatively quickly.
Furthermore, responses stop relaying packets directed to a node early.
The priority of this message for sending. Higher priorities are sent first (when managing the transmit queue). This field is never sent over the air, it is only used internally inside of a local device node. API clients (either on the local node or connected directly to the node) can set this parameter if necessary. (values must be <= 127 to keep protobuf field to one byte in size. Detailed background on this field: I noticed a funny side effect of lora being so slow: Usually when making a protocol there isn’t much need to use message priority to change the order of transmission (because interfaces are fairly fast). But for lora where packets can take a few seconds each, it is very important to make sure that critical packets are sent ASAP. In the case of meshtastic that means we want to send protocol acks as soon as possible (to prevent unneeded retransmissions), we want routing messages to be sent next, then messages marked as reliable and finally 'background' packets like periodic position updates. So I bit the bullet and implemented a new (internal - not sent over the air) field in MeshPacket called 'priority'. And the transmission queue in the router object is now a priority queue.
Generated
from enum meshtastic.MeshPacket.Priority