p2psp team mailing list archive

[Vicente Gonzalez <vicente.gonzalez.ruiz@xxxxxxxxx>]

On Sun, Aug 16, 2015 at 12:22 PM Max Mertens <max.mail@xxxxxxxxxx> wrote:

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

Hello Max,

good work! Only for this example [2], could you send to me a timeline with
the messages between peers, splitter, monitor peers, etc. in order to
understand it better (and remind to me a lot of forgotten things :-)?

Well,  this project has been a difficult one (it has a lot of research work
and possible results). Therefore, the documentation is as important as (or
even more than) the code. We (I and the rest of mentors of P2PSP) also
think that your work could be published in a conference (such as the
International
Conference on Computer Communication and Networks
<http://icccn.org/icccn15/>) or even a journal  (an example could be: Computer
Networks <http://www.sciencedirect.com/science/journal/13891286>), and we
would delight if you collaborate with us in this task. What do you think
(of course, this will not affect to our work/evaluation/results for the
GSoC)?

Regards,
Vicente.
-- 
-- 
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