Crate turnclient

Crate turnclient 

Source
Expand description

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

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