NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/sys/isis/227

Text File | 1992-08-28 | 6.1 KB | 130 lines

Newsgroups: comp.sys.isis
Path: sparky!uunet!usc!rpi!batcomputer!cornell!ken
From: [e-mail] (Ken Birman)
Subject: Re: Clusters, sites and scope in Isis
Message-ID: <[e-mail]>
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
References: <[e-mail]>
Date: Fri, 28 Aug 1992 14:36:03 GMT
Lines: 119

In article <[e-mail]> [e-mail] (Barry Kitson) writes:
>Hi all,
>
>    Is it correct that an Isis cluster is a collection of
>sites with identical "sites" files (i.e. that share the same
>backbone)?

Right.

>    Since the name server is built into the backbone (right?),
>does this mean that process (group) names are relative to a cluster?

Yes, thats right.

>    How does the application programmer communicate between
>clusters and how are names specified?

You need to use the wide-area network support that we have built into
NEWS or the spooler/long-haul subsystem, the latter being at a lower
level then the former.  Warning: we have discovered that one of our
hackers introduced a number of problems into the spooler/WAN stuff
right before V3.0.6 went out, and if you need to use this in a serious
way you should contact us for a patch.  V3.0.7 will fix this, and in
fact we are planning to reimplement that part of ISIS for V3.0.7 or
V3.0.8, in order to improve performance and scaling.  (The interfaces
may be extended but we will continue to support the current ones).

>    What is "scope" as defined in the sites file?  (Warning --
>This could be a dumb question.)

Scope is an old notion that we no longer really support.  ISIS V2.1
had the "backbone" on every machine.  So, you could get situations
in which the ISIS name server was running on 100 sites.  Say that a
process does a pg_lookup on a name that it has never mentioned before.
Potentially, ISIS needs to search 100 sites for the location of the
group -- a costly search.  Actually, we do a little better (see below)
but not always.

Now, one could use various hashing schemes to fix this, but as time
went by we realized that most ISIS backbones would have a small number
of sites, because we were adding the BYPASS code even back when V2.1
was released.  So... in V1.3.1 we supported a notion of scope: if you
searched for group name "@a:name" we would confine the search to sites
that listed "a" in their scope list.  In V2.2/V3.0, however, we
eliminated scope completely.  For backwards compatibility we left
the scope file in the sites file, and so that this isn't a complete
waste we actually have a procedure to get the scope value for a site,
the idea being that you could put some architectural data in these
fields or something.  By now, the whole thing is basically vestigal,
though -- people put the equivalent of a comment in the scope part
of the sites file, and I doubt that anyone ever tries to query this
data.  And, if an old V1.3.1 program actually gets run, ISIS complains
about the notation @a:name, when it sees it used.

The key point is that with three or four machines in the backbone,
searching them for a group name is just not a big deal...

>    While I'm on a roll, I have a few other dumb questions:
>
>    If an RPC can't find an interface reference (or whatever
>Isis calls them) in the local cache, is a request made to all sites
>in the backbone, or just one of them?  If only one, will it usually
>have a copy of this info, or will it have to ask others?  (i.e. is
>this data replicated at each backbone site?)

Well, what we really do is this.  If the local backbone has an attached
process that belongs to the group ("interface reference") then we do an
RPC to the local backbone and get back the ISIS group address.

If this fails because the local backbone doesn't know the group, we
send the request to all sites.

This is for mapping from an ascii group name to an ISIS address, so
it doesn't happen a lot.

Now, if the request is a pg_getview -- e.g. we have the group address
and need to find out who is in the group -- the search is much
cheaper.  Group addresses contain the site at which the group was
first created, so we have a good hint for a place to check for a
copy of the membership.  We don't search the whole backbone unless
this pans out.

But, in the limit, we still end up doing an asynchronous multicast
to all sites, taking the first ``positive'' answer that comes back.

>
>    Are there any products which allow interworking of Isis with
>other similar systems?
>

There are no other similar *products*, yet.  There are some message
backplanes and there is an ISO MIB standard, and we do plan to support
the latter and could probably integrate ISIS with some of the former.
If someone needs this and would be ready to invest the necessary
resources, it shouldn't be hard to develop gateways.  But, in terms
of the overall notion of group programming, the only other systems
that exist are for research: V, Ameoba, TRANSIS, Psync -- and only
TRANSIS among these uses an ISIS-like process-group execution model.
But, TRANSIS is still an an academic research prototype stage (Danny
Dolev's group is developing it at Hebrew University in Israel).
Among the others in this list, Ameoba is the most active but
there are significant differences between the way that Ameoba groups
work and the way that ISIS groups work.

There are some products that are not similar, of course, such as
DecMessageQ, Teknekron's TIB, and perhaps even ToolTalk and NewWave.
But, the former two systems have a very different programming model --
nothing like the ISIS group-oriented tools.  And, the fault-tolerance
guarantees are different -- neither supports a strong ordering model
where independent programs are guaranteed to see things in a virtually
synchronous manner.  As for ToolTalk and NewWave, these both lack
support for fault-tolerant distributed programming or object groups,
and we are giving serious thought to integrating Isis with them.
But, so far, we haven't started to do anything about this.

--
Kenneth P. Birman                              E-mail:  [e-mail]
4105 Upson Hall, Dept. of Computer Science     TEL:     [phone] (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     [phone]