Re: [GNUnet-developers] towards gnunet 0.9.x

[Christian Grothoff]

On Friday 29 May 2009 03:28:30 am Milan Bouchet-Valat wrote:
> Wow! Never tired of rewriting GNUnet to get it master the world! ;-)
> Reading the rationale, I see fantastic plans that really seem to allow
> for a very robust and full-featured networking system.
>
> Reading the analysis, a question has occurred to me : why didn't you
> choose C++ instead of plain C? At least with namespaces and classes, it
> would help making the different parts of the code cleaner. You know I
> hate C, while that's the language I code the most in... ;-)
> Also, using a general purpose library such as the GLib or Qt's fundation
> classes could be useful. Just wondering, not asking you to change your
> code now that it's done...

I didn't think C++ would really help.  And using glib/qt as a foundation would 
hugely increase the footprint of the background processes, which is not good 
either.  Not to mention I did not feel like these libraries would really 
contain much useful code: most of the code is networking-related at this 
point.

> On the details part, I particularly liked that one:
> > * With discovery being part of the transport service,
> >   it is now also possible to "learn" our external
> >   IP address from other peers (we just add plausible
> >   addresses to the list; other peers will discard
> >   those addresses that don't work for them!)
>
> That was one of the utopic designs I had imagined to solve that issue.
> Glad you chose it!

:-).

> Now, I've noticed that GNUnet's UPnP support doesn't work for the two
> router I've used, while some Internet applications do. One is Transmission
> Bittorent, another is Pidgin Instant Messaging. They automatically open
> the ports you need to make them work, and get your IP address. Looking at
> Transmission's code [1], there are three files about UPnP and NAT-PMP, and
> it's including a little lib called libnatpmp. It seems that these two
> protocols are concurrents, and my modems are using the latter.

libnatpmp is free software, so the question is mostly if it is good enough to 
be used directly.  I'd certainly like to see PMP and UPnP support in 0.9.x.  
IMO the first step would be to write a little library/API that could be used 
by any transport to obtain an external IP/port and/or create an entry in the 
port mapping done by the NAT box. Modifying the transports to add the 
resulting address to their list should then be quite easy.  

The repository contains some highly preliminary incomplete code (largely 
copied from the 0.8.x tree) for UPnP. If you want to work on making this nice, 
that'd be great.

> It shouldn't be too hard to get working in GNUnet, and that would provide
> people with easy ports redirection, and of a "certified" external IP
> address, else the general framework would get it from other peers. I could
> give a try a this one of these days (weeks). Are there special thoughts
> about it, or where it should go, etc.?

It should probably go into src/upnp, or something like src/upnppmp or some 
other name capturing both (src/nat?).  If the libraries that you write or use 
can operate without ever blocking (which good network libs should allow), then 
I think a simple shared wrapper library (ideally encapsulating both UPnP and 
PMP support) would do.  

gnunet/src/include/gnunet_upnp_service.h contains my first draft at a simple 
API that I'd like to see.  Maybe too simple, suggestions would be welcome. Oh, 
and if the API is implemented as a simple library, the header should be called 
"something_lib" in the end, not "something_service" (since we use the latter 
for things implemented by an external process where the shared library is just 
a convenience wrapper).

Best,

Christian