p2psp team mailing list archive

[Max Mertens <max.mail@xxxxxxxxxx>]

Hi Vicente,

On 08/13/2015 11:58 PM, Vicente Gonzalez wrote:
> Well, your heuristic could work. Have you already implemented it?
Not yet, but it is just a few lines to change/add.

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


On 08/14/2015 12:05 AM, Vicente Gonzalez wrote:
>
>     Are the monitor peers assumed to have a known public endpoint,
>     i.e. are not behind a NAT?
>
>
> Yes, you can assume that all monitor peers are fully accessible
> (although they could live in a private network).
>  
>
>     ...
>
> As you prefer, but again, we can assume that all monitor peers will be
> fully accesible from the rest of the team (remember that the monitor
> peers are controlled by the team administrator).
Ok, this is good. Then I will implement the first method (using more
monitors for port step determination), as it does not add much
complexity to the software.

As for the time until "pencils down" date, I plan to finish the last
coding tasks [1] until Sunday, and to test on real hardware from
tomorrow until Tuesday, and after that finish the documentation and
clean up the code until next Friday.

For the testing, I will use the university server for the splitter, and
my home router, mobile network (I am curious about the NAT type) and
some free VPNs (if they have a NAT?) for peers.

On 15.06.2015 08:08, Vicente Gonzalez wrote:
> For now, simulation is enough. However, as you thing, we should test
> the "definitive" solution in a real SYM scenario. I'm pretty sure that
> the University of Almería has one. Let me first check it and, if this
> is true, we'll try to run your code here.
It would be great if you could find out the NAT type of your university,
this [2] is a good tool to check. Do you know about more routers I can
use besides the ones mentioned above?

Thanks,
Max



[1] Currently remaining coding tasks: the two mentioned above (retrying
incorporation, using more monitors to determine port step), determining
the currently allocated source port of existing peers, adding improved
port prediction algorithm.
[2] http://nattest.net.in.tum.de/test.php