Resolved plugin chain for one TURN allocation.
What problem this solves
After Plugin.Lifecycle evaluates which plugins attach to an allocation,
the result must be a fixed ordered list for ingress and egress, split into
active (inline) and passive (GenServer) entries. This struct is stored in
Plugin.Table and consumed by Plugin.Dispatch.
Internal: built at allocation start; claimed via Plugin.Table.take/1 at
teardown.
RFCs
- RFC 5766 (TURN relay allocations)
Summary
Types
Active plugin entry: {module, opaque_state, opts} run inline on the hot path.
Passive plugin entry: {module, pid, atomics_ref, generation} notified after active work.
Ordered plugin entries for one allocation's ingress and egress paths.
Types
Active plugin entry: {module, opaque_state, opts} run inline on the hot path.
@type passive_entry() :: {module(), pid(), :atomics.atomics_ref(), non_neg_integer()}
Passive plugin entry: {module, pid, atomics_ref, generation} notified after active work.
@type t() :: %Xirsys.XTurn.Plugin.Chain{ egress_active: [active_entry()], egress_passive: [passive_entry()], ingress_active: [active_entry()], ingress_passive: [passive_entry()] }
Ordered plugin entries for one allocation's ingress and egress paths.
Fields
:egress_active- active plugins run before relaying toward the peer:egress_passive- passive plugins notified after active egress succeeds:ingress_active- active plugins run before delivering toward the client:ingress_passive- passive plugins notified after active ingress succeeds