Path: utzoo!attcan!uunet!ns-mx!ceres!gem.mps.ohio-state.edu!rpi!batcomputer!cornell!ken
From: ken@gvax.cs.cornell.edu (Ken Birman)
Newsgroups: comp.sys.isis
Subject: ISIS YP SERVER REDESIGN
Message-ID: <34463@cornell.UUCP>
Date: 20 Nov 89 17:07:06 GMT
Sender: nobody@cornell.UUCP
Reply-To: ken@cs.cornell.edu (Ken Birman)
Distribution: comp
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 56

This posting is a followup on the yellow pages redesign "homework
problem" I posted 10 days ago.

Based on the comments I've seen and the two posting from readers on this
subject, there seems to be a consensus on a few issues:

1) The YP architecture as SUN designed it doesn't scale well, and people
   are seeing this as a problem.
2) Something capable of supporting faster updates is needed.

I see this as arguing for the following architecture:

The "YP service" should be hierarchical at several levels:

1) Multi-enterprise.  At this level the YP services for places like
   Cornell, MIT, IBM, DEC talk to each other.  It isn't clear what they
   would "export", but obviously this will be a small subset of what YP
   manages internally to each site.

2) Multi-LAN.  At this level, one envisions multiple smaller YP service
   groups concerned with providing services local to a small number of
   machines.    

3) Single YP server group.  Any given client is supposed to be "bound" to
   a particular YP server in the SUN architecture; rebinding is only done
   if that server crashes and restarts.  In our architecture we would
   want this server to be the main repository for information used almost
   exclusively by these clients, and to cache information imported from
   other YP server groups.

On the positive side, YP has a nice organization for the information it
manages -- I like the idea of saying that it works with what seem to be
"files" with a query interface on each file.  Some comments suggest that
other people see this as overly restrictive, but I need to understand
what alternatives are proposed...

So, getting concrete, we now want to design a YP server group with the
following characteristics:

1) It uses the YP protocols to talk to clients. 
2) There are normally 3 or 4 YP servers in a group; they maintain 
   some "part" of the global YP database.
3) The YP servers at the mult-LAN level know about each other and
   cache data for one another; jointly they have a location name like
   "cs.cornell.edu" that covers them as a set.
4) YP servers can interact at the mutli-enterprise level for queries that
   explicitly reference remote data, e.g.
		"/etc/services/isis/bcast@cs.cornell.edu"
   the default for a given client is to search within his local area...

Does this sound like a promising architecture?  What limitations do people
see if we pursue this?  Note that the idea is to extend the current YP
name interface to "hide" the locality of a reference in the name, so that
the current name structure won't need much redesign.

-- Ken