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

[Christian Grothoff]

On Saturday 30 May 2009 04:15:27 am Milan Bouchet-Valat wrote:
> Le vendredi 29 mai 2009 à 23:43 -0600, Christian Grothoff a écrit :
> > > 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.
>
> libnatpmp seems to be good to do what it is intended for, it would only
> need to be wrapped I guess. Apparently the lib is not packaged, so project
> copy the few files it provides. Not a big deal.

Ok.

> I don't think the transports should be modified to call the new API
> directly, since the IP may be determined using config files
> (static/DNS), or the new mechanism you described. I'd rather make the
> core call the library trying to get the IP, and for every transport it
> knows about, to open ports in the router. Now, I'm not familiar with the
> networking code in GNUnet...

The core really knows nothing about IP addresses (or transports).  Each 
transport plugin is responsible for providing and validating addresses -- 
nobody else even knows what the format of an address is, or what "port" is 
being used (if at all).  So really the transport plugins are the ones that 
will absolutely have to do this.  But it should be a tiny modification given 
the right API.

> > 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.
>
> About that previous implementation: I guess it was working with 0.8.x,
> so the UPnP-specific code can be kept more or less as-is internally?

Yes, except that the existing UPnP code will have to be rewritten to make use 
of our new util libraries.  Should be a relatively minor change.

> Actually, I've checked again, and my boxes are UPnP, except that they
> don't work with GNUnet's implementation ('make check' fails). So I think
> I'll start the wrapper lib with UPnP, trying to get it working on my box
> (that's what it's for, isn't it?) and then with NAT-PMP.

Sounds good.  The code does work with my UPnP NAT box, but obviously making it 
work with additional systems would be great.

> Or maybe
> getting the UPnP implementation used by Transmission would be better,
> what do you think? This way, I could reuse their whole framework that
> unifies both protocols.

I would not mind, the existing UPnP implementation was adapted from 
pidgin/gaim and is not terribly nice to begin with.  So if Transmission has a 
nice way to do it, I'd be happy to switch.

> > 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.
>
> src/nat sounds good to me, if that's not too close to the NAT transport.

The NAT transport is history (no longer required, thanks to the new way how 
we're dealing with HELLOs).

> Regarding non-blocking calls, I'm not used to network and threads
> coding, but I'll see what I can do. I guess that means running each call
> in a separate thread?

No, it means not using any threads.  It means using a "select" loop.  Read the 
src/include/gnunet_scheduler_lib.h API.  Essentially, instead of doing a 
blocking read/write call, you ask the scheduler to call you once the socket is 
ready to do the operation, and then you do it.  Rather easy.

> > 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).
>
> I'd rather split the lib in different calls: one should get the IP,
> another open a port. There the question of signals triggered when the
> router advertises a IP address change, but that's for a second step.

Splitting it like that is fine with me as well. 

> I guess I'll have to ask you advice often... ;-)

That's fine, I'll try to hang out on IRC ;-).

Christian