Crate turnclient[−][src]
Expand description
Simple async TURN client.
Usage:
- Create
TurnClientBuilder
build_and_send_request
split
the resulting thing toStream
andSink
- Wait for
AllocationGranted
event from Stream - Create permission or channel with
AddPermission
message - Send datagrams to the peer with a
SendTo
message toTurnClient
’sSink
interface, receive datagrams from the peer by handlingRecvFrom
message fromTurnClient
’sStream
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
The thing to be split
to Stream<Item=MessageFromTurnServer>
and Sink<Item=MessageToTurnServer>
.
Look at crate-level doc for more details.
Options for connecting to TURN server
Enums
Whether to just create permission of also allocate a channel for it. I don’t see much reasons not to allocate a channel.
Callbacks from TurnServer
Requests and indications to be sent to TURN server
Type Definitions
anyhow
-based error handling.
File an issue if you want proper thiserror
-based errors.