Hi! I've worked a little on the NAT front, and I've come to something that basically builds. Now, I need to rework most of the generic code around UPnP and NAT-PMP actual implementations, since Transmission was working on a very different basis than ours. But there are a few things that I don't really understand (see below).
Le dimanche 31 mai 2009 à 12:31 -0600, Christian Grothoff a écrit : > 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. >From what I know of UPnP and NAT-PMP, I understand that you cannot choose the addresses (nor internal nor external) for which the redirection is performed: the internal address we used to send the request will be used for internal redirection, and the external address is chosen by the NAT box. So we can't take a sockaddr, but merely a port number. Moreover, isn't NAT kind of obsolete on IPv6? My knowledge in this realm is very limited, though. > 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. You mean called several times, once for each address/port? That means we need a GNUNET_NAT_Handler_Init() function, and then pass the struct to register(). But I can't see how we could pass addresses, as I said above. Other than that, I could not find the cron jobs API that was in GNUnet 0.8. I'd need some kind of timers to regularly check that the NAT is still working. I'd also need a basic list support if we want to use several ports, though I can use a custom singly-linked list if nothing exists. Cheers _______________________________________________ GNUnet-developers mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnunet-developers
