Ack/naks are sent with very high priority to ensure that retransmission stops as soon as possible
Background position updates are sent with very low priority - if the link is super congested they might not go out at all
This priority is used for most messages that don't have a priority set
Higher priority for specific message types (portnums) to distinguish between other reliable packets.
TODO: REPLACE
TODO: REPLACE
If priority is unset but the message is marked as want_ack, assume it is important and use a slightly higher priority
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.
Treated as Priority.DEFAULT
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