-----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:pgp-public-k...@gingerbear.net?subject=HELP
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-----
_______________________________________________
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
