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

[Milan Bouchet-Valat]

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.

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

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

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

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