Crate turnclient

Simple async TURN client.

Usage:

1. Create TurnClientBuilder
2. build_and_send_request
3. split the resulting thing to Stream and Sink
4. Wait for AllocationGranted event from Stream
5. Create permission or channel with AddPermission message
6. Send datagrams to the peer with a SendTo message to TurnClient’s Sink interface, receive datagrams from the peer by handling RecvFrom message from TurnClient’s Stream interface.

You may want to build a stream -> map -> sink chain using Stream::forward or Sink::send_all.

You need to handle errors from Stream::poll, otherwise somebody can DoS your client by sending tricky packets.

Not implemented / TODO / cons:

• Removing permissions. They keep on getting refreshed until you close the entire allocation.
• Quadratical complexity, linear number of UDP datagrams in case of N actibe permissions.
• TCP or TLS transport.
• Using short-term credentials instead of long-term.
• “Don’t fragment” specifier on sent datagrams
• Even/odd port allocation
• Message-integrity is not checked for server replies.
• Allocation-heavy, uses Vec<u8> for byte buffers.

Examples:

• echo.rs - Connect to specified TURN server, authorize specified peer and act as an echo server for it.

Structs

• ExportedParameters
  Exported parameters for resuming allocation
• TurnClient
  The thing to be split to Stream<Item=MessageFromTurnServer> and Sink<Item=MessageToTurnServer>. Look at crate-level doc for more details.
• TurnClientBuilder
  Options for connecting to TURN server

Enums

• ChannelUsage
  Whether to just create permission of also allocate a channel for it. I don’t see much reasons not to allocate a channel.
• MessageFromTurnServer
  Callbacks from TurnServer
• MessageToTurnServer
  Requests and indications to be sent to TURN server

Type Definitions

• Error
  anyhow-based error handling. File an issue if you want proper thiserror-based errors.