On 3/22/12 8:24 PM, Zooko Wilcox-O'Hearn wrote: > > I don't think so. Although, of course, I'm not entirely sure because > there are too many accounting designs. However, I don't think *any* of > Brian's accounting designs so far have been centralized, unless I'm > misunderstanding what you mean by that word. Could you please be more > specific?
We've designed a bunch of different stuff over the last 5 years, both in the AllMyData world and afterwards, so we've considered the gamut from centralized to decentralized. The variety of historical artifacts from these periods will paint a pretty confusing picture. I've pared down the complexity (and features) each year, hoping to get something (anything!) implemented, and then build back up to the features we thought we needed back then. My current plan is to start with the decentralized M*N form: each user (aka client, a person who wants to store files and the 'tahoe create-client' node they use to talk to the grid) has a separate relationship with each server (person who provides disk space, and the 'tahoe create-server' node they use to offer disk space to the grid). Clients have keypairs, servers have keypairs, they use the same one everywhere (so they could be correlated, once there exists something to do the correlation). Each server will tell the client how much space they're using. Later, the server can impose limits on that client. From the client's point of view, their grid-wide usage is the sum of what each server tells them, but they have to do that sum themselves. There's no central authority to enforce a global limit. There's also no central authority to tell all the storage servers about a new client: the first design is an "accept and report" scheme: servers accept any new client that connects. Later, we may add a mode in which the server rejects new clients by default, requiring the server admin to explicitly add new clients to a table somewhere. This would achieve better control of storage space, at the cost of requiring more work to get stuff started. For an AllMyData-like system, or indeed for a friendnet with more than maybe half a dozen people, that work becomes a drag (doing something to each server for every new client: M*N). The centralized components that we've dreamed up in the past would try to reduce that to M+N: some central box that gets storage authority on all servers, and then clients get acccess to the central box. My long-term vision is to have grid membership based on invitations, where anyone in the grid can invite new members, but everyone ends up knowing who invited them. Then collective gossip can provide information on each user's total consumption, which can then inform individual decisions about granting storage space. But if specific server nodes want to delegate control to some central space (e.g. Allmydata servers configured to just follow company policy), that should be an easy one-liner in tahoe.cfg. But, we've learned to start small. The first phase is just going to be distinguishing one client from another, and monitoring individual usage. Later, we'll add local controls over client usage. Then, once we've learned how people use those tools, we'll add the next step, whatever that ends up being. cheers, -Brian _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
