[cks-devl] Re: Sync thoughts (fwd)

[V Alex Brennen]

More of John's thoughts from July.

I'm much more interested in cleaning up all the segfaults
in the code and getting the code to a point where it can
be a stable replacement for pksd, than the advanced syncing
designed right now. I think the subkey support issue and
scalability issues with pksd are critical.  I need to get
cks_import and cks_backup written and get support for
keyrings.

Nevertheless, I want to mention that I talked with Werner
Koch and he suggested that there's was support for a binary
replacement for hkp - at the very least in gnupg. Syncing
mechanisms could be built in to that protocol.

For night now, I'm going to get the point to multipoint
code working (the current stuff)...  Then I agree the
mutlipoint to multipoint is the way to go - like the
Usenet and pksd records of servers transversed.  I
think we can most easily do that with comment lines
in the ASCII encoded keys.


        - VAB

---------- Forwarded message ----------
Date: Tue, 24 Jul 2001 13:56:49 -0500
From: John Goerzen <address@hidden>
To: V Alex Brennen <address@hidden>
Subject: Re: Sync thoughts

V Alex Brennen <address@hidden> writes:

>> 1. The sync code has no provision for dealing with servers that are
>> down.  It is an all or nothing thing -- if some servers are
>> unreachable at the moment, the key may not be synced to them
>
> yeah. this needs to be written.  We could extend the cks_other_servers
> table to include a down flag.  I was thinking I would just discard
> the record from the linked list built from cks_other_servers after
> x attempts and write something to the error log, that way the server
> is retried every night.  But perhaps the down flag is probably a
> better idea.

Another option is to extend the cks_pending_sync table such that each
key has a list of servers that it needs to be synced with (or perhaps
just one row for each key/server pair).  You could then iterate over
this list, with an ORDER BY of the server, sending each key and, if
successful, removing the key/server pair from the table.  If
unsuccessful, it remains.  Perhaps also an "entered on" date -- if
things still fail after eg 2 weeks, just delete them anyway.

> Every copy of cks should have a list of all other copies of
> cks running in the network...   Let me know if you have any

Brainstorming follows, grain of salt mode on...

That to me sounds like trouble.  While it's possible on a small scale
(say, a dozen hosts) it gets to be a problem when things grow.
pgp.net has sort of this problem already, I think sometimes.

I really like the way Usenet/NNTP works.  I'm not sure how familiar
you are with that but here's the basic idea.

There is a Path line in the header of each article.  When an article
is first posted (injected into Usenet), the Path line contains
(practically, at least) only one entry: the hostname of the machine
that the article was entered on.  As the article propogates through
the network, each new machine that receives it tacks on its hostname
to the Path line before saving or forwarding the article.  And,
whenever an article enters a system, it checks to see if its own
hostname is in the Path -- and if it is, discards the article on the
grounds that it has already been seen on that system.

This has the advantage in that it is topology-neutral.  It could be a
hub-and-spoke where there is one central host, or an
everyone-talks-to-everyone situation, or a chain (each host talks to
at most two others, and messages get relayed along).  In practice,
large networks have elements of each and this system lets it work well
with them all.

Another option is to add a last modified date to the data kept about
the key.  This date would have to be preserved across sync
operations.  This could be used instead of, or in addition to, the
Path idea -- each host would simply check to see if the incoming data
is newer than it already has, and if not, ignore it.

One other thing we need is a bootstrapping mechanism.  A keyserver
needs to be able to be welcomed to the network somehow.  Or if there's
a keyserver that had a dead disk and has been down for two weeks, it
needs to re-sync.  The last modified date could be handy.  The new or
formerly-dead keyserver could connect to a live node on the network
and say "Tell me what you have."  The live node responds with the
fingerprints and last modified dates of all its keys.  The dead one
can request whatever it needs to update itself.  (Or, the dead one can
send the live one its list and get a result pushed back to it;
whatever.)  As a consistency check, it would probably be wise to do
this sort of thing periodically anyway.

> better ideas.  A group experimented with multicasting.. but you
> need mbone access for that and multicast is inherently messy.

Yes, very.  I don't think that's a good idea either.

-- John

-- 
John Goerzen <address@hidden>                       www.complete.org
#include <std_disclaimer.h>  GnuPG key 0x8A1D9A1F from www.complete.org/key