p2psp team mailing list archive

[Max Mertens <max.mail@xxxxxxxxxx>]

Hi,

thank you for your replies and the explanations.
I skimmed through your protocol descriptions, and the idea of inheriting
sets of rules is great.

NAT traversal without special needs (port forwarding, UPnP, IGD
protocols, ...) is possible through UDP hole punching and TCP over UDP
tunneling:
There is a symmetric approach (perl-based, see [0]), where two peers
only need to know each other's IP, and an asymmetric approach (C-based,
see [1], paper: [2]), where the server does not need to know the
clients' IPs.
The second, asymmetric method however requires raw socket priviledges,
as far as I can see.

Would it be useful for your software stack to add such a NAT traversal
as a python implementation?
However tunneling over UDP is required, I do not know if this is
possible to do by inheriting your DBS classes (if not, one could open a
local TCP over UDP tunneling proxy and let the DBS classes connect to that).

Regards,
Max

[0] http://samy.pl/chownat/
[1] http://samy.pl/pwnat/
[2] http://samy.pl/pwnat/pwnat.pdf



On 19.03.2015 09:49, Vicente Gonzalez wrote:
> Hi!
>
> 2015-03-19 0:51 GMT+01:00 Cristóbal Medina López
> <cristobalmedinalopez@xxxxxxxxx <mailto:cristobalmedinalopez@xxxxxxxxx>>:
>
>
>         According to your possible project ideas page, you would like
>         to have
>         NAT traversal configured e.g. via UPnP (idea 10) to be
>         implemented in
>         your software.
>         So now my question is, if it would be useful to the P2PSP
>         project to
>         implement UDP hole punching and UDP tunneling, in Python or
>         somehow as a
>         "set of rules" or protocol, to provide NAT traversal without UPnP
>         requirements?
>
>
>     I'm sure that Vicente can provide more details of this project
>     than me but I think that the ideal solution would be to work with
>     any type of NAT. However it is not an easy task. Symmetric NATs
>     are a big barrier. Thus, an implementation of the internet gateway
>     device protocol could be useful (and enough) in order to work with
>     most of NATs. I don't see it as a set of rules.
>
>
> The P2PSP (like any other communication protocol) is defined by a
> collection of rules. The main objective of grouping these rules into
> disjoint sets is to facilitate the implementation by taking profit of
> the advantages of the object-oriented programming and in particular,
> of the inheritance. For example, if we some P2PSP community is going
> to stream in a reliable network, IP multicast is not available and all
> hosts can see each other directly (without NATs), the only class that
> need to be used is DBS (or IMS if IP multicast can be used). However,
> if some hosts will be behind "easy" NATs, the FNS class should be
> instantiated (see for example the file splitter_fns.py), which
> obviously inherits from DBS (which defines the most basic behaviour).
> This makes easier the life of the P2PSP implementors and network
> administrators.
>
> Summarising: new set of rules (in the form of Python classes) are
> always welcome because they minimal affect to the rest of set of rules
> and can extend the protocol functionality, without obscuring the
> implementation. And of course, any improvement in the NAT's war is
> also interesting for us.
>
> 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 <mailto:vruiz@xxxxxx>
> http://www.ual.es/~vruiz <http://www.ual.es/%7Evruiz>
> tel: +34 950 015711
> fax: +34 950 015486