p2psp team mailing list archive

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

On Wed, Jul 22, 2015 at 6:17 PM Max Mertens <max.mail@xxxxxxxxxx> wrote:

>  Hi all,
>
> just another status update, see the latest changes here [1]. The commits
> seem small, but it takes more time keeping all message sequences and
> possible packet drops in mind. I certainly have to document this in a
> sequence diagram when it is fully implemented, to explain it in detail. :)
> Currently the following steps until (*) are implemented, see also the
> attached example output for details:
>
>
>
>    1. new peer connects via TCP to splitter and receives UDP address and
>    port of splitter and monitor
>
>
>    1. new peer sends UDP packets to splitter and monitor (the packets
>    include the local source port of the new peer that is used for the
>    respective receiver)
>    2. the monitor forwards the local source port (as stated in the
>    packet) and the global public source port of the new peer to splitter
>
>
>    1. the splitter waits for response of the monitor (*) and determines
>    the NAT type and port allocation scheme
>
>
>    1. the splitter sends the guessed destination port numbers to the
>    existing peers and tells the new peer to send "hello"
>    2. new peer and existing peers send "hello" to the respective
>    destination port
>
>
>
> Considering the crucial role of the splitter, the Splitter_NTS
> implementation stays passive and is only sending single packet replies,
> whereas the peers wait for the splitter and have an extra thread for
> sending continuous hello packets, until an acknowledge packet is received.
>
>
Hi Max,

this scheme sounds good for me.


>
> On 13.07.2015 13:22, Vicente Gonzalez wrote:
>
>  Some thoughts: The step marked with a (*) above seems the most difficult
>> one to implement: The splitter has to keep track of newly arriving peers
>> and wait asynchronously (maybe with a timer) for the response from the
>> monitor, while storing the information about the new peer. The splitter's
>> timers and arriving peers list should be limited, to prevent DoS when a
>> malicious third party sends many joining requests.
>>
>
>  ¿Do you mean that a malicious peer connects the splitter and after that,
> it does not say nothing? Yes, some kind of time-out should be established.
>
> Currently for each arriving peer, the splitter temporarily stores the
> peer's socket, address and 3 source ports (local, to splitter, to monitor)
> until it is encorporated.
>

A question. How is determined the port that the arriving peer will use to
communicate with the monitor? I see the example you sent attached, but it
is not clear for me.


> To limit the number of arriving peers, you could implement regular checks
> how long the arriving peers want to be incorporated, and upon
> unresponsiveness (i.e. no UDP packet is received at the splitter or at the
> monitor) after a certain amount of time they are disconnected (a few
> seconds should be fair enough, as the peers want to do live streaming at
> last).
>

OK.


>
> Next I will add continuous hello packet sending between peers, and then
> the port allocation prediction can be implemented.
>

OK. Thanks Max. Good job.

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