Newsgroups: comp.sys.isis
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!news
From: rcbc@cs.cornell.edu (Robert Cooper)
Subject: Re: Process groups as network-level objects
In-Reply-To: abbott@aero.org (Russell J. Abbott)
Message-ID: <1991Apr30.133100.3535@cs.cornell.edu>
Sender: news@cs.cornell.edu (USENET news user)
Nntp-Posting-Host: honir.cs.cornell.edu
Reply-To: rcbc@cs.cornell.edu (Robert Cooper)
Organization: Cornell University Computer Science Department
References: <1991Apr29.205624.17754@aero.org>
Date: Tue, 30 Apr 1991 13:31:00 GMT
Lines: 61

In article <1991Apr29.205624.17754@aero.org>, abbott@aero (Russell J. Abbott) writes:

>With the preceding in mind, I would also recommend that ISIS do more to
>enforce (or at least strongly recommend) consistency among processes
>within process groups so that a process group will (unless explicitly
>defined otherwise by a user) consist of processes that implement
>network-level objects.  I imagine, though, that the issue of
>intra-process group consistency is one that the ISIS group must have
>debated.  I wonder why you made the decision not to go in that
>direction.
>
>-- Russ Abbott@itro3.aero.org

Russ has some good points. I've always thought that Isis programs were a
bit prone to errors of inconsistency between group members. E.g. where one
group member joins the group specifying PG_LOGGED (to enable logging for
total resiliency) but another member neglects to do so. Another example is
where an entry must be called using abcast to ensure correct semantics of
the application.

One idea we've been bouncing around for a while without actually
implementing it is the following:

(1) Entry numbers are on a per-group basis. Currently entry numbers
a global, or at least process-wide, rather like RPC procedure numbers.
Instead, entry numbers would be unique only within a group. Among other
things this would make management and allocation of entry numbers easier
for programmers. There would continue to be a process-wide entry numbers
for compatability purposes though.

(2) Associated with a group entry number would be some attributes,
including "Ordering" which would specify ABCAST or CBCAST (or either I
suppose). Other attributes would include something I call "Extent" which
says how many group members the bcast should be sent to (e.g. all,
majority, one), and "Replies" which says how many replies should received
before considering the bcast to have succeeded (e.g. all, one etc.).

(3) Groups would also have attributes specifying options such as 
PG_LOGGED that are currently specified as arguments to the group join
operation. Other attributes come to mind, such as a minimal and optimal
number of group members.

These attributes would be enforced as follows:

Group attributes would be defined by the first process to join the group,
in its arguments to the pg_join operation. Also there would be
an isis_group_entry routine that would take a list of entry attributes.
These group and entry attributes would be bundled up into a piece of group
state that would be transferred to other group members as they join. If
those members violated these attributes, i.e. they specified incompatible
arguments to their own pg_join and isis_group_entry operations, then they
would be prevented from completing their join to the group. 

These group and entry attributes would perhaps be specified in some group
interface language. However, the above proposal does not rely on any
one interface language, leaving us free to fit in with different interface
languages. One example language is the IDL language developed by 
ANSA/ISA project in Cambridge England. Currently we have a visitor at our
group from that project, so you may see some activity in this area.

                         -- Robert Cooper