dalia@SHUM.HUJI.AC.IL (Dalia Malki) (06/17/91)
In article <22820@ogicse.ogi.edu> rogere@ogicse.ogi.edu (Roger Ellingson) writes: > Agreed! We have just completed a graduate level distributed systems course here > at OGI. Using ISIS for class project programming support has been > a real boon for student implementation of distributed algorithms. > (Comment: Until one tries to implement their own ordered communication support, > they might not appreciate how much benefit ISIS is!) We have also been using ISIS as a teaching aid in the graduate distributed-algorithms course here, at the Hebrew University of Jeruesalem. We found it easy and convenient to use; the programs submitted by the students were exceptionally READABLE, as the "event-driven" structure of the ISIS interface forced them to program modularly. The internal protocols and the virtual synchrony concepts, as described in the many (good) publications and technical-reports from Cornell, provided a wonderful background material for teaching in class and for semi-theoretical exercises. I included below a description of an ISIS-project given as assignment in this course, which might be of interest to others. In the project, the students write a network conference-talk utility (the idea in not new). The assignment we gave was for two-weeks (!), and proved an interesting exercise in distributed computing. Many of the problems become apparent only when the students start working on it, e.g. atomicity of the manipulations on groups. >I would be happy to see more debate in this newsgroup, for example about >how abcast should work when groups overlay (should multicasts to different >groups be ordered in the overlap region, or is this unecessary)... Well, a while ago, in articles <dalia.674044526@shum> dalia@SHUM.HUJI.AC.IL (Dalia Malki), <dalia.674405035@shum> dalia@SHUM.HUJI.AC.IL (Dalia Malki), I prompted for a debate on a related subject: the need for CBCAST in overlaying groups. I received some interesting replies, some of which I am still discussing with the senders. Before I summarise - would other people care to respond ? - Dalia Malki ------------------------------------------------------------ E-mail: dalia@humus.huji.ac.il Dalia Malki Computer Science dept., The Hebrew University of Jerusalem, Givat Ram, Jerusalem 91904 Israel ------------------------------------------------------------ Distributed CHAT Facility General ------- The ISIS system provides various communication services for distri- buted applications. ISIS supports dynamic communication groups and pro- vides atomic broadcast operations among processes within the group. Various degrees of ordering features are supported: causality order --------- ----- (CBCAST), global order (ABCAST) and extra-global order (GBCAST). ISIS ------ ----- ----- ------ ----- is responsibile for promptly notifying member processes of any change within their membership group (notification of changes also preserves messages order throughout the system). We use these facilities to maintain global information by an abstraction called synchronous replicated data. This abstraction refers ----------- ---------- ---- to the fact that data is kept replicated, and all replicas are con- sistent. This is done without assigning a centralized server for main- taining the replicas, but in a completely distributed manner by all parts of the application. All the processes follow the same sequence of changes; the order of changes is preserved in all the processes by the broadcast-order property. In this project the application uses a synchronous replicated name server for maintaining user conference groups. Usage ----- chat <user@machine> Request to join a conference group with the specified user. This call starts the group if it doesn't exist already. ~m <user@machine> Merge with the specified user's conference group ~c Make this group a confidential group. Description ----------- The distributed chat facility enables users to communicate in a conference-communication fashion from different machines in the network. Every conference group is implemented via an ISIS communication group. Within each conference group, all members see all the messages (a mes- sage is an input line), preceded by the sender's name, as in: Msg from Dalia: "hello world!" At any time, any user from any machine in the network may connect to the conference group by requesting to chat with one of its members. In this case, the user receives the group-name of the conference from any of the chatting members and joins the group. All the members of the group receive a message on their terminal notifying them of the new member. Leaving a group is done by simply giving the EOF (CTRL-D) signal. A group is started (created) by the first member who requests to chat with a non-chatting user, as in: chat foo@bar The initiating member is then the only member of the group until foo@bar (or anyone else) issues a chat command back (terminal protection prob- lems prevent us from writing a request-chat message on foo's terminal). Note that if foo is already chatting in another conference group, the above chat command will be simply a request to join that group. Since foo has no special role, it can be the requesting user itself. Additional Operations ---------- ---------- In addition to chatting data, the chat program recognizes several special administration commands. For convenience, they are preceded by the `~' (wigly) character. These commands allow the merging of groups, blocking of groups for secret conferences, etc. A special merge command joins two conference groups into one. The union of all the members of these groups constitutes the members of the new group. The merge command can be issued by any member of any group, by naming a member in another group: ~m kuku@muku A conference group may decide that the contents of its conversation are becoming ``touchy'' and require secrecy by giving the `~c' command (by any member). After this command, new users will be blocked from joining this conference group and from merging it with another group. In this state, the confidence group must guard against non-monitored listeners who may discover the group's name by some means and join it without premission. They must not receive a single line of the confiden- tial conversation!