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

[Christian Grothoff]

On Sunday 31 May 2009 04:41:06 am Milan Bouchet-Valat wrote:
> Le samedi 30 mai 2009 à 12:47 -0600, Christian Grothoff a écrit :
> > 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.
>
> No issue, except about the IP adress. Since it can be detected via
> different means, we need some kind of centralization, i.e. a function
> that will check for config files, then NAT, and finally use the new
> framework for that. Should it be done in the nat library, or should it
> just provide a function to be called by another lib?

No, we don't need that type of centralization: we now support having 
*multiple* IP addresses.  This is required for proper IPv6 support anyway.  So 
all that will really happen is that the UPnP/PMP library should allow us to 
register a callback which will be called whenever there is an external IP 
address to be added to (or removed from) our IP list.  I've thought about it a 
bit more and here is what I'm thinking of for the API right now:

// add_remove: YES: add, NO: remove
// addr: see man 2 bind
void (*GNUNET_NAT_AddressCallback)(void *cls, int add_remove, 
                                    const struct sockaddr *addr,
                                    socklen_t addrlen)

struct GNUNET_NAT_Handle;

struct GNUNET_NAT_Handle *
GNUNET_NAT_register (struct GNUNET_SCHEDULER_Handle *sched,
                                struct GNUNET_CONFIGURATION_Handle *cfg,
                               const struct sockaddr *addr, socklen_t addrlen,
                             GNUNET_NAT_AddressCallback callback, 
                             void *callback_cls);
void
GNUNET_NAT_unregister (struct GNUNET_NAT_Handle *h);


Calling "register" is asking for the given IP address (which can be v4 or v6) 
to be made available "more globally" (mapped by the NAT box).  If such a "more 
global" address becomes available, the callback should be invoked with the 
address other peers should bind to.  If the mapping changes, the callback 
would be called with "NO" (on the old address) and then "YES" on the updated 
address.  

Note that "register" could be called on a range of IP addresses (127.0.0.1,
 ::1, 192.168.1.42) and ports (2086, 1080, ...).  The NAT could would have to 
decide if that address was somehow "mappable" (and do nothing if not) and for 
those that are do the right thing.

> > > 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.
>
> Latest update: 'make check' now reports my IP address, so something must
> have improved in GNUnet or in my box in this regard. So I'll consider
> what's the more logical/robust/clean solution, assuming the current
> implementation works.

Ok! Good to know.  I don't think anyone touched the UPnP code recently.

> > > 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.
>
> Good, I'll look at that.
>
> > > I guess I'll have to ask you advice often... ;-)
> >
> > That's fine, I'll try to hang out on IRC ;-).
>
> Don't spend your nights on IRC for me, I think I'm going to work on this
> sparsely (between exams and holidays!). I'm simply planning to follow
> your schedule for 0.9.0... ;-)
>
>
> Additionally, here are a few things I think could be good to keep in
> mind when designing 0.9:
>
> - We need a way for the daemon to send warning messages to the clients,
> e.g. show a conspicuous message in gnunet-gtk about TCP transport
> failing, library not found, etc. Logging is not usable for all cases and
> is very misleading for new users that don't understand what fails. Maybe
> GNUNET_ERROR already allows for this, though.

We have the "component" in the log call which tells us what part of the system 
caused the problem. My current thinking here is that for GUIs we should have 
an easy way for users to inspect the log file.  And of course, if error 
messages are expected to happen, we should have some way in the API between 
the two processes to pass the specific message.  But I'm not thinking of doing 
that for any messages logged using GNUNET_log.

> - It would be nice to allow downloads to go on on background, while
> closing all clients. I think this should be performed in the daemon
> itself - starting a new per-user process for that would not allow you to
> close your session and come back, for example. While this feature is not
> required to be present soon, keeping in the design the ability to add it
> at some point would be nice

First of all, there won't be "the daemon itself".  And yes, I was thinking of 
having a daemon for managing FS activities in the background.  However, I'm 
not anywhere near touching that code yet.

> - And posting a news on the website to sum up what you said in your mail
> would help people to keep in touch with the development. We've heard
> many times that the sites looked like it was dead - giving details and
> showing there's work going on will encourage users to persevere...

Hmpf.  More work :-).  I'll see what I can find time to do...

Christian