p2psp team mailing list archive

[Max Mertens <max.mail@xxxxxxxxxx>]

Hi Vicente,

thanks for your emails and for merging the pull request! :)

On 13.07.2015 13:22, Vicente Gonzalez wrote:
>
>       * new peer connects via TCP to splitter and receives UDP address
>         and port of splitter and monitor
>
> A question. It is supposed that the splitter uses the same end-point
> for the TCP and UDP connection. ¿Why the incoming peer need the
> address and port of the splitter?
Sorry, my fault. I didn't remember that the same port is used for UDP
and TCP connection. Of course in this case, that information does not
need to be sent to the peer.

>     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.
Yes, exactly.

> The minimization of the protocol overhead is essential, so, if we can
> live without extra fields in the headers, perfect. However, it is
> quite likely that at the end, when the complexity of the protocol
> grows, we will use this technique. So, if you see the thing more clear
> using message type prefixes, go ahead.
Ok, thanks for the explanation. Currently the different message types
are overseeable, so I'll stick to the current solution.

Regards,
Max