On Fri, Mar 09, 2007 at 10:05:57AM -0700, Damon Liwanu Mc Coy wrote: > > Yes this is a band-aid fix, and a better fix would be as Nick said > to have the directory servers ignore uptime and track stability. > > > Some of the issues with having the directory servers do this are: > (1) A set of rules as to how they measure stability needs to be > thought up. Proposed rule: "An authority should call a server Stable if its observed MTBF for the past month is at or above the median MTBF for Valid servers." MTBF shall be defined as the mean length of the Runs observed by a given directory authority. A Run begins when an authority decides that the server is Running, and ends when the authority decides that the server is not Running. In-progress runs are counted when measuring MTBF." This shouldn't be too hard to implement. > (2) The directory servers would need to retain more > state, so that when they are restarted they would remember all the > past stability information. Right; HD is pretty cheap, though, and I bet there's a nice incremental algorithm to maintain an estimate of MTBF as defined above without having to scan a server's complete history every time we want to generate a networkstatus. > (3) If a new authoritative directory > server is added how would they integrate into the network? That's mostly a separate issue; it only affects the Stable flag to the extent that a new authority would disagree with other authorities about which hosts are Stable. This disagreement is fine, since clients make decisions based on the majority opinions of the authorities. As long as new servers remain in a minority, they should be fine. (See dir-spec.txt and the in-progress 101-dir-voting.txt .) > (4) If > the directory servers became grossly out of sync could the clients > handle this? With respect to the Stable flag, yes; we can't get so out-of-sync that an odd number of voters don't reach a majority on a yes/no question. yrs, -- Nick Mathewson
Attachment:
pgpZZrfaQv4pK.pgp
Description: PGP signature