Greg Troxel writes: > Removal of introducer; presumably each client has to be configured > with all servers; I'm not sure this is a win.
True. However, since the server is resilient against a variety of server policies, you can handle this in any number of ways. Examples: * Anonymous registration for clients on my subnet * Paid registration via web app; service gains reliability by having one server (or family of servers) be front-ends for a vast array of additional replicated servers on the backend * Anonymous registration with quotas * Pseudonymous registration with some new in-band protocol message types RegistrationRequest and RegistrationResponse (pretty sure I'm going to need these) > You don't explain how you're dealing with repair, leases and garbage > collection, or why you don't need them. Same thing: servers can do whatever they want for garbage collection: * Quotas * Delete rarely-requested segments * For clients and servers that trust each other and want to be tightly integrated, the server could know the directory descriptors and thus could compute what segments are no longer used Repair is performed by the client, asynchronously, as described in a previous email: "Hey, have I saved all my segments to all my servers? Oh, good. Say, while I'm prefetching for performance, I think I'll do it randomly across the set of servers and see how they are all doing. Is that old guy still up and serving my segments?" -- http://noncombatant.org/ _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
