Hi again, forget my reasoning about that the problem only happens with SYMRP NATs. You are right. PRCN also will generate problems because the [hello]s from the peers that are behind a SYMRP NAT will be blocked by the PRCN.
Regards, Vi. On Thu, Aug 20, 2015 at 12:00 AM Vicente Gonzalez < [email protected]> wrote: > On Wed, Aug 19, 2015 at 3:27 PM Max Mertens <[email protected]> wrote: > >> 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. :) >> > > Yes, that seems to be. It a nice find :-) > > The other day we also did some experiment transmitting (large) echo ICMP > packets between two mobiles in the same (mobile) network (I believe that it > was Pepephone) and the ISP was not aware of the bandwidth consumption. If > this also happens with UDP datagrams, this means that we could run the > P2PSP for free :-) > > >> >> >> 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. >> > > Yes, I have already seen that in your documentation. Thanks! > > >> 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. >> > > That's true. However, IPv6 has been coming for 20 years ... and I think > that NATs and firewalls will be used in the future. > > >> >> >> >> 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. >> > > OK. > > >> 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). >> > > Which is the time between two consecutive messages? > > >> 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? >> > > I think so. > > >> >> 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. >> > > Let's see if I have understood well your example. You mean that in the > team there is already a peer that is behind a SYMRP NAT? Yes, this can > happen if this is the first and the only SYMRP NATted peer of the team. > Next, a new peer arrives and try to join the team, and this peer is behind > a PRCN. I don't see any problem with this configuration because the new > peer should receive the hello replies from the whole team. I think that the > problem will arise if the new peer is behind a SYMRP NAT device. Or I am > missing something ... > > >> 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). >> > > We are analysing the possibilities of clustering to cope with these > situations. For example, if there are several peers behind a SYMRP NAT, it > could be advantageous to create a local team behind that NAT, only for > those peers (to achieve this configuration, a public peer should send its > code-stream to the local splitter, of course). > > Good night! > Vi. > > >> >> Regards, >> Max >> >> >> [1] https://github.com/jellysheep/p2psp/blob/nts_doc/doc/NAT_traversal.md >> >> -- > -- > 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: [email protected] > http://www.ual.es/~vruiz > tel: +34 950 015711 > fax: +34 950 015486 > -- -- 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: [email protected] http://www.ual.es/~vruiz tel: +34 950 015711 fax: +34 950 015486
-- Mailing list: https://launchpad.net/~p2psp Post to : [email protected] Unsubscribe : https://launchpad.net/~p2psp More help : https://help.launchpad.net/ListHelp
