Skip to main content

Module relay_seen

Module relay_seen 

Source
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§

RelaySeenCache
Bounded, insertion-ordered record of recently handled message ids.
RelaySeenConfig
Configuration for RelaySeenCache.

Enums§

SeenOutcome
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.