On Apr 21, 2011, at 12:38 AM, Gabor Kiss wrote: >> Are there any recommendations for the number of peers each keyserver >> should have in the membership file? > > Not yet. :-) > > In theory an optimal value could be computed but there are > too many parameters (e.g. network delay and bandwidth, > probability of hardware errors, average length of outages, > cpu power, number of new keys "produced" by each node etc.) > Moreover some of them are subjective preferences > (e.g. the estimated cost of your CPU time and networks BW, > the required availability etc.) > > So all of us have some idea about how many peers are the best. > Some guys want to be connected to everybody else. > I think 5-10 peer is more than enough. > > (I guess a wild debate will start now... :-) >
Well one does need a stricter definition of "optimum" that what was asked: "current" as in up to date. Any model with "current" as "optimum" definition needs as many peers as possible the more the merrier. There are some simple heuristics that reaches "optimum" up-to-date as staying green at http://sks-keyservers.net/status/ that will accomodate outages etc. Check occaisionally and if you go red, add another peer. There are other definitions for "optimum" such as minimal propagation latency across all peers, or minimum distance to all other nodes. Almost certainly someone has modeled gossip protocols, lemme dig a bit. The minimum distance is likely computable simply from collecting a snapshot of existing peers and then computing maximum path length for each node to all other nodes, and comparing your node with others. Minimum latency would require a simulation perhaps, using a model with parameters derived from an existing log file to get the parametrs about right. 73 de Jeff
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel