-----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-----
