Re: [Sks-devel] 3 million keys & and community help requested

[John Clizbe]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1,SHA256

Jeffrey Johnson wrote:
> 
> On Nov 2, 2011, at 5:49 AM, Andrey Korobkov wrote:
> 
>> Is there any chances that SKS would be ported to some other, more common
>> databases like MySQL?
> 
> BDB isn't "uncommon" …

Pretty popular when used for specific applications. IIRC, OpenLDAP gets its best
performance with BDB as a datastore.

>> What is the reason behind choosing BDB as a storage?
> 
> Likely MySQL wasn't available or sufficiently portable when an implementation
> choice had to be made (2003? 2004? something like that). Disclaimer: I wasn't
> there, don't know, just guessing.

Close, the first mention of SKS was by Yaron, on the [pgp-keyserver-folk] list
on 26-Sep-2002, followed 8 hours later with

>> I think, having SKS work with client-server databases rather than
>> file-based could give it more scalability…
> 
> Your turn now: What benefit would there be using "common" implementation and
> a client-server architecture?
> 
> Scalability as in transactions/second isn't the important issue for SKS:
> gossiping and rapid synchronization and robust loosely-coupled availability
> are perhaps more important than what db implementation is/was chosen.

HUGE ACK

Quoting from Yaron's debut email:

> You might wonder why we need a new keyserver at all.  After all, the 
> existing keyservers do a pretty good job, and there are some actively 
> developed keyservers (namely CKS) that are getting better all the time. 
>   But SKS is meant to address one big weakness shared by all of the 
> existing PGP keyservers -- replication.  Current keyservers rely on a 
> not-terribly-reliable flooding-based approach.   Keys often fail to get 
> distributed everywhere, and the only current way to repair these 
> differences is to periodically exchange full database dumps.
> 
> SKS takes a very different approach to replication.  Instead of using 
> the kind of flooding approach adopted by PKS, SKS works by directly 
> comparing the databases and discovering and repairing whatever 
> differences are found.  SKS uses some newly developed algorithms for 
> making the comparison between databases extremely efficient.  In 
> particular, the cost of reconciling a pair of keyservers is proportional 
> to the number of keys that differ between them, rather than the size of 
> the overall database.  That means reconcilation is cheap enough to be 
> done often. By having hosts periodically reconcile with other randomly 
> selected hosts, updates are quickly "gossiped" throughout the system. 
> The resulting system is simple to administer, and the replication is 
> extremely robust.

IMHO, I don't see where client-server scalability would help at all.

Regards,

- -John

- -- 
John P. Clizbe                      Inet: John (a) GingerBear DAWT net
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
     mailto:address@hidden

Raise your hand if you know someone who is alive only because you
did not want to spend time in jail


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12-svn5502-2010-12-23 (Windows XP)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Comment: Be part of the £33† ECHELON -- Use Strong Encryption.
Comment: It's YOUR right - for the time being.
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOsY+cAAoJECMTMVxDW9A05foH/1ynQUvG4eE/isZA6dRlampU
XMoWk4KT8jz7asb06bo7NOEyQzsn+iLYuC8NvumgADp/1lc5a+D+PQqZtL6d4Yf6
aILnz35XwBaKGwaJXP/IVDJLXKvMqLwD7nd+GgJ/hhitN217Fp0Ppub4x4PvCE/2
MWqqV3A7LHsy7f6ZvfuENgc8GRA853tqTzkhQjz/pP42iREh9zhBCS0BvebQTGn3
FoRx4ryX2VPni4NLs/jQgXK3kKjOH9zFD/foRdJhdfexiUk4KeET+Q9jpLbbwsMD
Pc41uineyReCByax9BpyRr1w9hGlKMngdMM0DWdSa2lFat2kna12WLvsagHelNuI
XgQBEQgABgUCTrGPnAAKCRDrXhnz1laYJXZEAP0WSAOkd8UFmuG/RwDzRKtds2kp
fMtTCpLm1rtcge5CxAD/QnIcast+ERxYusojBecaBhMpuD9/+KrMY1n4jo3CrFw=
=B8TB
-----END PGP SIGNATURE-----