Overview
Universal UDP Mux extends the standard UDP multiplexing functionality by adding support for STUN server reflexive address discovery and TURN relay functionality. It combines the capabilities ofUDPMux with built-in handling of STUN/TURN server communication, making it ideal for NAT traversal scenarios.
The Universal Mux intercepts and processes STUN responses from STUN/TURN servers before passing packets to the underlying UDP mux, automatically managing XOR-mapped addresses and relay allocations.
UniversalUDPMux Interface
TheUniversalUDPMux interface extends UDPMux with additional methods for STUN and TURN functionality.
Methods
Discovers the server reflexive address by sending a STUN binding request to the specified STUN server. Results are cached to avoid repeated requests.Parameters:
stunAddr- The address of the STUN serverdeadline- Maximum time to wait for a response
Creates a relayed connection through a TURN server and returns the relay address.Parameters:
turnAddr- The address of the TURN serverdeadline- Maximum time to wait for relay allocation
errNotImplemented.Returns a connection that is unique to both the ufrag and the server URL. This allows multiple STUN/TURN servers to be used simultaneously without connection conflicts.Parameters:
ufrag- The username fragment from the ICE credentialsurl- The STUN/TURN server URLaddr- The network address to bind to
net.PacketConn for this ufrag/URL combinationThe Universal Mux also implements all
UDPMux interface methods:GetConn(ufrag string, addr net.Addr) (net.PacketConn, error)RemoveConnByUfrag(ufrag string)GetListenAddresses() []net.AddrClose() error
UniversalUDPMuxDefault
UniversalUDPMuxDefault is the default implementation that wraps a UDPMuxDefault instance and adds STUN/TURN handling.
Creating a UniversalUDPMuxDefault
UniversalUDPMuxParams
Logger instance for the mux. If nil, a default logger will be created.
The UDP connection to multiplex. This connection will be wrapped to intercept STUN responses.
Time-to-live for cached XOR-mapped addresses. After this duration, a new STUN request will be sent.Default: 25 seconds
Network transport interface. Used for network operations.
Example: Basic Universal Mux
How It Works
Packet Flow
-
Outgoing STUN Requests: When
GetXORMappedAddris called, the mux sends a STUN binding request to the specified server and tracks the transaction. - Incoming STUN Responses: The wrapped UDP connection intercepts incoming packets. If a packet is a STUN response with an XOR-mapped address attribute from a known server, it’s processed separately.
- Address Caching: XOR-mapped addresses are cached per STUN server address with a TTL. Subsequent requests within the TTL return the cached address.
- Regular Packets: Non-STUN packets or STUN packets not matching tracked transactions are passed to the underlying UDPMux for normal processing.
Connection Uniqueness
TheGetConnForURL method ensures connection uniqueness by concatenating the ufrag with the server URL:
Address Discovery
Server Reflexive Addresses
Server reflexive addresses are your public IP and port as seen by a STUN server, essential for NAT traversal:Caching Behavior
Cache Management
- Each STUN server address has its own cache entry
- Cached addresses expire after
XORMappedAddrCacheTTL - Expired entries trigger new STUN requests automatically
- If a request is already in flight, subsequent calls wait for the same response
- Cache is cleared when the mux is closed
Multiple STUN Servers
Querying multiple STUN servers can help verify your public address and provide redundancy:Combining Universal Mux Capabilities
The Universal Mux combines three key capabilities:1. UDP Multiplexing
All standard UDP mux features are available:2. Server Reflexive Discovery
Automatic discovery and caching of public addresses:3. URL-Scoped Connections
Unique connections per STUN/TURN server:When to Use Universal Mux
Use Universal UDP Mux when:- NAT Traversal Required: Your application needs to discover its public IP address for NAT traversal
- Multiple STUN Servers: You want to use multiple STUN servers with a single UDP port
- Server Reflexive Candidates: Your ICE agent needs to gather server reflexive candidates
- Automatic Address Management: You want automatic caching and management of discovered addresses
- TURN Integration: You plan to add TURN support in the future (relay functionality)
- You only need host candidates (no NAT traversal)
- You’re implementing your own STUN client logic
- You want minimal overhead and don’t need STUN integration
Best Practices
-
Cache TTL Configuration: Set an appropriate TTL based on your network stability:
-
Timeout Handling: Use reasonable timeouts for STUN requests:
-
Error Recovery: Handle STUN failures gracefully:
-
Resource Cleanup: Always close the mux when done:
-
STUN Server Selection: Use reliable, geographically diverse STUN servers:
Integration with ICE Agent
Limitations and Future Work
Current Limitations
-
TURN Support: The
GetRelayedAddrmethod is not yet implemented. TURN relay functionality is planned for a future release. - IPv6 Zones: IPv6 zone information may not be fully preserved in some address conversions.
- Concurrent Requests: Multiple concurrent requests to the same STUN server are serialized to avoid duplicate requests.
Error Handling
Common errors you may encounter:Performance Considerations
- Memory: Each STUN server address adds a small cache entry (~100 bytes)
- Network: STUN requests are small (~20-60 bytes) and responses are similar
- Latency: First address discovery adds 1 RTT to the STUN server
- Cache Hits: Subsequent requests within TTL have no additional latency
Related
- UDP Mux - Standard UDP connection multiplexing
- TCP Mux - TCP connection multiplexing
- Agent Options - Using muxes with ICE agents
- NAT Traversal - Understanding STUN and NAT traversal