p2psp team mailing list archive

[Max Mertens <max.mail@xxxxxxxxxx>]

Hi Vicente,

On 25.06.2015 12:46, Vicente Gonzalez wrote:
>  
>
>     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).
Ok, I see, thanks.

>         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?
Just for clarification: The entry "no" in bold and capital letters above
means that first a peer behind a symmetric NAT connects to the splitter
(being the first peer and automatically becoming a monitor), and then a
second peer behind a Full Cone NAT connects to the splitter. The "no"
means that the monitor and the splitter cannot receive packets from each
other (neither "hello" nor chunks).
I don't exactly know why the combination "monitor behind sym. NAT and
second peer behind FCN" does not work while "monitor behind FCN and
second peer behind sym. NAT" works well (same results in several test
runs). It must be because of the "hello" packets sent by one
peer/monitor but not by the other, which prevents a hole in one of the
NATs. I will elaborate on this further.

Regards,
Max