p2psp team mailing list archive

[Vicente Gonzalez <vicente.gonzalez.ruiz@xxxxxxxxx>]

On Wed, Jun 24, 2015 at 11:44 PM Max Mertens <max.mail@xxxxxxxxxx> wrote:

>  Hi Vicente,
>


> Thanks for providing this link.
> The documentation now splits up NTS into Restricted NAT Traversal and
> Symmetric NAT Traversal set of rules, so I suppose I should create two
> distinct classes as well, and rename the current NTS into RTS. The second
> part of NAT Traversal will then be implemented as STS classes, probably
> subclassing RTS and extending them by port prediction.
>
>
That's only an idea. In general most people will use both set of rules at
the same time (RTS and STS), but I thought that it could help in your work
(STS can be seen as an intermediate milestone).

The script is now functional, you can have a look at it in the repo [1]. It
> outputs a table with "yes" if the two peers can send packets to each other,
> and "no" else. Now I have a automatic and reliable way to test NAT
> Traversal between peers, and can apply it on different implementations
> (though the script takes about 5 minutes to run, to ensure that the stream
> can be buffered completely for each configuration).
>
> The results differ a bit from the ones I got so far, as now in the test I
> make a distinction between monitor and peer, and which type of NAT each of
> them is behind. The resulting tables are included at the bottom.
> I will send a pull request for the nts_doc branch when the documentation
> for the Virtual Machine setup and for the test itself is ready.
>
> Regards,
> Max
>
> [1]
> https://github.com/jellysheep/p2psp/blob/nts_doc/tools/test_NAT_traversal.sh
>
> Monitor_LRS, Peer_FNS, Splitter_LRS (master branch, commit fafca93):
>
> Mon\Peer| fcn    | rcn    | prcn    | sym
> ==========================================
> fcn     | yes    | yes    | yes     | yes
> rcn     | yes    | yes    | yes     | yes
> prcn    | no     | no     | no      | no
> sym     | no     | no     | no      | no
>
> Monitor_NTS, Peer_NTS, Splitter_NTS (nts branch, commit 1b844e4):
>
> Mon\Peer| fcn    | rcn    | prcn    | sym
> ==========================================
> fcn     | yes    | yes    | yes     | yes
> rcn     | yes    | yes    | yes     | yes
> prcn    | yes    | yes    | yes     | no
> sym     | no     | no     | no      | no
>
> OK, a question. ¿Why is more dificult to deal with a monitor peer than
with a standard peer?

Regards,
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