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... 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. 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.? Cheers, and good luck! _______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org http://lists.gnu.org/mailman/listinfo/gnunet-developers