Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!sun-barr!newstop!exodus!noam.Eng.Sun.COM!jyl
From: jyl@noam.Eng.Sun.COM (Jacob Levy)
Newsgroups: comp.sys.isis
Subject: Re: Process groups as network-level objects
Message-ID: <12521@exodus.Eng.Sun.COM>
Date: 30 Apr 91 16:49:56 GMT
References: <1991Apr29.205624.17754@aero.org>
Sender: news@exodus.Eng.Sun.COM
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 76

Russell

Robert Cooper at Cornell has been working on this issue and I
have also spent some time thinking about it. Robert has done an
initial implementation of his ideas - I'll defer to him to
describe what he has obtained so far. Here is what I've been
thinking about:

Similar to your reasoning, I also think of ISIS pgs as network
objects. There is a problem of efficiency, however. The PG
mechanism does not scale well as the number of pgs grows into
thousands. Specifically, the problem is located in the pg view
update code. Consider a process which is member of several
thousand pgs. When such a process fails, several thousand
invocations of the pg view update protocol will be run. This is a
globally synchronous (abcast) type protocol. Clearly the cost
would be prohibitive.

The solution which Robert came up with and which I embellish here
is that each process is member of several (a fixed number) of
ISIS pgs. Networked objects are mapped onto these fixed pgs and
used as a kind of "lightweight" pg. A "name service" manages the
lightweight pg namespace. As you suggest, it is important that
consistency among processes participating in a lightweight pg be
enforced so that each process indeed implements that network
object abstraction. To achieve this, we have processes register
with the name service the types of network objects they are able
to implement. The name service creates heavyweight pgs from those
processes implementing each network object, and maps network
objects to the appropriate "type" of heavyweight pg.

A lightweight pg (serving as a network object) thus consists of
the following information:

struct lightweight_pg {
	/*
	 * Where in the heavyweight pg name space is the object?
	 */
	address		heavyweight_pg;
	/*
	 * A token to identify the lightweight pg
	 */
	char		*name;
};

The problem with this solution is that it is still not scalable,
due to the presence of the name service. In order to make it
scalable, we must allow a name service to store names managed by
other name services. Thus, we store, in the lightweigth pg
structure an additional address, that of the heavyweight pg
which provides the namespace management for this network object:

struct lightweight_pg {
	address		heavyweight_pg;
	char		*name;
	address		namespace_manager;
};

The advantages are:

a. The namespace manager is the natural place to implement
   replication, persistence, storage, activation, deactivation
   etc. policies. 
b. The namespace manager can be used as a transparent fallback if
   communication with the heavyweight pg hosting the object is
   lost. The namespace server could then reactivate the object in
   another heavyweight pg.
c. Namespace managers can store names managed by other namespace
   managers. This provides scalability and allows the construction 
   of a general graph of name spaces.
d. We can hide the notion of heavyweight pgs entirely beneath
   this layer.
  
Does all this sound familiar?

--JYL