On Wed, Jul 22, 2015 at 6:17 PM Max Mertens <[email protected]> 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: [email protected] http://www.ual.es/~vruiz tel: +34 950 015711 fax: +34 950 015486
-- Mailing list: https://launchpad.net/~p2psp Post to : [email protected] Unsubscribe : https://launchpad.net/~p2psp More help : https://help.launchpad.net/ListHelp
