p2psp team mailing list archive

[Max Mertens <max.mail@xxxxxxxxxx>]

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