Matthew Dillon wrote:
One big issue still needs to be resolved, and that is how to figure out an optimal physical route from point A to point C without having to go through point B, where point B is the registration node used as a rendezvous for A and C. It is always possible for A to issue a cluster-wide broadcast to 'forge' a route to C, or vise-versa, and we will probably implement things this way initially (and always have it available for emergencies), but it would not scale as the cluster grows despite the fairly rough granularity in the resources being advertised (e.g. filesystems rather then files).
Hey, that's exacly my area of interest! So maybe I can contribute a bit to the design... What do you mean with "optimal physical route"? There are multiple metrics I could imagine: 1. shortest hop 2. maximize minimum bandwidth 3. lowest latency 4. node/link availability of the routing nodes for efficiently designing the routing overlay, we also should have an estimate of the maximum number of nodes joining one cluster. are we talking 100, 1000 or 1000000? there are a number of possible self-structuring methods (preferably incremental, dynamic) to produce an effective mesh. also, should we optimize on writer vs readers, or are all nodes considered writers and readers? oooh, that sounds exciting :) cheers simon -- Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
signature.asc
Description: OpenPGP digital signature
