p2psp team mailing list archive

[Max Mertens <max.mail@xxxxxxxxxx>]

Hi Vicente,

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?

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


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.

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.

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

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.

Have a nice week,
Max


[1]
https://github.com/jellysheep/p2psp/commit/a8021e459519ce185ce9aed341ae175d05de8a7a