← Back to team overview

p2psp team mailing list archive

Re: NAT Traversal Set of rules implementation

 

On Thu, Jun 11, 2015 at 6:02 PM Max Mertens <max.mail@xxxxxxxxxx> wrote:

>  Hi Vicente,
>

Hello!


>
>
> On 08.06.2015 10:49, Vicente Gonzalez wrote:
>
> A remark. We can suppose that the splitter (I think, your server) will run
> in a public host, with all the port open.
>
> In this test, the server can not be compared to the splitter, the name
> 'server' is misleading here. It is assumed that each other peer's public
> endpoint is already known as I typed in the addresses as a parameter, so
> the splitter part is not needed for this test.
>

OK.


> The only difference between the server and client is that the server sends
> UDP packets every 5 seconds, and the client every 1 second.
> It is a bit surprising that e.g. RCN->PRCN connection does not work but
> PRCN->RCN does, and sometimes one peer can see the other peer connecting
> but cannot reply. I think that this asymmetric behaviour is due to the
> chownat implementation (as server and client are not exactly equivalent)
> and should not occur in a NTS implementation.
>

Well, according to:

http://en.wikipedia.org/wiki/Network_address_translation

A PRCN is more restrictive than a PRC, so, for my makes sense that
RCN->PRCN connection does not work but PRCN->RCN does. However, it is
possible that you are right :-)


>
>
>    Is there already some kind of case differentiation implemented, where
>> the peers determine the type of NAT they are behind (using the splitter),
>> and automatically choose the Set of rules they need?
>>
>
>  No, but we can think that all peers will implement the overhead of the
> NAT Traversal Set of rules (I hope, with a negligible protocol overhead ...
> I mind, with a small number of small messages).
>
> Ok, so all peers will use peer_nts.py?
>

At this moment, the implementation of the P2PSP allows to select (using
inheritance) the number of set of rules that a peer will implement (the
same should happen for the splitter). This is the only that you should keep
in mind while you will write your implementation. However, it is very
likely that all peer, in a real scenario, will implement the NTS.


> How is TCP streaming handled by P2PSP, is this also planned to be handled
> by NTS?
>

All video data is transmitted over UDP, so, you can ignore the TCP for now.


>
>
>
>>
>> When using UDP to transmit data, where should lost packages/datagrams be
>> recovered? When using software like udptunnel, the P2PSP classes could
>> expect a reliable stream; but as stated in the Lost chunks Recovery Set
>> (LRS) of rules, P2PSP uses UDP for communication, so if LRS is used, no
>> extra package recovery is necessary?
>>
>
> No, LRS resends only video chunks that were lost from the splitter to the
> peer. LRS will not provide any kind of recovery for other UDP messages.
>
> Ok. So the NTS implementation will have to recover lost UDP packages, as
> not only video chunks are sent and all UDP messages are needed to maintain
> the connection?
>

No, the chunk recovery mechanism should be the responsability of a
different set of rules.


>
> I wrote a UDP communication test program to test NAT traversal outside the
> P2PSP code (to simplify testing and debugging), and will integrate it into
> a NTS implementation in P2PSP as soon as it works correctly. You can have a
> look at it here:
> https://github.com/jellysheep/p2psp/blob/nts_tests/nts_tests/nts_tests.py
> Currently it simulates two peers connecting using a splitter and then
> communicating directly. I will now test if this also works with different
> NAT types between them, and then extend the code to correctly implement the
> NTS algorithm as specified in the paper.
>

Perfect.


>
> And thanks for sending the paper, it is great to read it in "printed" form.
>

:-)


>
> @Cristóbal Medina López: Thanks for the guide, I forked the repo and added
> the NTS branch, and will work in this branch.
>
> Regards,
> Max
>

Best,
Vi.

-- 
-- 
Vicente González Ruiz
Depto de Informática
Escuela Técnica Superior de Ingeniería
Universidad de Almería

Carretera Sacramento S/N
04120, La Cañada de San Urbano
Almería, España

e-mail: vruiz@xxxxxx
http://www.ual.es/~vruiz
tel: +34 950 015711
fax: +34 950 015486

Follow ups

References