Dear Mentors, I updated my SoC application. Cheers, Thomas
On Thursday 04 May 2006 14:35, Matthew Toseland wrote: > On Thu, May 04, 2006 at 12:21:26AM +0200, Thomas King wrote: > > On Wednesday 03 May 2006 22:06, Matthew Toseland wrote: > > > On Wed, May 03, 2006 at 09:43:28PM +0200, Thomas King wrote: > > > > > > 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. :) > > > > Ups, I haven't found this code. Sorry. > > > > Hmm, what do you think about an abstraction layer that uses whatever > > technology is available or enabled (e.g. STUN, UPnP, Zeroconf, Peers, > > ...) to discover the official IP address and do further configurations > > (e.g. port forwarding). The idea is that different NAT circumvention > > technologies can easily plugged in without any change in the core of the > > Free Network Project client. So lets say UPnP will be really dead in two > > years and Zeroconf is the technology of the future it will be very easy > > to write a Zeroconf module and plug it into the NAT circumvention layer. > > Sounds great?!?!???? > > Good idea yes. Just write an interface, and split all the current > mechanisms into classes which implement it, and have an aggregator > probably in Node. You will need to have a credibility value for each, so > e.g. "another node told me" is lowest precedence. And you might even want > to combine it with multi-homing support (3 nodes said I am w.x.y.z, 4 > nodes said I'm a.b.c.d, UP&P, which could be faked, said I am e.f.g.h). > > > Cheers, > > Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 481 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20060504/363b0396/attachment.pgp>
