Expand description
Suppression cache for messages that have already been forwarded.
A forwarding node sees the whole neighborhood’s traffic, not just its own: every frame that crosses it arrives once per link that carries it. Forwarding each arrival would turn one message into as many copies as the network has edges, and those copies would arrive back at nodes that already forwarded them, and so on. This cache is what stops that — the record that says “this id has been handled, ignore further arrivals.”
It is deliberately separate from Deduplicator,
which answers a different question. The deduplicator tracks messages
addressed to us, and its entries are load-bearing for delivery semantics:
entries are removed again (unmark_seen) when a message could not be
delivered, so the sender’s retry is reprocessed rather than silently
re-acknowledged. Forwarding traffic has no such lifecycle — an id is either
handled or not — and mixing the two populations would let relay volume evict
the delivery-critical entries.
§Sizing
Capacity has to cover the whole network’s traffic for as long as copies of
a message can still be in flight, not just our own. Two windows matter: a
flood’s lifetime (bounded by hop limit times per-hop latency, so seconds),
and the sender’s early retransmissions as forwarders pass them on (tens of
seconds). The forwarder adjacent to the sender carries the sender’s own
re-send again, releasing and re-recording its entry, because the recipient
re-acknowledges only a re-send that reaches it; every device after that
still suppresses it. The defaults cover
both with margin, and are chosen so that at the maximum rate a node will
accept forwarding traffic, the cache still holds far more than
DEFAULT_RELAY_SEEN_RETENTION_SECS of it — meaning entries expire by age
rather than being pushed out by volume. That ordering is what makes the
suppression guarantee hold: an id evicted early would be forwarded a second
time, and by every other node too, which is how a flood becomes a storm.
Eviction is O(1): entries leave in insertion order, which for a fixed retention window is also expiry order.
Structs§
- Relay
Seen Cache - Bounded, insertion-ordered record of recently handled message ids.
- Relay
Seen Config - Configuration for
RelaySeenCache.
Enums§
- Seen
Outcome - What a cache lookup found for an id.
Constants§
- DEFAULT_
RELAY_ SEEN_ CAPACITY - Maximum ids tracked before the oldest is dropped.
- DEFAULT_
RELAY_ SEEN_ RETENTION_ SECS - How long an id stays suppressed.