p2psp team mailing list archive

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

On Sun, Jun 28, 2015 at 3:46 PM Max Mertens <max.mail@xxxxxxxxxx> wrote:

>  Hi Vicente,
>


> 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?
>

No. But we can assume that the monitor peer will run always in the same
host that the splitter. If you configure the team in such way the problem
persists? In any case, I would like to know what is happening ...


> Should all peers send keepalive UDP packets every few seconds to the
> splitter, to maintain/create the NAT entry?
>
>
Yes, it could help. Good idea.  Please, try this.


>
> 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?
>

This is one of the reasons why the monitor peer should be hosted in the
same machine than the splitter, or at least, in the same network.


> 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)?
>
>
I don't understand well your question ... but, if running the monitor peer
and the splitter in the same host answers it, all happy. If not, obviously,
all polling processes need to define and deadline. In this case, consider
the time you think that can be fine.


> Thanks,
> Max
>
>
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