p2psp team mailing list archive

[Max Mertens <max.mail@xxxxxxxxxx>]

Hi Vicente,

On 08/19/2015 12:09 PM, Vicente Gonzalez wrote:
>  
>
>
>     I tested the mobile internet, and apparently it implements a cone
>     NAT (probably a PRCN) so it has the same source port for every
>     destination endpoint.
>
>
> This result has been surprising for me, but your are right. It seems
> that most mobile ISP uses a PRCN. I have run the test on my wife's
> network (Vodafone) and this is the result:
>
> **********************
> ...
> **********************
Thanks for the results. So mobile networks seem to be well suited for
P2P software, though many providers prohibit those applications. :)

> No, I can't imagine any other technique that could help with dealing
> with random-SYM NATs. Sorry. Maybe, some kind of
> try-and-if-it-fails-try-again method :-/
Ok, this is implemented by the incorporation retry after a timeout.
Hopefully those NATs won't get implemented too often.
And I am also anxious to see P2P possibilities when IPv6 becomes more
mainstream, because address translation would not be needed anymore.


On 08/19/2015 03:01 PM, Vicente Gonzalez wrote:
> But there is still  something that is not totally clear for me. You
> comment in [1] that when a burst of three UDP datagrams is sent from
> one entity to another, you represent this by two consecutive arrows.
> That's OK, however, why some times the arrows have the same direction
> and other times the opposite direction (I don't understand well you
> explanation).
The second arrow in the opposite direction symbolizes the acknowledge
message back to the sender.
Because UDP is unreliable, a message from a peer is sent repeatedly
(every second) until an acknowledge message (exactly the same data) is
sent back (so two messages in opposing directions).
To reduce load on the splitter, it does not have an extra thread
dedicated to send messages continuously, and instead just sends a
message several times, without waiting for acknowledge (so two or more
messages in the same direction).
Thanks for this hint. Maybe it is better to show just one arrow in the
diagrams, and explain the details about message sending from peers and
from the splitter in the text?

Just a random thought: Currently each peer sends chunks to its peers one
after another, in a round-robin style. This means that if there is one
peer with random source allocation (SYMRP) in the team, another peer
with port-restricted NAT cannot join the team at all (or vice versa)
because it fails to connect to one peer.
A complicated solution (maybe for another GSoC or so) could be to have
SYMRP peers only connect to peers behind FCN or RCN NATs, and ensure by
a special algorithm that network load is distributed equally between the
peers. Though I do not know if this is possible and if it has
implications on security (DoS attacks could be easier).

Regards,
Max


[1] https://github.com/jellysheep/p2psp/blob/nts_doc/doc/NAT_traversal.md