[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sks-devel] Re: [Fwd: Re: Alternative to round-robin (was Re: pool.s
Re: [Sks-devel] Re: [Fwd: Re: Alternative to round-robin (was Re: pool.sks-keyservers.net having trouble?)]
Fri, 03 Sep 2010 16:14:54 +0200
Thunderbird 22.214.171.124 (X11/20080305)
-----BEGIN PGP SIGNED MESSAGE-----
John Marshall wrote, On 09/03/2010 11:24 AM:
> On Thu, 26 Aug 2010, 23:48 +0200, Kristian Fiskerstrand wrote:
>> That said, it is still a very simplistic approach by timing the
>> connection speed (in seconds) and doing a weight = (int)(1/responsetime
>> * 100). After this I have manually overwritten the weight of the local
>> keyserver (keys.kfwebs.net) to 200.
>> I have added the weights into the table at
>> At this point, what is the preferred approach?
>> 1) keep the weights as they are
>> 2) group them into intervals / steps in order to get some additional
>> load balancing
> Unless I'm missing something, it looks like we've transformed the global
> pool.sks-keyservers.net pool into a regional European pool. Do we want
> the whole world using only the European servers? From
> http://sks-keyservers.net/overview-of-pools.php it is apparent that both
> host and SRV DNS queries for pool.sks-keyservers.net will result in the
> same set of servers (with the SRV queries including the additional
> priority and weighting data). How useful is this Europe-centric
> response-time weighting for a global set of servers being used by global
> clients? The pool currently gives me (in Australia) a list of 10
> European servers - all with ICMP round-trip times of between 320ms and
> 520ms. Unless RTT is taken into account in the response weighting, I
> can't see any value in using response time to weight selection of
> servers for a global pool.
> If we would prefer that clients use servers running more recent versions
> of SKS, we could reflect that preference usefully in SRV records - but
> perhaps using the priority field rather than the weight field. But
> then, we could just as easily exclude older SKS servers from the pool.
> Just some food for thought. Thanks to Kristian for all the work he does
> maintaining this pool.
I agree with your reasoning, so I moved the added features into a new
european centric pool eu.pool.sks-keyservers.net. (
and_pgpkey-http._tcp.eu.pool.sks-keyservers.net ) and reverted
pool.sks-keyservers.net to the prior mechanism (random).
Audaces fortuna iuvat
Fortune favors the brave
This email was digitally signed using the OpenPGP
standard. If you want to read more about this, visit:
Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
-----END PGP SIGNATURE-----