Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!uwm.edu!cs.utexas.edu!think!gem.mps.ohio-state.edu!rpi!batcomputer!cornell!ken
From: ken@gvax.cs.cornell.edu (Ken Birman)
Newsgroups: comp.sys.isis
Subject: ISIS "homework" problem...
Message-ID: <34173@cornell.UUCP>
Date: 13 Nov 89 18:51:36 GMT
Sender: nobody@cornell.UUCP
Reply-To: ken@cs.cornell.edu (Ken Birman)
Distribution: comp
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 35

A while ago I proposed to post interesting problems to the news group
from time to time as a way for people to start thinking about how to
use the system to build useful application software.

In this spirit, I propose that we design a YP server replacement.
Ideally, I hope that people will post contributions, but you can also
email thoughts to me anonymously or just follow the discussion silently.

YP defines a fairly specific, standardized interface using SUN RPC
as its facility for talking to clients.  We won't want to change that.
The idea is to use ISIS internally to the YP server to (hopefully)
come up with a version that propagates updates a bit faster than the
standard version and is a bit more robust when crashes occur.

Lets also plan for the future.  The YP server we design should be one
suitable for scaling to fairly large systems.

Any systems design problem starts at the architecture level.  So,
the first question we need to consider is what an appropriate architecture
would be for such a scalable YP application.  The second issue, somewhat
down the road, will be how to implement it without too much code.

I hope that this exercise will culminate with an ISIS "YP server" in
the system utilities or demos area -- ideally one that is vastly better
than the current YP package because of the clever we we built it.

If a few people go as far as to implement the server, it should be
interesting to compare solutions.

So, to start with, I suggest that readers interested in following
this dialog read about YP:
	man ypclnt ypfiles ypserver

Question 1: is the YP server as defined by SUN suitable for use in a
larger-scale high availability setting?