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
-- Mailing list: https://launchpad.net/~p2psp Post to : [email protected] Unsubscribe : https://launchpad.net/~p2psp More help : https://help.launchpad.net/ListHelp
