abbott@aero.org (Russell J. Abbott) (03/09/91)
I just read that the Carnot project at MCC plans to offer virtual synchrony (plus a whole lot more). If virtual synchrony becomes one of the more-or-less "standard" features that distributed systems begin to provide, where will ISIS focus its future efforts?
ken@gvax.cs.cornell.edu (Ken Birman) (03/09/91)
In article <1991Mar8.163555.1321@aero.org> abbott@aero.org (Russell J. Abbott) writes: >I just read that the Carnot project at MCC plans to offer virtual >synchrony (plus a whole lot more). If virtual synchrony becomes one of >the more-or-less "standard" features that distributed systems begin to >provide, where will ISIS focus its future efforts? An answer in 3 parts: 1) I have never heard of the Carnot project and so can't comment on this. Are they implementing the mechanisms themselves? I would be very interesting in seeing the details. There is at least one MCC group that actually uses ISIS in their work. Maybe this is that group? 2) We would like our next ISIS system (the one we are designing and building now) to be a component of the various distributed systems that are likely to be important in the next few years. To this end: - We have been working with the Chorus people on an extension to make the Chorus port-group mechanism virtually synchronous. - We are working closely with the Mach project on adding virtually synchronous port-groups to Mach+Xkernel - We are continuing to talk to OSF about our stuff... - We are starting to talk to UI about our stuff... - We are talking to a number of major hardware vendors about our commercial plans. So far, this is mostly talk. However, our new system design and implementation is well underway. The best outcome from my point of view would be that all these groups just buy into ISIS. I would like to see standards for process group mechanisms in UNIX-like systems, and I think that our new ISIS architecture could be a very solid basis for such standards. We have much more experience than any other group in this area, and we are making the development of the new architecture as "open" a process as possible. As an aside, ISIS was not easy to develop, and our publically available source is a mixture of old public domain code (pre V1.3) and a lot of more recent code subject to a fairly restrictive copyright. So, any group proposing to build a virtually synchronous toolkit has a fair amount of work cut out for themselves, and they won't be able to use much of our recent code (not without our written permission, at any rate). However, we built one and are building another, and I am sure that there are at least a dozen distributed systems groups world-wide fully capable of doing the same. So, perhaps some real competition will emerge in the next few years. Generally speaking, this would be good... keeps us all honest... and, my group has probably missed a number of deep insights or clever tricks that other groups can contribute, and we all benefit when that happens. 3) The focus of our future efforts are: - Near term: getting our new lightweight stuff running as solidly and as close to the hardware performance limits as possible, and re-working the toolkit with a focus on awkward aspects like the C++ interface and the way in which the architecture specification is presented (i.e., incorporating ideas from projects like ANSA) - Longer term: we've been thinking about this. We'll tell you when we get there... (after all, if we are going to be imitated, we want the credit, and you get the credit by getting there 2 years before the competition!) Ken
ken@gvax.cs.cornell.edu (Ken Birman) (03/13/91)
In article <1991Mar8.163555.1321@aero.org> abbott@aero.org (Russell J. Abbott) writes: >I just read that the Carnot project at MCC plans to offer virtual >synchrony (plus a whole lot more). If virtual synchrony becomes one of >the more-or-less "standard" features that distributed systems begin to >provide, where will ISIS focus its future efforts? With a lead-in like this, I couldn't resist getting in touch with the Carnot people.... It turns out that Carnot is more along the lines of Tuxedo or the system that Transarc is building: a "database integration" environment. The idea is to build one big database system out of lots of pre-existing, heterogeneous components. ISIS, on the other hand, uses a non- transactional approach and although our system is usable for database integration (especially now that standard external "commit" modules have become more common), most ISIS users are concerned with building fault-tolerant services, or with a general problem of distributed systems architecture, or with controlling/managing subsystems of some sort. Of course, ISIS is about gluing components together to make a big system and so is Carnot, so the projects do seem to share some aspects of their architecture. This is why their project summary sounds like it could be a system directly aimed at typical ISIS applications. In fact, however, what they are doing is very much in a transactional model and not particularly aimed at process group programming, whereas ISIS is aimed at process group programming and has "token" support for transactions, at least so far. Virtual synchrony in Carnot is also a little different than in ISIS. For us, this is very much a process-group property, combining synchronization, fault-tolerance and causality properties, and with an emphasis on asynchronous interactions. Carnot doesn't seem to have a process group model per-se, although it apparently can support several aspects of what ISIS does. From what they sent me, it appears that the system doesn't have anything comparable to virtually synchronous addressing, and the model is not fault-tolerant in the sense of the ISIS model. What they do provide is more of an ordered multicast primitive, like abcast, and in fact while they call the system "virtually" synchronous, I would have used the term "closely" synchronous. They implement this model over the network Linda system: a broadcast is done by creating a tuple containing the data, and a recipient uses "rd" to pull messages in in the order they were issued. The scheme was developed by Chris Tomlinson (tomlic@mcc.com). The head of the project is Phil Cannata: 512-338-3376 (cannata@mcc.com). I hope I haven't gotten all this wrong -- I'm substantially compressing the information they were able to send me, and I may have missed a key point. If you really need to learn about this, please contact them and take anything written above with a grain of salt. -- Ken Kenneth P. Birman E-mail: ken@cs.cornell.edu 4105 Upson Hall, Dept. of Computer Science TEL: 607 255-9199 (office) Cornell University 607 257-6195 (home) Ithaca, New York 14853 (USA) FAX: 607 255-4428