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. -------------- 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/eee70d6f/attachment.pgp>
