← Back to team overview

p2psp team mailing list archive

Re: NAT Traversal Set of rules implementation

 

Hi Vicente,

On 08/14/2015 02:36 PM, Max Mertens wrote:
>>
>>>     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.
>>     This would be good and convenient for the user, if you do not
>>     have to retry connecting the peers yourself. I would like to
>>     implement it like this:
>>     Considering the splitter timeout noted above, the peer will have
>>     a timeout on its own and will retry incorporation into the team
>>     before the splitter quits the connection. Also if a connection to
>>     one or more peers cannot be established (I suppose *all* have to
>>     be working for P2PSP to work), then the peer will retry as well.
>>     When retrying incorporation, the peer sends goodbye messages to
>>     all connected peers and closes the UDP socket, then retries
>>     sending UDP packets from a new socket to the splitter and the
>>     monitor again. So the TCP connection to the splitter has to
>>     remain open until the arriving peer is connected to all existing
>>     peers (or else the peer would have to start "from scratch",
>>     connecting to the splitter, receiving the configuration etc.).
>>
>>
>> Well, keeping the TCP connection to the splitter could be dangerous
>> for the splitter if the number of incoming peers (with joining
>> problems) is high, but, taking into account that we have only two
>> more weeks to finish our work, please, implement the easiest (for
>> you) solution.
> Ok, now I have implemented most parts of this, and the TCP socket can
> be closed as early as before, because all further communication
> between splitter and peer uses UDP.
Now I finally finished the implementation, it was hard to get it fully
working, with all messages sent and the peer data updated correctly; now
it works fine. :)
After all it was better to keep the TCP socket open, as the existing
peers have to be transmitted reliably and doing this over UDP would
impose more overhead than leaving the TCP connection open.
You can have a look at the changes here [1] and a live output can be
watched here [2] (it is a PRCN<->SYMPP scenario, which for a very low
network delay does not work everytime).

Thanks,
Max

[1]
https://github.com/jellysheep/p2psp/commit/ee337d87a173292bb76c76e422c4143a4a63017f
[2] https://asciinema.org/a/1wxkq1mf4oseiex1hzfn0gkst

Follow ups

References