p2psp team mailing list archive

[Vicente Gonzalez <vicente.gonzalez.ruiz@xxxxxxxxx>]

On Sat, Jul 11, 2015 at 6:16 PM Max Mertens <max.mail@xxxxxxxxxx> wrote:

>  Hi Vicente,
>
>
Hello!


>
> On 09.07.2015 12:31, Vicente Gonzalez wrote:
>
>
>
>>  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).
>>
>
>  Please, refresh my memory: Which is the difference between Peer1 and
> Peer2?
>
> Peer 1 and 2 are completely identical except that Peer 2 is started after
> Peer 2, so the arrival order is different: Peer 1 is already a team member,
> whereas Peer 2 is the newly joining peer.
> An asymmetric behaviour could happen, as it makes a difference if the
> existing or the newly joining peer is behind a NAT.
>

OK.

>
>  That's right. Well, however, if we are able to determine the port
> allocation scheme used by a NAT, do you think that we could traverse it?
>
> Yes, exactly. I suppose that NAT traversal should be possible in all cases
> except between two NATs with indeterminable (i.e. random) port allocation
> (or with NATs with some weird behaviour).
>

OK.


> To determine the port allocation scheme, a newly arriving peer should send
> packets to the splitter and the monitor¹, and the splitter then sends the
> NAT type back and to the other peers to facilitate the connection
> establishment.
> The timing would look like this (in contrast to the current NTS
> algorithms, the NAT type determination happens at the splitter instead of
> the monitor):
>
>    - new peer connects via TCP to splitter and receives UDP address and
>    port of splitter and monitor
>
>
A question. It is supposed that the splitter uses the same end-point for
the TCP and UDP connection. ¿Why the incoming peer need the address and
port of the splitter?


>
>    - 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)
>    - the monitor forwards the local source port (as stated in the packet)
>    and the global public source port of the new peer to splitter
>    - the splitter waits for response of the monitor and determines the
>    NAT type and port allocation scheme (*)
>     - the splitter sends the guessed destination port numbers to the
>    existing peers and tells the new peer to send "hello"
>     - new peer and existing peers send "hello" to the respective
>    destination port
>
> How do you think about this approach, do you have suggestions/comments?
>

I see it fine,


> Is it ok to directly implement this, or should I first implement the
> algorithms as stated in the P2PSP paper, and afterwards add support for
> other NAT types?
>

I think that the algorithms that you are developing could have more success
than the described in the white P2PSP paper, which need some maintenance
after some time without improve them.


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


> A related thing to consider: If two peers behind the same NAT want to join
> the team simultaneously, the splitter and monitor must differentiate
> between the two peers. For a symmetric NAT, the splitter cannot match the
> source ports received by the monitor to the source ports received by
> itself, as all are different. So an idea is to assign random unique peer
> IDs at the splitter and send them to the peer over the TCP connection. Then
> for the joining process, the ID is sent with each packet to identify the
> peer.
>

Excellent idea.


>
> In Peer_NTS, to handle different NTS-specific messages, I just copied over
> the process_next_message method from Peer_DBS and added another case.
> However, it seems simpler to handle specific messages in inheriting classes
> (i.e. Peer_NTS) and forward all other messages to be handled by the base
> class (Peer_DBS). I have submitted a pull request that implements this
> technique [1]; it would be great if you could have a look at it and shared
> your thoughts.
>
I have not seen the pull request ... yet. Probably it is in the list of
unread emails ... However, your inheritance thoughts are accurate :-)

>
> Just a thought that appeared when extending the process_next_message
> method: Currently, to differentiate between message types, the length of
> the message is compared to the expected struct size. For a small number of
> message types, this seems a good and easy to understand technique, however
> it could lead to collisions if some protocols are changed or the number of
> message types increases. Is there another approach (e.g. a message type
> prefix) planned for later versions of the P2PSP implementation?
>
The minimization of the protocol overhead is essential, so, if we can live
without extra fields in the headers, perfect. However, it is quite likely
that at the end, when the complexity of the protocol grows, we will use
this technique. So, if you see the thing more clear using message type
prefixes, go ahead.

 Thanks, and sorry for the long email :)
>
Don't worry :-)

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: vruiz@xxxxxx
http://www.ual.es/~vruiz
tel: +34 950 015711
fax: +34 950 015486