I think I can hit on a couple of these... "After a little research I can't seem to find anything that indicates if Bonjour can scale to thousands or tens of thousands of peers. I was wondering if any one has any experience or knows of any research on the topic."
It doesn't scale, and it's not designed to. Zeroconf [1], a lot of which came out of work previously done for appletalk networking (Apple stupidly branded the standard Rendezvous and then after getting sued over a name conflict, got to love the irony, to Bonjour), is composed of three main things, dynamic address assignment for getting onto a network when you don't have a DHCP server available (which is really just a pointer to an existing RFC [2]), multicast-DNS for local network naming, and DNS-SD for doing service discovery. The beauty of them all is in the simplicity: * For address assignment you chose a random IP in a certain range, and then do an arp probe to make sure someone else isn't using it before becoming active. These addresses are only good on the local LAN though, they are not routable. * mDNS is used for local naming and service discovery. For naming, machines can just give themselves a name in the .local domain and advertise on a local broadcast address. So if your laptop is named foobar you would be accessible by "ssh foobar.local". * Service discovery sits on mDNS, and lets you issue local broadcast queries that try to find network services. It uses the existing DNS protocols, but just sets up a nice little convention for finding services based on the protocol they use. To find IPP compatible printers on the network you do a DNS query for "_ipp._tcp.local", or if you have a fancy app running the zipzap protocol over udp you would query for other clients by looking up "_zipzap._udp.local" The DNS-SD stuff could work to query any domain if the services are registered with a dns server for the domain, or the requests are all forwarded to the right subnet(s), but I've never heard of this actually being done. "Look into OpenDHT" A DHT doesn't work for service discovery. It's solving a different problem. In service discovery you want to find all the nodes who offer a given service, where in a DHT you want to find one node which has a specific object that hashes to a single value. This can be augmented to have pools or whatever, but fundamentally it's a different primitive. This is why something like SWIM "Indeed, I think mDNS + dynamic DNS is the recipe for a really interesting, completely decentralized naming system that works seamlessly both on and off the internet:" Dynamic DNS still requires all the DNS infrastructure because whoever you are using for your dynamic DNS service has to be registered with the regular DNS system, otherwise you have a bootstrap problem. In effect all it does is shift your dependency onto a single node in the DNS tree so you can quickly update your IP rather than having to wait for the typical DNS record propagation delay. "Anyway, the more I learn about DNS, the more I like it. It's one of the few systems that is truly decentralized at not only a technical infrastructure level, but also the legal/political level." Uh, you sure about that? DNS is extremely centralized both technically and politically. ICANN [3] is responsible for managing the whole thing, and it is a hierarchical system that relies very much on the root name servers and the name servers for the top level domains (TLDs). Records are mirrored all over the place, but this is definitely a centralized architecture. "The names can be resolved using mDNS or standard DNS, and local peers can respond with the names of remote peers, so it looks like a pretty good fit for a gossip-based membership protocol." That's not a bad idea, having local peers respond also with remote peer info they know about. Although if you are already speaking a custom protocol to share other information (latency, bandwidth, geo-id or whatever), then you might as well just do a local lookup and find out the rest with your gossip scheme. Right? Distributed naming and distributed service discovery are two different beasts. If the names are globally unique you can just use a DHT. For non unique names as long as you don't expect many conflicts you could probably do something on top of a standard DHT to handle pools, conflicts etc. For service discovery it gets much messier. Depending on how many nodes you expect to be running a given service, it could mean on the order of N. This means you are really just sampling for subsets of nodes. I don't know of anything better then a gossip protocol for that kind of thing if you need global knowledge. (Gossip is really just a more scalable version of flooding, which trades way higher latency for dramatic bandwidth savings.) If checking a subset is enough, then a random walk or some kind of smart (probabilistic) flood are the two strategies I know of for doing efficient network sampling that are tunable depending on your sample-size/bandwidth constraints. I think the best solution is to find ways to partition the nodes so that you aren't gossiping between N, but just subsets of N who are likely to care about each other. Basically build a set of loosely connected gossip networks. I think this is one of the most interesting topics in P2P today. Hell, it is the primary value in P2P for most apps I can think of. Once you learn about nodes you can just talk directly for all intents and purposes (especially if and when IPV6 is pervasive so we aren't wasting our time with NAT issues), so learning about remote clients is really THE benefit of P2P networking. (Well, there are plenty of other cool things that can be done, like reputation systems, streaming, but I'm guessing that various forms of lookup will be the primary use of P2P for a long time.) Peace, Jeff [1] http://www.zeroconf.org/ [2] http://tools.ietf.org/html/rfc3927 [3] http://www.icann.org/ On 6/16/07, Chaz. <[EMAIL PROTECTED]> wrote:
Right now I have a p2p application that uses a proprietary membership protocol. This protocol has been shown to scale to thousands of peers. I was thinking of changing over to something like Bonjour. After a little research I can't seem to find anything that indicates if Bonjour can scale to thousands or tens of thousands of peers. I was wondering if any one has any experience or knows of any research on the topic. Thanks and regards, Chaz. _______________________________________________ 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
