* Ian Clarke <ian at revver.com> [2006-07-10 17:59:33]: > 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.
It might be interresting to see how other networks are dealing with that. http://actes.sstic.org/SSTIC06/Securite_et_cooperation_reseaux_ad_hoc/ Some slides and an article explaining how MANET (a mesh wireless network) is using trust and cooperation to circumvent "Bad Guys". The first link is in english, following in french :/ NextGen$ -------------- 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/20060715/901d8450/attachment.pgp>
