Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!lll-winken!uwm.edu!cs.utexas.edu!rice!uw-beaver!cornell!ken
From: ken@gvax.cs.cornell.edu (Ken Birman)
Newsgroups: comp.sys.isis
Subject: Re: ISIS "homework" problem
Message-ID: <35282@cornell.UUCP>
Date: 18 Dec 89 15:02:28 GMT
Sender: nobody@cornell.UUCP
Reply-To: ken@cs.cornell.edu (Ken Birman)
Distribution: comp
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 47

Well, with the holiday season approaching, I think we can wrap up
phase one of our "YP redesign" project.

The initial goal seems to be to build a small-scale module for
storing the YP database.  It needs to support an internal interface
with a lookup/update/delete ability.  Data can be assumed to consist of
tuples like ("isis","udp","1234") with multiple such tuples in each
of a set of "files" (like "/yp/etc/services").  If it helps, you can
initially assume that everything fits in memory; later the service will
need to work off of disk files.  Details of the tuple matching rules
and content rules can be deduced from the YP documentation if necessary.

Having built this, we'll want to extend it to support the sort of
import/export mechanisms that I proposed earlier; the effect will be
to let us build a large-scale YP service with individual data items
(tuples) living on some primary set of 2 or 3 servers, but available
everywhere.

I think this extension raises some interesting problems at the level
of the "ISIS architecture" to use -- e.g. how groups notify one
another about their desire to import/ability to export chunks of 
data.  I suggest that we pick up this topic in January sometime.

The last step of the implementation will be to hook this together with
the new long-haul facility so that our YP program can span multiple LAN's
running different versions of ISIS. 

When I have time (not soon, since I am trying to get ISIS V2.0 into a
distributable form now). I plan to throw together the basic triple-replicated
YP module.  Hopefully, a few of you will too...  My plan is to
benchmark this under ISIS V2.0 in late January and to post the code
in that timeframe; if we have a few competing designs, perhaps we can
compare and contrast...

Ken

PS: This first stage is trivial, in case you haven't noticed.  It
resembles the replication example in the ISIS Manual so closely that
you can practically type it in right from there.  I suggest that you
use a token-based replicated update scheme, with any server in the TMR
set satisfying read requests locally; to do a write you request the token
for the "file" in which the tuple resides, then CBCAST the update in
a simple message that all receipients interpret in parallel.

Actually, there is a minutely faster protocol that combines the token
request message with the update message, but we can worry about that
some other time...