I see. Well, any connection requires refs to be sent both ways, because of NATing. And a single announcement request would hopefully result in many nodes connecting; certainly many nodes would have an opportunity to connect. But this may be along the right lines.
On Tue, Jul 11, 2006 at 11:00:07AM -0700, Ian Clarke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > In Dijjer, an announcement can be sent to any peer, and it will then > be routed back towards the location of the announcing peer. Any > peers along that path (that want to) can then establish a connection > to the announcing peer. Seed nodes deal with this announcement > message in exactly the same way that any other node would. > > This mechanism opens up the possibility of separating out the > "destination sampling" link creation process from the data request > process (in 0.5 these were both part of data requests). > > I'm not necessarily advocating this for Freenet, but we should > certainly consider it. > > Ian. > > On 11 Jul 2006, at 10:44, Matthew Toseland wrote: > > >They then do some sort of announcement to the seed nodes which gets > >them > >a bunch of connections to normal nodes? It seems clear that the 5% of > >the network that isn't NATed will not be enough to deal with a typical > >slashdotting, even if only for a short time while they get more > >connections through path folding. > > > >On Mon, Jul 10, 2006 at 05:59:33PM -0700, Ian Clarke wrote: > >>-----BEGIN PGP SIGNED MESSAGE----- > >>Hash: SHA1 > >> > >>The Dijjer approach is to run one or more centrally administered > >>"seed nodes", which aren't behind a NAT, and for nodes to be > >>configured to try to join the network through these by default. The > >>only difference between such a seed node and an ordinary node is that > >>seed nodes don't themselves try to connect to the network when they > >>start, and nodes will never send requests to a node they know is a > >>seed node. > >> > >>Node, on starting up, randomly select two seed nodes, and try to join > >>through them. > >> > >>Ian. > >> > >>On 10 Jul 2006, at 17:50, Matthew Toseland wrote: > >> > >>>How do we implement opennet initial joining? > >>> > >>>We need to provide the node with a list of seed-nodes to connect to. > >>>Each seed-node must be either directly connected to the internet, or > >>>behind a full cone NAT (i.e. effectively directly connected). Given > >>>the > >>>scarcity of such nodes (I expect at least 90% of nodes to be > >>>behind at > >>>least one NAT), we probably need a central registration scheme; > >>>unless > >>>the user tells us not to in the installer, if we are directly > >>>connected > >>>then we register with emu. Harvesting is not an option, because most > >>>nodes are NATed, and therefore completely useless as seednodes. > >>> > >>>Once the newbie node connects to one of these seed-nodes, the seed- > >>>node > >>>must provide it with connections to a number of peers. We have no > >>>other > >>>choice than to implement an announcement protocol; there is no way > >>>that > >>>the seed-nodes will be able to deal with all the newbie nodes on > >>>their > >>>own, even for the time that it takes them to find new nodes via > >>>destination sampling. > >>> > >>>Thus, a new node sends a message to a seednode. It establishes an > >>>encrypted session (authenticating the seednode, but not the new > >>>node, > >>>since it is unknown), and requests some connections, sending its > >>>reference. The seednode picks a random location and then sends an > >>>announcement request to that location. A bunch of nodes receive the > >>>newbie's announcement request, those which are receptive to new > >>>connections (a small minority at any given time!) add its ref to > >>>their > >>>routing tables, with a short connect timeout so that if it does not > >>>connect inside say 5 minutes they will remove it again, and return > >>>their > >>>node references through the request chain to the original node. Thus > >>>both ends know the other's reference, and can connect, even if > >>>there are > >>>NATs between them. > >>>-- > >>>Matthew J Toseland - toad at amphibian.dyndns.org > >>>Freenet Project Official Codemonkey - http://freenetproject.org/ > >>>ICTHUS - Nothing is impossible. Our Boss says so. > >>>_______________________________________________ > >>>Tech mailing list > >>>Tech at freenetproject.org > >>>http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > >> > >>-----BEGIN PGP SIGNATURE----- > >>Version: GnuPG v1.4.2.2 (Darwin) > >> > >>iD8DBQFEsvf1QtgxRWSmsqwRAkvwAJ48x+c4DDlHUWgQg4So9W/DrSk87ACffbkV > >>6zHAr6DSQbZye8LC2KlZQM4= > >>=r9Kb > >>-----END PGP SIGNATURE----- > >>_______________________________________________ > >>Tech mailing list > >>Tech at freenetproject.org > >>http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > >> > > > >-- > >Matthew J Toseland - toad at amphibian.dyndns.org > >Freenet Project Official Codemonkey - http://freenetproject.org/ > >ICTHUS - Nothing is impossible. Our Boss says so. > >_______________________________________________ > >Tech mailing list > >Tech at freenetproject.org > >http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (Darwin) > > iD8DBQFEs+cnQtgxRWSmsqwRAsCgAJ43iVLoXQjPj3jW8Qk4J3cXvqNzCgCeLm6v > he8gLY5ScvzJSl2kNCVCgck= > =UH+Y > -----END PGP SIGNATURE----- > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > -- 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/20060711/f2d51f89/attachment.pgp>
