Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!ken
From: ken@gvax.cs.cornell.edu (Ken Birman)
Newsgroups: comp.sys.isis
Subject: Re: New ISIS spool facility -- comments?
Message-ID: <30419@cornell.UUCP>
Date: 27 Jul 89 16:22:20 GMT
Sender: nobody@cornell.UUCP
Reply-To: ken@cs.cornell.edu (Ken Birman)
Followup-To: <30369@cornell.UUCP>
Distribution: comp
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 43


>> From jlevy@arisia.xerox.com Thu Jul 27 11:51:01 1989
>> ....

>> Have I understood correctly that this in effect makes it possible
>> for two independent networks of ISIS-connected sites to
>> communicate? This means that in effect the limitation on the
>> number of sites is removed?

Yes, the new spooler/long-haul facility is intended to help
you link "clusters" of ISIS sites over long-haul links.  The idea
is that if you are running ISIS at Cornell and ISIS at Xerox,
you might want to build applications that span the two LAN's.
ISIS doesn't normally allow this, but the spool mechanism offers
a way to cobble something together explicity.

Basically, you spool messages for the remote LAN (currently
you need to use the SP_NETWORK option, but eventually we will move
to a new group naming convension like
	/cardiology/ccu/bed11/alarm@columbia.new-york
where "new-york" would be taken as the network name).  ISIS
needs to know how to talk to "new-york", and you tell it by
means of the spooler's interlan configuration file - which
lists some machine in new-york and ports that they use to
do this type of communication.  Whenever it gets the change, 
ISIS makes a connection and forwards the spool using a scheme that
gives at most once delivery semantics.  As long as the line is up,
overhead is low -- your message goes to the spooler, out the line,
into the spooler remotely, and is re-broadcast on arrival.

Because the scheme is completely asynchronous, you would have to
layer any sort of reply mechanism on top of this as part of your
application.  There were technical obstacles to doing something
reasonable with replies as part of our mechanism -- basically,
failure cases that made it very hard to recover lost replies.

We recognize that the initial facility is pretty primitive.
Messac Makpangou is working on this and would be interested in
feedback or suggestions.  Contact him as mak@cs.cornell.edu.
He is working on extending the long-haul code, specifically, while
I am responsible for the spooling/replay mechanisms.

Ken Birman