Skip to content

Next hop reliability - #3359

Draft
OverkillFPV wants to merge 2 commits into
meshcore-dev:devfrom
OverkillFPV:next-hop-reliability
Draft

Next hop reliability#3359
OverkillFPV wants to merge 2 commits into
meshcore-dev:devfrom
OverkillFPV:next-hop-reliability

Conversation

@OverkillFPV

Copy link
Copy Markdown
Contributor

This is an attempt at direct path reliability using retries if a repeat is not heard, I reckon the extra airtime implication of retries either for failed packets, or not heard repeats that were actually repeated is overall not as big of an impact of a complete resend. only a draft as i am testing the first revision of it.

When a repeater forwards a direct (path-routed) packet and there is a further hop
in its remaining path, it now tracks the packet's hash and waits to overhear the
next hop repeating it as implicit confirmation of receipt. If no repeat is heard
within a timeout, the packet is resent, up to 3 retries, before being dropped.

- Mesh.h: add PendingNextHopConfirm table + getNextHopReliabilityEnabled(),
  getNextHopMaxRetries(), getNextHopConfirmTimeout() virtual hooks for tuning.
- Mesh.cpp: register a pending confirm after forwarding a direct packet with
  a remaining path, check overheard direct packets against the pending table,
  and process retries/timeouts each loop().
Companions, repeaters, and room servers that originate a direct packet
(via Mesh::sendDirect()) now also register it for next-hop reliability
tracking when there's at least one hop in the path, so the sender itself
listens for the first hop to repeat it and retries just like an in-transit
repeater would.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant