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