Hi Vicente, On 08/20/2015 12:00 AM, Vicente Gonzalez wrote: > 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 :-) Haha this is great. :D Sometimes also DNS requests (or just any UDP packet over port 53) is not counting for bandwidth or can traverse firewalls.
> > > 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. Yes, that's true, at least for security reasons. > > > 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? Currently a message is sent 3 times without a pause in between. This avoids blocking the splitter (as would be possible when waiting e.g. 1ms between each message), but could lead to network congestion and a higher packet loss. > > > 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). Ah, now I remember the paragraphs about this technique in the paper. Sadly when clustering, the splitter has more load as it sends all data once to each cluster. > Good night! > Vi. Thanks. :) On 08/20/2015 12:15 AM, Vicente Gonzalez wrote: > 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. Exactly, this is what I was thinking of. Now I finally finished coding, with implementing the reporting of currently allocated source ports of incorporated peers behind SYMSP NATs. Today I would like to read through the NTS code again and clean it up, add comments. For this I have another question about logging and verbosity: It seems from the P2PSP code that sometimes 'std.stdout', 'print()' and '_print_' is used, debug messages are shown if '__debug__' is set, and some messages are colorized. Is there some preferred output method, and coloring scheme? Then I will apply this to the NTS code as well. Overnight I will be running final test runs. Are there special networking conditions (delay, jitter, loss rate) you would like to have tested? I will probably configure 30ms delay ±5ms jitter and 1% packet loss (comparable to my home internet), and maybe a harder condition like 10ms delay ±5ms jitter and 10% packet loss to compare. Then tomorrow morning I will add the result tables to the documentation, and send pull requests for the nts and the nts_doc branch, so you can look through it tomorrow before merging. Is this ok for you? Regards, Max
-- Mailing list: https://launchpad.net/~p2psp Post to : [email protected] Unsubscribe : https://launchpad.net/~p2psp More help : https://help.launchpad.net/ListHelp
