Add udp.align option

[Anisotrop]

Do you have any idea on where should the resource address option be checked and added on the connector side ?

[dpwspoon]

I don't think we need to have any behavior for the connector, or at least I'm not sure what the behavior would be for outbound connections, so we can document that it has no effect on that. Do you agree, or do you think we should also align outbound bytes? Perhaps a better name for the property would be inbound-align or something to that effect.

We do need it as a <connect-option> though, specifically for reverse connectivity, where it gets put on the connect-options, but is really used on udp ACCEPTOR over a reverse connection

[Anisotrop]

From here: https://tools.ietf.org/html/rfc5766#section-2.5 it would look like a peer will send turn channel data messages to a client using the channel number. Since the proxy is in the middle it would mean that the data comes on the outbound connection.

In the reverse direction, when Peer A sends a UDP datagram to the relayed transport address, this UDP datagram arrives at the server on the relayed transport address assigned to the allocation. Since the UDP datagram was received from Peer A, which has a channel number assigned to it, the server encapsulates the data into a ChannelData message when sending the data to the client.

[Anisotrop]

After giving more thought, the messages coming from the TURN Server without padding could be considered to always come on udp. I don't think we have anything between the server and the proxy that might alter the data or that we use an underlying protocol.

This would mean that the require.padding option would only apply to the TurnFrameDecoder initiated by the acceptor while the connector side should have the following logic:

• buffer has exact length as declared we are most certainly on UDP so decode
• buffer has more than declared, should assume padding and decode accordingly

We might even try to detect the underlying transport since the assumption is the connection is direct. The lmitation is that we cannot add on the connector side an intermediary gateway that connects to the turn server on udp but has the accept on tcp.

I think the problem comes because of the difference in the transports, where multiple tcp segments inside a buffer can trigger a read, meaning we can only see a stream of bytes, while only a single udp datagram will trigger a read. There is a protocol over IP that has the reliability of tcp but is message oriented: https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol

Waiting for your thoughts on this, I will be focusing on implementing the UdpAlignFilter.

[dpwspoon]

I think you are correct, that we need UDP align for inbound packets on the outbound/connector. And then the logic can be added probably as a filter put on by the connector

[dpwspoon]

This looks good to me, is it ready to merge?