Hi Vicente, On 03.07.2015 16:27, Vicente Gonzalez wrote: > > Exactly. It would be great having a local source server (on the > host or on a virtual machine), to not strain your public server > and have a reliable source (on the university's network the > connection frequently drops, which alters test results). > Do you just need the VLC command, or do you have to run Icecast as > well? > > > Hi, > > both (VLC and Icecast) can be used as a source. See: > > http://slides.p2psp.org/Elche-2015/indexse11.html#x29-2500011 > > In the point 6, there is an example of using VLC as a source. However, > Icecast is more reliable and it's configuration (at least in a Linux > host) is really easy. Thanks for the link. I had to reset my VLC settings, as somehow the splitter could not read the stream header from VLC (could be some high cache value that I set for smooth streaming). Now it is working, and I added the local source to the test script. Note that it now requires the video file in the working directory, though now does not need an internet connection anymore.
Taking a few ideas from this paper [1], I added subtypes of the symmetric NAT type depending on the public source port allocation (port preservation (SYMPP), sequential port allocation (SYMSP), or random port allocation (SYMRP)) to the documentation and the script. I added a result table below, but have to recheck the values to be certain about the results (the table is not symmetric, I marked the odd results in bold). This implementation of the symmetric NAT subtypes is to determine if the (now following) NTS implementation for symmetric NATs works. An algorithm I would suggest to the P2PSP protocol is to determine if the NAT is a "port preserving symmetric NAT", i.e. the public source port is the same as the source port of the local host behind the NAT (which can easily be determined). Then the only case where a connection cannot be established would be with two symmetric NATs with random port allocation, or with sequential allocation and a "port stepsize" greater than 1 (which seems not supported by the P2PSP algorithms). Regards, Max [1] https://tools.ietf.org/id/draft-takeda-symmetric-nat-traversal-00.txt Results for different symmetric NAT subtypes: Splitter_NTS, Monitor_NTS, Peer_NTS (branch nts, commit 0595dc3): Peer1\2 | fcn | rcn | prcn | symsp | sympp | symrp ======================================================== fcn | yes | yes | yes | no | no | yes rcn | yes | yes | yes | no | no | yes prcn | yes | yes | yes | no | *no* | no symsp | no | no | no | no | no | no sympp | no | no | *yes* | no | no | no symrp | yes | yes | no | no | no | no
-- Mailing list: https://launchpad.net/~p2psp Post to : [email protected] Unsubscribe : https://launchpad.net/~p2psp More help : https://help.launchpad.net/ListHelp
