On Wed, May 03, 2006 at 09:43:28PM +0200, Thomas King wrote: > Hello, > today, I received two mentor's comments about my SoC application "STUN and > UPnP support for the Free Network Project client" from the mentors (thanks > for the valuable critics). I would like to comment the mentor's comments as > well as adjusting my proposal: > First mentor's comment: This is interesting, but I am concerned about the > reliance of STUN on contacting a STUN server to determine IP address - > ideally a Freenet node could determine this using another Freenet node that > wasn't behind a firewall, rather than a single centralized node used by > everyone. Could the proposal be generalized such that if STUN did not prove > to be appropriate, alternate means of NAT circumvention, perhaps more > customized to the needs of Freenet, could be employed? > > My comment: There are many STUN servers out there so the implementation could > randomly select a STUN server. However, I like the idea of using one of the > seednodes instead of STUN server infrastructure. Furthermore, all STUN > features are not required, instead it is sufficient if the client discovers > the presence of a NAT between itself and the public Internet. So, I propose > to add only a minimal set of STUN (client and server) features so that the > discovering process can be accomplished without any help from further > infrastructure.
It is more important for it to discover its external IP address. However, on darknet, we can already ask a node for our IP address. > > Second mentor's comment: We can ALREADY determine our IP from a trusted > Freenet node not behind a firewall. STUN allows us to use the standard > framework supported by many VoIP and P2P clients, to determine our IP > address. UP&P is also somewhat interesting, although we will have to ask the > user if he is on an untrusted LAN before probing for it. > > My comment: I double-checked the Freenet Network Project source code (latest > version available on the website) and I could not find any hint that a client > is able to learn its official IP address from a trusted node if it is located > behind a NAT. With the current implementation of the IPAddressDetector it is > only possible to learn the IP addresses of the client's network interfaces. > If the client is located behind a NAT this mechanism will only reveal private > IP addresses (that are not accessible from the public Internet). So, as I > mentioned above I propose a minimal set of STUN (client and server) features > to enable a client to learn its official IP addresses. Fred 0.7 includes code to send the IP address of a node to any node which connects successfully; the message FNPDetectedAddress. This is used in Node.detectPrimaryIPAddress(). Admittedly this probably ought to be in IPAddressDetector. :) > I agree with you. If I am going to add UPnP to the Freenet Project client > will > I add a switch in the configure file to en-/disable UPnP (I will also add a > question screen to the installer). Ok. > > What do you think about my adjustments? I think STUN is useful, and UP&P may be useful. > > Thanks for your great comments! > > Cheers, > Thomas -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20060503/871e3201/attachment.pgp>
