Re: [Sks-devel] De-peering (temp) very stale peers

[Jason Harris]

On Wed, Feb 13, 2013 at 01:06:40AM -0500, Phil Pennock wrote:

> Does anyone have any figures for the load caused by significant
> differences in the numbers of keys had by two keyservers and how quickly
> SKS stops being able to cope efficiently?

> A couple of my peers are >100K keys behind, so I've temporarily

Figuring out the differences in the working set happens quickly enough.
But then your server will spin its wheels grabbing all those 100k keys
by their old hashes and parsing every last one just to find that there
are no new packets in there.

Your peer will be pulling those same keys, via their newer hashes,
in blocks of 100 keys (default setting).  If your server and the
communications to your peer are fast, that will minimize the non-
multitasking time SKS spends grabbing the keys and transmitting them.
An HTTP proxy will let "sks db" get back to work sooner, instead of
blocking until it finishes transmitting the data to the peer.

> de-peered from them and let them know, and I'll happily re-peer once
> they get their problems fixed, but I'm not 100% sure I'm not
> overreacting; I just recall the significant problems had a couple of
> years back with one peer.

When running multiple servers, I often restart "sks recon" on the updated
peer after the outdated one has gotten the hashes and started pulling the
updated keys.  This prevents a lot of wasted work for the updated server.

> I'm pondering if I should find time to rig up a system to automatically
> disable peers more than N keys behind.

You could tail+grep your recon log, regenerate your membership file, and
restart "sks recon" without disrupting your normal key serving by "sks db."

Or, just block the bad peer via automated firewall rules (and regenerate
your membership file).

-- 
Jason Harris           |  PGP:  This _is_ PGP-signed, isn't it?
address@hidden _|_ Got photons? (TM), (C) 2004

pgptk_fgl0FxI.pgp
Description: PGP signature