Struct Processor

Source

pub struct Processor { /* private fields */ }

Expand description

process udp message and return message + address.

Implementations§

Source §

impl Processor

Source

pub async fn process<'c, 'a: 'c>( &'a mut self, b: &'a [u8], addr: SocketAddr, ) -> Result<Option<Response<'c>>, StunError>

process udp data

receive STUN encoded Bytes, and return any Bytes that can be responded to and the target address. Note: unknown message is not process.

In a typical configuration, a TURN client is connected to a private network [RFC1918] and, through one or more NATs, to the public Internet. On the public Internet is a TURN server. Elsewhere in the Internet are one or more peers with which the TURN client wishes to communicate. These peers may or may not be behind one or more NATs. The client uses the server as a relay to send packets to these peers and to receive packets from these peers.

                                    Peer A
                                    Server-Reflexive    +---------+
                                   Transport Address   |         |
                                     192.0.2.150:32102   |         |
                                       |              /|         |
                      TURN              |            / ^|  Peer A |
   Client's           Server            |           /  ||         |
   Host Transport     Transport         |         //   ||         |
   Address            Address           |       //     |+---------+
198.51.100.2:49721  192.0.2.15:3478     |+-+  //     Peer A
           |            |               ||N| /       Host Transport
           |   +-+      |               ||A|/        Address
           |   | |      |               v|T|     203.0.113.2:49582
           |   | |      |               /+-+
+---------+|   | |      |+---------+   /              +---------+
|         ||   |N|      ||         | //               |         |
| TURN    |v   | |      v| TURN    |/                 |         |
| Client  |----|A|-------| Server  |------------------|  Peer B |
|         |    | |^      |         |^                ^|         |
|         |    |T||      |         ||                ||         |
+---------+    | ||      +---------+|                |+---------+
               | ||                 |                |
               | ||                 |                |
               +-+|                 |                |
                  |                 |                |
                  |                 |                |
         Client's                   |             Peer B
         Server-Reflexive     Relayed             Transport
         Transport Address    Transport Address   Address
         192.0.2.1:7000       192.0.2.15:50000    192.0.2.210:49191

                               Figure 1

Figure 1 shows a typical deployment. In this figure, the TURN client and the TURN server are separated by a NAT, with the client on the private side and the server on the public side of the NAT. This NAT is assumed to be a “bad” NAT; for example, it might have a mapping property of “address-and-port-dependent mapping” (see [RFC4787]).

The client talks to the server from a (IP address, port) combination called the client’s “host transport address”. (The combination of an IP address and port is called a “transport address”.)

The client sends TURN messages from its host transport address to a transport address on the TURN server that is known as the “TURN server transport address”. The client learns the TURN server transport address through some unspecified means (e.g., configuration), and this address is typically used by many clients simultaneously.

Since the client is behind a NAT, the server sees packets from the client as coming from a transport address on the NAT itself. This address is known as the client’s “server-reflexive transport address”; packets sent by the server to the client’s server-reflexive transport address will be forwarded by the NAT to the client’s host transport address.

The client uses TURN commands to create and manipulate an ALLOCATION on the server. An allocation is a data structure on the server. This data structure contains, amongst other things, the relayed transport address for the allocation. The relayed transport address is the transport address on the server that peers can use to have the server relay data to the client. An allocation is uniquely identified by its relayed transport address.

Once an allocation is created, the client can send application data to the server along with an indication of to which peer the data is to be sent, and the server will relay this data to the intended peer. The client sends the application data to the server inside a TURN message; at the server, the data is extracted from the TURN message and sent to the peer in a UDP datagram. In the reverse direction, a peer can send application data in a UDP datagram to the relayed transport address for the allocation; the server will then encapsulate this data inside a TURN message and send it to the client along with an indication of which peer sent the data. Since the TURN message always contains an indication of which peer the client is communicating with, the client can use a single allocation to communicate with multiple peers.

When the peer is behind a NAT, the client must identify the peer using its server-reflexive transport address rather than its host transport address. For example, to send application data to Peer A in the example above, the client must specify 192.0.2.150:32102 (Peer A’s server-reflexive transport address) rather than 203.0.113.2:49582 (Peer A’s host transport address).

Each allocation on the server belongs to a single client and has either one or two relayed transport addresses that are used only by that allocation. Thus, when a packet arrives at a relayed transport address on the server, the server knows for which client the data is intended.

The client may have multiple allocations on a server at the same time.