firmware icon indicating copy to clipboard operation
firmware copied to clipboard

If a packet is heard multiple times, rebroadcast using the highest hop limit

Open erayd opened this issue 11 months ago • 18 comments

Sometimes a packet will be in the TX queue waiting to be transmitted, when it is overheard being rebroadcast by another node with a higher remaining hop limit. When this occurs, modify the pending packet in the TX queue to avoid unnecessarily wasting hops.

This is intended to help solve the problem of a router node with excellent coverage (A) hearing a packet bounce around between several poorly-placed nodes while waiting for the opportunity to rebroadcast. On a busy mesh, this can mean that the first copy of the packet that (A) hears may have had its hop limit prematurely reduced, and a better version is subsequently received.

This is more relevant to the late-rebroadcast scenario implemented in https://github.com/meshtastic/firmware/pull/5528, but is still applicable even without that mode, particularly when having to contend with poorly-placed rooftop routers.

For example:

  1. (E) transmits a packet with hop limit 3
  2. (B) & (D) both overhear it. (D) starts rebroadcasting it first with hop limit 2, (B) overhears (D) and waits.
  3. (B) and (C) are both ready to transmit. (C) happens to go first, rebroadcasting with hop limit 1.
  4. (A) hears the packet from (C), and is about to rebroadcast with hop limit 0, when it hears (B) starting to send.
  5. (B) rebroadcasts the packet with hop limit 2.
  6. (A) hears the packet again from (B), this time with hop limit 2.
  7. (A) adjusts the hop limit on the packet in its TX queue from 0 to 1, and then transmits the packet.

example

erayd avatar Dec 09 '24 09:12 erayd