Hi Vicente, On 08/17/2015 09:57 AM, Vicente Gonzalez wrote: > This is the result for the test of the Java Applet you have indicated > before [2], for the University of AlmerÃa: > > ******************************************************* > ... > ******************************************************* > > I think that if your developments can manage this NAT, you can hope to > handle any other kind of NAT :-) > > As you mentioned before, maybe you can use also the NAT of your mobile > device (I'll try to check also mine). Thanks for that information! The network of my university shows similar results, but with a UDP timeout of 16 instead of 0 seconds. So in the tests this was good to use for splitter and monitor. 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. As the connection was a bit slow, I had to increase the timeouts. With the splitter and 2 monitor peers on the university server, one peer via DSL and one peer via mobile internet, the NAT traversal between the peers worked. When adding another peer in a virtual machine behind a SYMRP NAT (unpredictable source port) to the team, the other peers could not connect to it, as to be expected. The free VPN services that I tried (and that were usable for tunneling the hole networking) had symmetric NATs with random source ports, so a peer could only connect to splitter, monitor peers and peers behind a FCN or RCN NAT. Do you suggest other testing combinations or methods?
On 08/17/2015 10:48 AM, Vicente Gonzalez wrote: > > [2] https://asciinema.org/a/1wxkq1mf4oseiex1hzfn0gkst > > > Hello Max, > > good work! Only for this example [2], could you send to me a timeline > with the messages between peers, splitter, monitor peers, etc. in > order to understand it better (and remind to me a lot of forgotten > things :-)? Thanks! Yes, this is the next thing I will do, adding sequence diagrams with explanations to the documentation, about the NAT traversal and the retry process. I will send you a link as soon as it is uploaded. > Well, this project has been a difficult one (it has a lot of research > work and possible results). Therefore, the documentation is as > important as (or even more than) the code. We (I and the rest of > mentors of P2PSP) also think that your work could be published in a > conference (such as the International Conference on Computer > Communication and Networks <http://icccn.org/icccn15/>) or even a > journal (an example could be: Computer Networks > <http://www.sciencedirect.com/science/journal/13891286>), and we would > delight if you collaborate with us in this task. What do you think (of > course, this will not affect to our work/evaluation/results for the GSoC)? It would be great if it would be published in some way, as other P2P software could also benefit from the NAT traversal methods; I would like to collaborate with you in this. Last week I also thought about maybe putting the implemented methods into a portable NAT traversal C library, to embed in P2P applications. The updated task list can be found here [1]; the only coding task left for this week is the determination of the currently allocated source port for incorporated peer behind a SYMSP NAT, which is needed if a new peer arrives a long time after the last peer has arrived (so there could be many source port skips). In the last days I added a script to setup a network with NATs in Linux namespaces, which works much smoother than with VMs; also the test script now supports parallel test runs. During testing, I created another script that runs a team and filters/colorizes the output (as you saw in the terminal recording); I would add that to the tools/ subdirectory, if you could need this. Thanks, Max [1] https://github.com/jellysheep/p2psp/wiki/GSoC-2015:-NAT-traversal-using-UDP-hole-punching---Timeline
-- Mailing list: https://launchpad.net/~p2psp Post to : [email protected] Unsubscribe : https://launchpad.net/~p2psp More help : https://help.launchpad.net/ListHelp
