p2psp team mailing list archive

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

On Thu, Aug 13, 2015 at 5:11 PM Max Mertens <max.mail@xxxxxxxxxx> wrote:

> Hi Vicente,
>
>
> On 08/11/2015 08:09 AM, Vicente Gonzalez wrote:
>
> 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?
>>
>
> Yes.
>
> Now I submitted a pull request, and I have another question about this:
> 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).


>

> If yes, this would help for port step determination:
>

>    1. the arriving peer sends UDP packets to all monitors
>    2. after receiving all packets, the splitter incorporates the peer.
>
>
Yes, this could give some information about the port allocation procedure.


>
>
> If not, the UDP packets would not reach the monitor (because of the NAT).
> So in this case, I think the following would be a more reliable
> implementation:
>
>    1. the arriving peer tries to get incorporated into the team, with one
>    monitor
>    2. all peers, including the additional monitors, send source port
>    information about the arriving peer to the splitter (see commit [1]
>    <https://github.com/jellysheep/p2psp/commit/756b6e0>)
>    3. the peer possibly fails to get incorporated and tries again
>    4. the splitter now knows the port step reliably from 2.
>
> So I would go with the second implementation, as it works also if the
> additional monitors cannot be reached, and has the only drawback that
> sometimes the arriving peer has to retry connection one time.
>
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).

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