Heh, I don't mean to be harsh, just trying to understand the final goal. If you're instead designing technology without any real clear product in mind, perhaps you'd better take this to an IETF mailing list. (Just kidding!)
Regarding bootstrapping, I think the only truly resilient mechanism is to just accept a list of IP addresses of arbitrary nodes. Then so long as you can get the IP address of a single working node, you can join the network. Furthermore, so long as there are people willing to share IP addresses of nodes (via web, email, IRC, etc), then the network can continue to be joined by new nodes (and repair itself in the event of damage) no matter how many heads are severed off the hydra. The reason this is important is it creates a requirement for your mesh: given any individual node, you need some way to find all the others. I'll admit, I didn't exactly follow your proposal, but it sounds like it uses a sort of top-down allocation, which might violate this implicit "decentralized bootstrapping" requirement. If I understand correctly, there's no way to "jump" from one sphere to the next except via the poles. If you attack both poles simultaneously, you can effectively sever the network beyond repair. Furthermore, it looks like the bootstrapping server and poles assign you your location in the topology. Thus the only way to "join" the network is through a couple, vulnerable spots. Again, knowing what the final application is really matters. If your goal is to make an indestructible mesh, then the #1 priority is ensuring it's indestructible. But if being indestructible isn't the goal, then I wonder why you are considering a decentralized topology at all? If you're willing to accept that your network can be destroyed, then why bother with all the complexity of decentralized indexing when central servers are faster, cheaper, more reliable, and better in every measurable way? (Other than geek cred, that is.) -david > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:p2p-hackers- > [EMAIL PROTECTED] On Behalf Of Gustavo Carreno > Sent: Sunday, September 09, 2007 4:59 PM > To: theory and practice of decentralized computer networks > Subject: Re: [p2p-hackers] New protocol idea > > On 9/9/07, David Barrett <[EMAIL PROTECTED]> wrote: > > It sounds like an interesting idea, but my first question is: > > > > What problem are you trying to solve? > > >From one or two implementations (topologies) that I know of, one that > I, kinda, understood was circle and the other is what I call the > general implementation, all of them have 2 dimensional topologies. > That is, they have N maximum connections (to avoid to many connections > per client) to N clients and they have to keep a track of routing in > tables. Thi leads to very long tables once the grid gets really big. > My way routing is easy since you have 3 coordinates and can send > message to pole nodes until reached the appropriate level and then go > to meridian via parallel. In my naive way of thinking about routing it > makes more sense, instead of looking on a table to see if you know the > route, then if not take a guess or some other algorithm that I'm > unaware to reach some node. I think, not sure, that circle uses some > kind of circular search if table fails, reinforcing my ignorance it's > just an educated guess. > > > Basically, what sort of real-world application do you envision using > this > > for (is it an integrated file-searching/sharing system?), and how is > this > > No application yet. Why ? Simple: if this makes any sense on a pure > P2P network with balancing, increase node limit, less latency, more > accurate pin point of alive versus dead nodes and all other P2P > optimizations that I don not recall now, then I'll consider all the > input in favour of a file sharing, messaging or pure and simple > resource sharing or what would be the strengths of this kind of > implementation in any of the fields of P2P. > > > better than the next-easiest solution to the same problems (eg, doing > all > > searches on a central server)? > > This is where I need input from the community: Since searches will > propagate in the way I've described on my first mail and will get back > to the initiator node via fast routing, vide my rant on routing some > paragraphs above, is this better or worse that all of the > implementations you (community) can think of ? > > > For example, you mention "the bootstrap server". If the goal is to > create a > > p2p file-sharing application that is impossible to shut down, then > before > > worrying about anything else, you need to figure out how to create a > > bootstrapping service that also can't be shut down -- until that's > solved, > > your attacker will skip all your fancy P2Pness and just go right for > your > > centralized jugular. > > You have a very good point and I really don't have a fail safe answer > to that. Mostly since I'm just a curious P2P observer and have not a > record of all the possibilities of bootstrapping nor the safe > combinations of the non safe ones. > > You'll notice along ALL of my mails that I'll have to plead ALOT of > ignorance and will ask MANY TIME to forgive me for attempting a humble > crack at all this P2P stuff that I really don't master. So please > forgive my utter ignorance on the subject and give me harsh but solid, > constructive comments so I can initiate a little black book with all > that is said and all the resources that I have to investigate to give > more knowledge and talk less crap. > > What I've figured out until now is: > 1 - Server will have the responsibility to allocate the entries for > the first sphere. During this time I think I can be safe in the wild. > Even if my jugular is still completely open. > 2 - a) After first sphere is allocated server will delegate > allocations to next sphere north/south pole. Spheres have to maintain > poles, rearranging if need be. > 2 - b) Server maintains list of poles' IPs with free spheres and > passes it in the bootstrap procedure. > 2 - c) Community tells me I'm an idiot and gives me more fail safe idea. > 3 - Use some other network to scan for nodes and use that for > bootstrap, or community tells me that I'm an idiot, again, and gives > me a better idea. > 4 - At some time in the future I envisage that the central server will > no longer be the centralized jugular since, if only one node is in > your bootstrap list you can reconnect to the grid. Or: this is too > naive, community kicks my but and tells me to smell the coffee. > > > > > -david > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:p2p-hackers- > > > [EMAIL PROTECTED] On Behalf Of Gustavo Carreno > > > Sent: Sunday, September 09, 2007 1:39 PM > > > To: P2P-Hackers > > > Subject: [p2p-hackers] New protocol idea > > > > > > Hey guys, > > > > > > First of all the disclaimer: > > > I'm a programmer, not a P2P programmer, just a simple day2day > programmer. > > > I'm a complete ignorant about NAT traversal and all of the UDP > schemes. > > > I've always been interested in P2P but never had real time to > > > investigate all the theory behind all the DHT and etc. > > > > > > My proposal: > > > Imagine a sphere, and a point that is the center of the sphere. > > > The point that is the centre of the sphere will be address 0,0,0. The > > > bootstrap server. > > > The sphere will be the first level of clients. > > > Every client will have an address of <level>, <x-axis>, <y-axis>. > > > There are 8 parallels and 8 meridians. > > > Clients on the poles link to the next sphere(level). > > > Searches are executed counter-clock wise on a parallel and upon > > > returning to the same client go up one meridian. Special cases are the > > > poles that send the search one level and invert the search order. > > > The bootstrap server decides addresses from equator to poles, first up > > > and then down. Once all positions are filled the north pole point > > > takes care of address assignment (still needs some thinking not sure > > > if it works if one client has already a known client somewhere in the > > > crowd). > > > > > > What has made me think about this 3D scenario is easy routing once you > > > know the opposite node you want to send message. It also has every > > > client connected to 4 other clients, excluding poles and server. > > > > > > Please insert all the rest of the needs of a P2P network and if it > fits or > > > not. > > > > > > Please do not be condescendant and hit me real hard with your views. > > > > > > Thanks > > > Gustavo Carreno > > > --- http://batxman.wordpress.com > > > < If you know Red Hat you know Red Hat, > > > If you know Slackware you know Linux > > > > _______________________________________________ > > > p2p-hackers mailing list > > > [email protected] > > > http://lists.zooko.com/mailman/listinfo/p2p-hackers > > > > _______________________________________________ > > p2p-hackers mailing list > > [email protected] > > http://lists.zooko.com/mailman/listinfo/p2p-hackers > > > > > -- > Gustavo Carreno > --- http://batxman.wordpress.com > < If you know Red Hat you know Red Hat, > If you know Slackware you know Linux > > _______________________________________________ > p2p-hackers mailing list > [email protected] > http://lists.zooko.com/mailman/listinfo/p2p-hackers _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
