p2psp team mailing list archive

[Max Mertens <max.mail@xxxxxxxxxx>]

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
 2. 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)
 3. the monitor forwards the local source port (as stated in the packet)
    and the global public source port of the new peer to splitter
 4. the splitter waits for response of the monitor (*) and determines
    the NAT type and port allocation scheme
 5. the splitter sends the guessed destination port numbers to the
    existing peers and tells the new peer to send "hello"
 6. 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.

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.
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).

Next I will add continuous hello packet sending between peers, and then
the port allocation prediction can be implemented.

Regards,
Max


[1] https://github.com/P2PSP/p2psp/compare/a4f1592...jellysheep:nts

Example output of the NTS classes (commit 141bc4d).
1401 is the peer port, 1501 is the splitter port.
192.168.57.6 is the host of splitter and monitor,
192.168.57.4 is the host of the arriving peer.

Splitter: Accepted connection from peer ('192.168.57.6', 1401)
Splitter: Sending an empty list of peers
Splitter: Sending ID FPHVC9O to peer ('192.168.57.6', 1401)
Splitter: Incorporating the peer FPHVC9O. Source ports: 1401, 1401, 1401
Splitter: Sending [send hello to ('192.168.57.6', 1401)]
Monitor: Requesting peer ID from splitter
Monitor: ID received: FPHVC9O
Splitter: Accepted connection from peer ('192.168.57.4', 22677)
Splitter: Sending the monitor as the list of peers
Splitter: Sending ID 57QNZAS to peer ('192.168.57.4', 22677)
Peer: Requesting peer ID from splitter
Peer: ID received: 57QNZAS
Peer: Sending hello (57QNZAS) to ('192.168.57.6', 1401)
Peer: Sending hello (57QNZAS) to ('192.168.57.6', 1501)
Monitor: Received hello (ID 57QNZAS) from ('192.168.57.4', 64943)
Monitor: Forwarding ID 57QNZAS and source port 64943 to splitter
Peer: Received acknowledge from ('192.168.57.6', 1401)
Splitter: Received hello (ID 57QNZAS) from ('192.168.57.4', 22677)
Peer: Received acknowledge from ('192.168.57.6', 1501)
Splitter: Received hello (ID 57QNZAS) from ('192.168.57.6', 1401)
Splitter: Incorporating the peer 57QNZAS. Source ports: 1401, 22677, 64943
Splitter: Sending [send hello to ('192.168.57.4', 22677)]
Monitor: Sending hello (57QNZAS) to ('192.168.57.6', 1501)
Monitor: Received acknowledge from ('192.168.57.6', 1501)
Monitor: Received [send hello to ('192.168.57.4', 22677)]
Monitor: Sending hello (FPHVC9O) to ('192.168.57.4', 22677)
Monitor: Sending hello (FPHVC9O) to ('192.168.57.4', 22677)
Monitor: Sending hello (FPHVC9O) to ('192.168.57.4', 22677)
Monitor: Sending hello (FPHVC9O) to ('192.168.57.4', 22677)
# ... the arriving peer does not send hello packets yet ...