p2psp team mailing list archive

[Max Mertens <max.mail@xxxxxxxxxx>]

Hi Vicente,

On 25.06.2015 22:13, Max Mertens wrote:
> On 25.06.2015 12:46, Vicente Gonzalez wrote:
>>
>>         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.
I did a lot of further testing over the weekend. The "no" in bold above
sometimes switches to "yes" when running exactly the same test again, so
at first I thought it was a problem with the iptables/NAT configuration
(allowing some connections and some not), but even un-/reloading the
iptables and netfilter kernel modules to reset NAT entries did not
change the results.
Apparently the issue is the UDP "connection" between splitter and
monitor (i.e. first peer): If the monitor is located behind a symmetric
NAT, it is not always able to receive UDP packets from the splitter (in
216 out of 300 test runs it works and the monitor receives all packets,
in all other test runs it does not work and the monitor receives no
packet at all from the splitter).
In the failure case, the monitor just outputs:

    [...]
    Monitor LRS
    ('0.0.0.0', 21792): buffering = 000.00%
    Waiting for a chunk at ('0.0.0.0', 21792) ...
    Waiting for a chunk at ('0.0.0.0', 21792) ...
    -2
    Waiting for a chunk at ('0.0.0.0', 21792) ...
    -2
    [...]

This is the case with the new NTS classes and with the master branch,
and even if I manually edit peer.py and create a Peer instead of a
Monitor instance, so apparently not related to monitor-specific code.
On the other hand, a second peer (i.e. the first normal peer) is mostly
able to receive UDP packets from the splitter (93 out of 100 test runs).
I do not know why this happens, because the peer sends 3 UDP "hello"
packets to the splitter after closing the TCP connection.
Do you have an idea where this connection issue comes from? Should all
peers send keepalive UDP packets every few seconds to the splitter, to
maintain/create the NAT entry?


When I wanted to continue implementing the NTS algorithms, and a few
questions arised: The splitter uses the monitor peer to determine the
NAT type of other peers, but how does it determine the NAT type of the
monitor peer? Is the monitor peer expected to always be behind a
full-cone NAT, or to be located on the same machine as the splitter?
When should the NAT type determination happen, after the monitor reports
to the splitter that it got a "hello" from the new peer (probably with a
timeout, as the "hello" packet might not reach the monitor if it is
behind a NAT)?

Thanks,
Max