ken@gvax.cs.cornell.edu (Ken Birman) (01/06/91)
If you've been following this news group, you will be aware that we have started a redesign effort that will lead to a complete rewrite of ISIS. We are finding it hard to keep extending the original system, which is getting a bit complicated and "hacked" as it keeps being adapted to solve problems for which it wasn't originally designed. Also, realistically, the day when someone proposes a standards effort in this area can't be too far off. We want to arrive at a carefully thought-out specification that we can live with for a long time, and a compliant implementation, sometime before this occurs. Finally, there have been a lot of research developments here and elsewhere that ISIS doesn't take full advantage of. We are hoping to simplify the system substantially while also doing a better job in areas like: C++ and OO programming support Very reactive process group subset mechanisms, i.e. "subset of the members of some group with minimal load". (This would tie in with the Meta toolkit) Realtime protocols and support for various priority mechanisms Transparent fault-tolerance mechanisms under systems like Mach, Chorus (i.e. replace a Mach/Chorus task/actor with a fault-tolerant one that a caller can treat identically to the original one, using standard Mach/Chorus system calls, etc). Persistent data (transactions) Group mechanisms for use in large parallel processors (i.e. we need a way to exploit multi-threaded architectures and physical concurrency) Exploiting special communication devices It would also be nice to get away from some of the ISIS-specific mechanisms where standards are emerging, i.e. for threads, "port-based" communication, message and RPC stub generation, etc. I've had a few inquiries about this in email. The questions run in two basic directions. One direction is concerned with extending ISIS in some direction; these tend to be from people who would like to have a chance to participate in our design process, if possible. The other type of inquiry expresses concern about whether we are aware that people have developed some fairly large software systems over the existing ISIS interfaces and will need a clear migration path and a lot of warning to take advantage of this new activity. We have settled into the following plan. Over the next few months, we are going to be developing a "process group specification" document, in cooperating with ISIS Distributed Systems and various other organizations. This specification will be a full definition of the system architecture and interfaces for the new, ISIS system, from the programmer interface level down to the level at which messages are transmitted. We believe we can come up with simpler but more powerful interfaces, while still preserving the functionality of the current system. In parallel with this, we plan to start implementing the new system. I think the result can be quite a bit smaller than the current ISIS implementation. However, while I think the specification effort can probably be wrapped up by the end of the summer, it may be a lot longer before we have a useful system running (useful to anyone except us, at any rate). While we do not feel compelled to be 100% upward compatible, we are very concerned about minimizing the disruption when moving to the new system; after all, we have developed many large ISIS applications ourselves, and want to keep them running. A lot of thought will be going into keeping the migration path as simple as possible, and s whenever possible, we want to preserve the current system interfaces. Our specification document should serve as an early reference against which it will be possible to plan. If possible, we also plan to support a version of the interface over ISIS V3.0 so that developers can begin to code against the specification. Once we have a draft of the specification document, we will be circulating it for comments. If you would like to get directly involved in this "reinvention" of ISIS, drop me a note. Depending on the level of interest, we'll would certainly consider setting up a mailing list or even posting discussions of the various issues to this newsgroup on a regular basis. However, we will only do this if I get a fairly strong expression of interest in response to this posting. We will have a technical report out later this month discussing some of the key ideas behind the new architecture. The other document that has stimulated a lot of our thinking is Pat Stephenson's thesis on Fast Causal Multicast; his work explores many of the issues in the Cornell technical report on this subject (same title; currently be revised for publication). Pat's thesis will be available as a technical report too. We'll continue to post announcements of these papers as they appear.
ken@gvax.cs.cornell.edu (Ken Birman) (01/25/91)
Two weeks ago I posted a summary of our ISIS re-design plans and indicated that I would be willing to set up an email distribution list or post to comp.sys.isis to keep people in the loop, if interest was strong enough. I've seen relatively little interest in either plan. As things stand, we'll post announcements as documents become available but the active design discussions will probably be local to Cornell. Ken