sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] Mass drop from pool


From: Matthew Palmer
Subject: Re: [Sks-devel] Mass drop from pool
Date: Tue, 19 Apr 2011 18:42:51 +1000
User-agent: Mutt/1.5.20 (2009-06-14)

On Tue, Apr 19, 2011 at 09:10:43AM +0200, Gabor Kiss wrote:
> > Just noticed virtually all of us have dropped from the pool for having >500
> > missing keys. Not sure what is going on but have restarted my processes in

Wow, I'm still in the pool.  I'm a bit surprised at that.  Still no
appreciable load on the server, which is nice.

> Kristian,
> Could you modify the selection algorithm? E.g. if number of pool
> members drops below 50% of normal level the check should be
> done once an hour instead of once a day.

I would recommend making the algorithm less tied to one particular peer
(which, after all, should have no reason for being in any way special from
the point of view of clients), and instead use a statistic across the pool;
something like "any peer which is more than N standard deviations from the
mean number of keys across all candidate servers gets dropped".  (N could be
fractional, if appropriate).

This method should handle almost all possible failure situations; to cover
the case where the key counts are grouped either side of the mean, a safety
net of "if the pool would include less than X% of candidate servers, repeat
analysis with 2*N, 3*N, etc, until at least X% of keyservers are included". 
This makes sure that nobody gets blasted if the worst happens -- I think
it's better that in the event of failure, users occasionally hit servers
that are a bit short on keys than hit a couple of servers that are all
overloaded and near-dead.  (This same safety net could be applied to the
current selection algorithm, too, and I think would be better than making
the check run more often).

While we're on the topic, is there any analysis of "well-connectedness" in
the keyserver pool?  That is, if a server was only gossiping with one peer,
perhaps even on the end of a long chain (say A<->B<->C<->D<->rest of pool),
is there anything to deprioritise it or otherwise get it out of the pool? 
Especially if any of B/C/D are out of the pool or go offline...  that could
suck.

- Matt



reply via email to

[Prev in Thread] Current Thread [Next in Thread]