Re: [Sks-devel] Mass drop from pool

[Matthew Palmer]

On Tue, Apr 19, 2011 at 01:32:11PM +0200, Kristian Fiskerstrand wrote:
> Matthew Palmer wrote, On 04/19/2011 10:42 AM:
> > 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).
> 
> I'll look into some other way to handle this, but it comes down to a
> balancing act of complexity vs usability. In any case I don't have too
> much free time to look at it atm.

Are the scripts publically available?  There's no reason you necessarily
have to write this yourself; I've got plenty of free time.

> > 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.
> 
> You could try to make sense of
> http://storage.sks-keyservers.net/map.png :) It is generated using
> graphviz, so if you want the original .dot file to try to make it more
> usable, feel free to let me know.

I wasn't thinking of manually working out the "strong set"; rather, using
more script to calculate it (or at least warn of any servers that are in the
pool but don't appear to be able to easily and quickly gossip their new keys
to others).

- Matt

-- 
"Need? What does -need- have to do with it? I'm talking about pure,
unadulterated lust here."
        -- James Campbell Andrew, in the Monastery, hopefully talking about
                computer hardware