p2psp team mailing list archive

[Vicente Gonzalez <vicente.gonzalez.ruiz@xxxxxxxxx>]

Hello!

On Wed, Aug 5, 2015 at 6:29 PM Max Mertens <max.mail@xxxxxxxxxx> wrote:

> Hi Vicente,
>
> thanks for your reply! Now the timeout to remove peers that take too long
> for being incorporated into the team is implemented.
>
>
Yes, this is something that we need in order to deal with those peers that
are unable to connect to a team :-/


>
> 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.
>

Good.


>
>
> 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?
>
>
Monitor peers were "created" with the aim of sending some kind of feedback
to the team administrator, in order to know if the things go right during a
broadcasting session (for example, the team administrator can visualize the
video that the monitor peers are rendering). We can imagine this
configuration quite simple: the administrator launches the splitter and
next, he also runs one or more monitor peers in some hosts (not necessary
the same host than the splitter's one). Therefore, just including a new
parameter to the splitter (indicating the number X of monitor peers) and
supposing that the first X peers to enter to the team will be the monitors,
it could be enough.


> 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.
>

Yes, you're right. I also think that it will be very difficult to find a
real NAT with this behaviour :-/


>
> 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.
>

Please, remind me for what are you using this socket ...

Regards,
Vi.

-- 
-- 
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: vruiz@xxxxxx
http://www.ual.es/~vruiz
tel: +34 950 015711
fax: +34 950 015486