← Back to team overview

p2psp team mailing list archive

Re: NAT Traversal Set of rules implementation

 

On Mon, Aug 10, 2015 at 4:29 PM Max Mertens <max.mail@xxxxxxxxxx> wrote:

> Hi Vicente,
>
> Hi Max,


>
> On 08/06/2015 10:02 AM, Vicente Gonzalez wrote:
>
> 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.
>
> Thanks for this explanation, this is a great solution. So I will send an
> implementation proposal as a pull request, if that is ok?
>

Yes.


>
>
> 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 ...
>
> This is just the TCP connection between peer and splitter, during sending
> the IDs of the existing peers to the arriving peer (in
> disconnect_from_the_splitter()). It occurs in about 5% of the test runs
> and leads to connection failure.
>

In your code ..., ¿where is this function declared?


>
> The sequentially allocating NAT can finally be simulated, with an
> adjustable port step. I found a workaround that forces the NAT to create a
> new mapping: First another temporary socket is connected to the destination
> host, then the original used team_socket has to skip to the next
> available port. This is done several times for higher port steps. You can
> have a look at the commit here [1], the implementation is similar to the
> Lossy_Peer.
>

OK, good idea.


>
> The last few days I adapted the Peer_NTS class to connect to several ports
> (probable source ports of the other peer), i.e. the incorporated peers send
> to a number of consecutive ports at the arriving peer behind a SYMSP NAT
> (sequential source port allocation).
> Currently I am developing an algorithm to find the most probable source
> ports to try. For example, if a port difference of 10 between the port to
> the splitter and to the monitor is determined, then the actual port step
> could be one of {1,2,5,10}. So until now the 3rd existing peer would try
> the ports source_port_to_splitter+{3,4,...,15}, and with the new
> algorithm the ports
> source_port_to_splitter+{3,4,5,6,7,8,10,12,15,20,30,40} are tried.
>

Why do you expect that with the new algorithm the performance will be
better?


>
> Also the case when an incorporated peer is behind a SYMSP NAT, is now
> handled. The arriving peer tries different ports at the incorporated peer,
> with the port step determined before.
> This will be extended so that each arriving peer sends the used source
> port of the incorporated peers to the splitter, to determine the port step
> of the incorporated peers accurately. Also for each arriving peer, the
> incorporated peers behind a SYMSP NAT will have to connect to another port
> at the splitter, to determine the currently allocated port number (which
> could be different if many UDP connections are established).
>
>
I see.


> The test results (just the relevant parts) now look like this:
>
> Splitter_NTS, Monitor_NTS, Peer_NTS (branch nts, commit adc3867):
> Results in % (20 test runs):
>
> Peer1\2 | sympp | symsp
> ========================
> sympp   | 95    | 95
> symsp   | 80    | 70
>
> The case SYMSP<->SYMSP is difficult to handle in real-world scenarios, as
> for each tried destination port (probable source port of the other peer)
> another source port is created. So if another UDP connection besides the
> P2PSP software is established, the two peers are "out of step" and cannot
> connect to each other, because the source ports do not match.
>

Well, this is something quite difficult to control. I suppose that for
these cases, the incoming could try to join the team more than one time,
with the aim of that this situation does not happen in some of the tries.


>
> Have a nice week,
>

You too :-)

Vi.


> Max
>
>
> [1]
> https://github.com/jellysheep/p2psp/commit/a8021e459519ce185ce9aed341ae175d05de8a7a
>
-- 
-- 
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

Follow ups

References