Hello! On Wed, Aug 5, 2015 at 6:29 PM Max Mertens <[email protected]> wrote:
> Hi Vicente, > > thanks for your reply! Now the timeout to remove peers that take too long > for being incorporated into the team is implemented. > > Yes, this is something that we need in order to deal with those peers that are unable to connect to a team :-/ > > On 08/03/2015 04:44 PM, Vicente Gonzalez wrote: > > Ok. I added a simple port prediction algorithm to the NTS code, you can >> have a look at the changes here [2]. Currently it determines if the >> difference between the source ports towards the splitter and the monitor is >> <10, and then takes this difference as the step for the port prediction. >> Other possibilities would be assuming a constant step of 1, or to let the >> peers send packets to all port,port+1,...,port+port_difference >> possibilities. Another approach would be to start another listening socket >> at the monitor and gather another source port difference, to detect the >> port allocation type more accurately. >> Which approach would you suggest? >> > > For me, none of the approaches has a clear advantage. Try the simplest one. > > >> How do you think about sending ~10 packets per second to each peer in the >> connection attempt phase, is this too much? >> > > No. The packets are small. > > Ok, then I will make the peer send to different possible port numbers. > Good. > > > Some NATs might be destination port-insensitive when allocating source >> ports, which could lead to a wrong NAT type detection (port preservation >> instead of sequential allocation) if splitter and monitor are on the same >> host. The only option here would be using either public STUN servers or >> having trusted peers with predictable NATs, to determine the source port >> difference for different destination addresses. >> > > Well, there may be more than one monitor peer. Does this solve your > question? > > This would be great for NAT type discovery in the port-insensitive case! > How can you distinguish between additional monitors (not the first in the > peer list) and standard peers? > > 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. > A NAT type combination (marked as "(yes)" in the tables in previous >> emails) that does not work yet is a SYMSP router at an existing peer and a >> port-restrictive NAT (any type except FCN and RCN) at the arriving peer: To >> handle this situation, the existing peer has to send UDP packets to a new >> port at the monitor or at the splitter, to get the currently allocated >> source port of the existing peer and predict its next port. What do you >> think about this? >> > > The use of ports should be minimized, but I suppose that in this case this > use is fully justified. Please, try it. > > Ok. However I cannot test this unless I find some NAT which implements the > sequentially allocating type. > Yes, you're right. I also think that it will be very difficult to find a real NAT with this behaviour :-/ > > Currently I noticed that in some rare cases the TCP socket of the peer > receives 0 bytes from the splitter, which indicates a closed socket. Let's > see if this persists and if a reason can be found. > Please, remind me for what are you using this socket ... Regards, Vi. -- -- 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
