Hi Vicente, thanks for your reply! Now the timeout to remove peers that take too long for being incorporated into the team is implemented.
On 08/03/2015 04:44 PM, Vicente Gonzalez wrote: > > Ok. I added a simple port prediction algorithm to the NTS code, > you can have a look at the changes here [2]. Currently it > determines if the difference between the source ports towards the > splitter and the monitor is <10, and then takes this difference as > the step for the port prediction. Other possibilities would be > assuming a constant step of 1, or to let the peers send packets to > all port,port+1,...,port+port_difference possibilities. Another > approach would be to start another listening socket at the monitor > and gather another source port difference, to detect the port > allocation type more accurately. > Which approach would you suggest? > > > For me, none of the approaches has a clear advantage. Try the simplest > one. > > > How do you think about sending ~10 packets per second to each peer > in the connection attempt phase, is this too much? > > > No. The packets are small. Ok, then I will make the peer send to different possible port numbers. > Some NATs might be destination port-insensitive when allocating > source ports, which could lead to a wrong NAT type detection (port > preservation instead of sequential allocation) if splitter and > monitor are on the same host. The only option here would be using > either public STUN servers or having trusted peers with > predictable NATs, to determine the source port difference for > different destination addresses. > > > Well, there may be more than one monitor peer. Does this solve your > question? This would be great for NAT type discovery in the port-insensitive case! How can you distinguish between additional monitors (not the first in the peer list) and standard peers? > A NAT type combination (marked as "(yes)" in the tables in > previous emails) that does not work yet is a SYMSP router at an > existing peer and a port-restrictive NAT (any type except FCN and > RCN) at the arriving peer: To handle this situation, the existing > peer has to send UDP packets to a new port at the monitor or at > the splitter, to get the currently allocated source port of the > existing peer and predict its next port. What do you think about this? > > > The use of ports should be minimized, but I suppose that in this case > this use is fully justified. Please, try it. Ok. However I cannot test this unless I find some NAT which implements the sequentially allocating type. Currently I noticed that in some rare cases the TCP socket of the peer receives 0 bytes from the splitter, which indicates a closed socket. Let's see if this persists and if a reason can be found. Thanks, Max
-- Mailing list: https://launchpad.net/~p2psp Post to : [email protected] Unsubscribe : https://launchpad.net/~p2psp More help : https://help.launchpad.net/ListHelp
