p2psp team mailing list archive
-
p2psp team
-
Mailing list archive
-
Message #00244
Re: NAT Traversal Set of rules implementation
2015-07-02 18:35 GMT+02:00 Max Mertens <max.mail@xxxxxxxxxx>:
> Hi Vicente,
>
Hello again :-)
>
>
> On 01.07.2015 23:31, Max Mertens wrote:
>
> On 29.06.2015 08:43, Vicente Gonzalez wrote:
>
> No. But we can assume that the monitor peer will run always in the same
> host that the splitter. If you configure the team in such way the problem
> persists? In any case, I would like to know what is happening ...
>
> Ok, and thanks for explaining the reasons for this setup.
> I have adapted the test to the new scenario, with monitor and splitter on
> the same host and two extra peers behind NATs. Output parsing is a bit more
> difficult here, I will write result tables as soon as the test fully works.
>
> In fact the output parsing was working correctly, however the monitor did
> behave strangely when running on the same host as the splitter:
> To reach the internet and connect to the source server, the splitter host
> had a second IP address 10.0.3.15, and apparently this address was reported
> by socket.recvfrom to the monitor if a message is received from the
> splitter on the same host. So the monitor recognized the splitter as a
> peer, and it did not receive chunks from other peers, nor did it forward
> chunks to them.
> So I removed the internet network interface from the splitter host, and
> instead added a local port forwarding using socat to the test script, to
> let the splitter connect to the source (I didn't manage to setup a local
> source, how can you achieve this? When using tools/run_a_source.sh, the
> splitter prints "IMS: No data in the server!").
>
If I did not understand bad your question, you want to run a source in the
same host that the splitter. I have done this several times. You should not
have any difficulty. For example, in the script "tools/create_a_team.sh",
the default source (Icecast) is running at localhost:8080.
> Now everything works as expected, and the peers successfully join the team
> and can send packages to each other and the monitor, see the result table
> below.
>
Good work. It is nice to see that the number of "yes" grows :-)
>
> Sending keepalive packets seems not to be needed, as the connection works
> well without. However if any issues in maintaining the connections is
> experienced, I will try that as a solution.
>
OK.
> So the next steps will be finishing the documentation until so far and
> then continue the NTS implementation to handle symmetric NATs.
>
>
OK.
>
> An unrelated question: To determine the address to listen on, in Peer_IMS
> the public IP address is gathered by this code [1]:
>
> s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
> s.connect(("gmail.com",80))
> #my_ip = socket.gethostbyname(socket.gethostname())
> my_ip = s.getsockname()[0]
> s.close()
>
> However it might not be possible (e.g. in a virtual machine setup where
> the peers don't have a direct connection to the internet) or desired for
> the peer to send packets to gmail.com. Would it be possible to do the
> same technique but connect to the splitter IP address instead, as it has to
> be reachable from the peers anyway?
>
>
Sure. Go ahead.
> Regards,
> Max
>
> [1] https://github.com/P2PSP/p2psp/blob/master/src/peer_ims.py#L99
>
>
> Test results when the monitor is located on the same host as the splitter:
>
> Splitter_LRS, Monitor_LRS, Peer_FNS (branch master, commit e4e16bd):
>
> Peer1\2 | fcn | rcn | prcn | sym
> =========================================
> fcn | yes | yes | yes | yes
> rcn | yes | yes | yes | yes
> prcn | no | no | no | no
> sym | no | no | no | no
>
>
> Splitter_NTS, Monitor_NTS, Peer_NTS (branch nts, commit 395aa1e):
>
> Peer1\2 | fcn | rcn | prcn | sym
> =========================================
> fcn | yes | yes | yes | yes
> rcn | yes | yes | yes | yes
> prcn | yes | yes | yes | no
> sym | yes | yes | no | no
>
>
>
Best,
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: vruiz@xxxxxx
http://www.ual.es/~vruiz
tel: +34 950 015711
fax: +34 950 015486
Follow ups
References
-
NAT Traversal Set of rules implementation
From: Max Mertens, 2015-06-06
-
Re: NAT Traversal Set of rules implementation
From: Vicente Gonzalez, 2015-06-08
-
Re: NAT Traversal Set of rules implementation
From: Max Mertens, 2015-06-11
-
Re: NAT Traversal Set of rules implementation
From: Vicente Gonzalez, 2015-06-12
-
Re: NAT Traversal Set of rules implementation
From: Max Mertens, 2015-06-14
-
Re: NAT Traversal Set of rules implementation
From: Vicente Gonzalez, 2015-06-15
-
Re: NAT Traversal Set of rules implementation
From: Max Mertens, 2015-06-21
-
Re: NAT Traversal Set of rules implementation
From: Vicente Gonzalez, 2015-06-22
-
Re: NAT Traversal Set of rules implementation
From: Max Mertens, 2015-06-24
-
Re: NAT Traversal Set of rules implementation
From: Vicente Gonzalez, 2015-06-25
-
Re: NAT Traversal Set of rules implementation
From: Max Mertens, 2015-06-25
-
Re: NAT Traversal Set of rules implementation
From: Max Mertens, 2015-06-28
-
Re: NAT Traversal Set of rules implementation
From: Vicente Gonzalez, 2015-06-29
-
Re: NAT Traversal Set of rules implementation
From: Max Mertens, 2015-07-01
-
Re: NAT Traversal Set of rules implementation
From: Max Mertens, 2015-07-02