Child of #194.
Context
AntHocNet discovers neighbours by periodic hello broadcast, and presumes a neighbour gone after allowedHelloLoss missed hellos (ADR-0008 detector A, core/include/anthocnet/core/config.h). That is the right design on a shared radio where the neighbour set is unknown and changes continuously.
On an inter-satellite link it is not. An ISL is point-to-point: exactly one peer, known from the constellation geometry, and its presence/absence is an interface up/down event the simulator already knows. Broadcasting a hello every second onto such a link — from ~1584 satellites × ~4 ISLs — is control traffic that discovers nothing.
Scope
Give the adapter a way to learn neighbours from link state instead of (or alongside) hello, without changing what core/ believes:
- feed neighbour presence from interface up/down and, where the substrate exposes it, ISL visibility events, into the same
loseNeighbor / neighbour-learn path detector A uses;
- make hello suppressible per interface when the neighbour set is authoritative from link state — an adapter-side decision, since
core/ must not know what a satellite is (golden rule 1);
- keep hello on any interface where the medium is shared (a hybrid LEO + ground-MANET scenario has both kinds on the same node — do not assume all interfaces are the same kind).
Explicitly out of scope: changing the core neighbour model. Detector A stays the mandatory path per ADR-0008. This is about who supplies the events, not about what the core does with them.
Open question for the implementer
Does suppressing hello break anything that quietly depends on it? Hello also carries pheromone diffusion adverts (enableDiffusion, ADR-0007) — so "suppress hello" may mean "suppress the liveness role, keep the diffusion role", or it may mean diffusion needs its own timer on those interfaces. Settle this before writing code, and record the answer here.
Acceptance
On a p2p-ISL topology, neighbour loss is detected from link state with hello disabled on those interfaces, multi-hop delivery is unaffected, and control-packet count drops measurably. Covered by an NS-3 test case; A/B the control-traffic reduction via the benchmark-results skill rather than by eye.
Related
#194 (parent), ADR-0008 (two detectors), ADR-0007 (diffusion rides on hello — the complication above), #202 (whether this regime is worth optimising at all).
Child of #194.
Context
AntHocNet discovers neighbours by periodic hello broadcast, and presumes a neighbour gone after
allowedHelloLossmissed hellos (ADR-0008 detector A,core/include/anthocnet/core/config.h). That is the right design on a shared radio where the neighbour set is unknown and changes continuously.On an inter-satellite link it is not. An ISL is point-to-point: exactly one peer, known from the constellation geometry, and its presence/absence is an interface up/down event the simulator already knows. Broadcasting a hello every second onto such a link — from ~1584 satellites × ~4 ISLs — is control traffic that discovers nothing.
Scope
Give the adapter a way to learn neighbours from link state instead of (or alongside) hello, without changing what
core/believes:loseNeighbor/ neighbour-learn path detector A uses;core/must not know what a satellite is (golden rule 1);Explicitly out of scope: changing the core neighbour model. Detector A stays the mandatory path per ADR-0008. This is about who supplies the events, not about what the core does with them.
Open question for the implementer
Does suppressing hello break anything that quietly depends on it? Hello also carries pheromone diffusion adverts (
enableDiffusion, ADR-0007) — so "suppress hello" may mean "suppress the liveness role, keep the diffusion role", or it may mean diffusion needs its own timer on those interfaces. Settle this before writing code, and record the answer here.Acceptance
On a p2p-ISL topology, neighbour loss is detected from link state with hello disabled on those interfaces, multi-hop delivery is unaffected, and control-packet count drops measurably. Covered by an NS-3 test case; A/B the control-traffic reduction via the
benchmark-resultsskill rather than by eye.Related
#194 (parent), ADR-0008 (two detectors), ADR-0007 (diffusion rides on hello — the complication above), #202 (whether this regime is worth optimising at all).