ETS-backed table mapping normalised allocation keys to plugin chains.
What problem this solves
Relay plugins attach per allocation and must be looked up on every ingress/
egress frame without a GenServer hop. This table stores the resolved
Plugin.Chain for each normalised five-tuple key so Plugin.Dispatch can
read concurrently from the data plane.
Internal: keys normalise protocol to :_ so UDP and TCP variants of the same
allocation match. Use take/1 during teardown to claim a row atomically.
RFCs
- RFC 5766 (TURN relay allocations plugins observe)
Summary
Functions
Deletes the row for tuple5 without returning it.
Returns the plugin chain for tuple5, or nil when none is attached.
Creates the named public plugin chain table.
Normalises a tuple5 key so ingress and egress lookups agree.
Stores chain for the normalised tuple5 key.
Reads and deletes the row in one operation, so two concurrent teardowns of the same allocation cannot both act on the chain.
Functions
Deletes the row for tuple5 without returning it.
Returns the plugin chain for tuple5, or nil when none is attached.
Creates the named public plugin chain table.
Normalises a tuple5 key so ingress and egress lookups agree.
Stores chain for the normalised tuple5 key.
Reads and deletes the row in one operation, so two concurrent teardowns of the same allocation cannot both act on the chain.