laubach@aspen.IAG.HP.COM (Mark Laubach) (02/03/90)
I am thinking of extending ISIS V2.0 to support ISIS client applications running on workstations where the ISIS system itself is not up; such "children" would connect to ISIS at a "mother" machine. I believe that on a standard UNIX system, ISIS could probably support 50 or 100 such children without much trouble. The children would have transparent access to all ISIS facilities and could receive fast bypass multicasts in the normal way, but would depend on their connection to the mother machine for all of these features. Questions: do you know of applications where this would be useful? What sort of child hardware should be be thinking of (PC's under OS/2? Apple's?) Can I count on UDP messaging? TCP/IP? Is it vital that ISIS switch transparently from one mother machine to another if the first one fails, or is this getting too fancy? This would be a great idea. That way, we could also possible have participating non-UNIX OS implementations, like MS-DOS. Also, on diskless clusters, it would be easier to maintain having one ISIS mother per filesystem server (cluster server) to reduce the administrative overhead of running on each client CPU. This would be fairly easy for me to do for child "UNIX" systems, harder for non-UNIX systems (because the clib code does a few UNIX system calls). What we do depends on the feedback we get... DOS environments would be very useful to have integrated into this. My hope is to include something along these lines into the March beta release of ISIS V2.0. Looking forward to V2.0. Mark
ken@gvax.cs.cornell.edu (Ken Birman) (02/12/90)
(Ken -- I am sending this by mail since all my attempts to post to
comp.sys.isis failed. Feel free to repost it to the newsgroup.)
I think this is a great idea. Not all sites want to run ISIS.
Here is an example situation where the feature you propose would
be very useful. I am building a distributed language on top of
ISIS, and this will make it much easier to make my language
implementation widely available. The situation I am thinking
about has any number of low-powered workstations talking to each
other in my distributed programming language environment. Running
ISIS on each station would be unacceptable since this would at
the very least cause the workstations to swap (through the net,
oy!). Also, this is a way to get much larger configurations right
now, even without waiting for ISIS to mature past the 128 site
limitation.
As an aside, I do not think that building a distributed language
on top of ISIS would strain its communication capabilities too
much, since all messages are fully asynchronous and can thus be
batched into big chunks. If I understood correctly from previous
discussions in the newsgroup, the time transmission cost of a
message is linear in its size and the factor is not very large.
Regarding progress, I expect to have a demo version of my system
by June or July. If everything works out OK, I plan to place it
in the public domain, so other ISIS users could certainly get a copy.
Cheers,
--Jacob
[KB: I see no reason that a language like this couldn't run well on ]
[ISIS V2.0; in fact, it might have the advantage of being able to ]
[plan to generate code that will respect the limitations on "bypass"]
[communication (basically, multicasting primarily within groups) and]
[hence give naive users a substantial performance benefit... ]
[At any rate, V2.0 will definitely support remote (unix) clients. ]