From: ken@cs.cornell.edu (Ken Birman)
Newsgroups: comp.sys.isis
Subject: Re: Process group addresses, DCE etc.
Date: 2 Sep 92 16:27:39 GMT
Organization: Cornell Univ. CS Dept, Ithaca NY 14853

In article <barry.715390460@citr.uq.oz.au> barry@citr.uq.oz.au (Barry Kitson) writes:
>Hi,
>
>	Do all clients of a process group have the same address
>for the group?  What I don't understand yet, is how virtual synchrony
>is implemented, and what protocols operate between which objects.
>How is ordering controlled in bcasts and who is responsible for
>controlling it?

Isis implements protocols and a model described in two ACM TOCS papers,
one in August 1991 and one in June 1987.  A prior ACM SIGOPS paper, also
in 1987, describes the toolkit and the overall approach -- although TR1216
will eventually be published and does a better job than the original 1987
paper, I think.

To answer your questions, though: yes, all processes in the system that
do a pg_lookup on a group (within the same LAN) get the same internal
ISIS "address" back.  ISIS knows how to expand an address into the
current membership of the group, but this information is only stored
and updated at the members of the group, so anyone who isn't a member
gets data that could be stale by the time it arrives.  We have a whole
bunch of protocols engineered for different communication patterns and
ordering properties, and you should read the papers if this interests you.
Note, however, that the new ISIS system will actually be implemented
entirely over cbcast and a type of "flushed" cbcast that achieves
the properties of gbcast.  This is discussed in a TR by me, Cooper and
Gleeson (isis publications list appended).  So, we don't really need
a complex implementation, it turns out, to support a very flexible
protocol suite.

Isis is totally decentralized, although some protocols do pass tokens
around that allow the holder to do some distinguished thing, like
ordering two concurrent events.  But, when we do this, the token is
automatically regenerated in the event of system reconfigurations.

I think that the more I say on this the more confusing it will get,
short of pointing you again to the detailed model and discussion in
the journal articles, which were written to be precise.

>>No, we leave this to the OSF and UI Atlas people... Sounds like you need
>>DCE; then you can ask "can ISIS be used within DCE" and we can reply "sure".
>>(This is no problem...)
>
>	How do Isis and DCE fit together?  Do you make use of DCE RPC's for
>secure communications?  Does Isis use DCE threads?  (I don't know much about
>how DCE offers all these services to applications programmers, so don't assume
>too much.)

The fit is pretty much one of "non-inteference".  ISIS programs in
a DCE environment would use the POSIX threads package, aka pthreads,
which ISIS already supports when compiled for MACH.  (Actually, we might
need to edit some include files a little once we get ahold of a real
DCE distribution, but this will not be a problem).  The isis routines
would then be running concurrently with your "normal" DCE application.

RPC would be into your application, through DCE RPC, but the various
ISIS primitives could all be called -- so you basically just get both
worlds at the same time.  Since DCE has encyption facilities, you could
invoke these primitives to encrypt data sent in ISIS messages...

ISIS itself doesn't use DCE directly, except for the threads package.
In fact, we can use any of a half-dozen threads packages, but our model
is pretty much the pthreads one, so DCE is a particularly close match.

By the way, we are working closely with OSF's Research Institute on
adding ISIS functionality to OSF 1/AD.  When this is done, we plan to
have a look at how that functionality might be used within systems
like DCE.  (We aren't particularly biased towards OSF -- we are
also working with everyone else!)

Ken
-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
Newsgroups: comp.sys.isis