glade@sjofn.cs.cornell.edu (Bradford Glade) (10/11/90)
We recently received some concerns from Peter Wang and his user group about the ISIS news facility along with their solution to those problems. These concerns are well founded and we thought that this would be a good opportunity to discuss a new version of the news facility that was motivated in part by these limitations and in part by advances made in the ISIS protocols for large group communication. First some background on the ISIS news facility. The ISIS news facility behaves similar to a bulletin board. Messages can be posted to subjects maintained by the news service. Processes that post these messages can be thought of as reporters (or posters). Processes that are interested in these subjects can then register themselves with the news service. These processes are called subscribers. This facility thus provides a mechanism for message permanence in a distributed system. A process can come up, post a message to a news subject, and depart. A second process can then, at some later time, come in and read this message. Thus the news service is a mechanism for keeping messages around in the system while application processes come and go. While processes are registered to a news subject they will receive messages posted to this subject until they cancel their subscription. The ordering of these messages obeys the ISIS broadcast delivery semantics used to post them; reporters can post messages using either causal or atomic ordering semantics. Let me now describe the current services available in the news facility, I'll the describe Peter's concerns with them, then go on to describe the design changes that we are making to the news facility for ISIS V3.0. We would love to have your comments on these design changes and would also like to hear how you are using the ISIS news facility, and what services you would like to see available. Please, feel free to post here or send me mail. The ISIS V2.1 News service (and earlier) provides the following functions: news_post(sitelist, subject, msg_p, back); news_posta(sitelist, subject, msg_p, back); These routines are used to post a message to the news servers on the machines listed in the sitelist. The back parameter is an integer that controls how the message is deleted by the news service. The message will be removed after the next back messages have been posted to the same subject. news_subscribe(subject, entry, nback); This routine is used to subscribe to the subject, the isis entry (task) entry will be invoked whenever a message is sent to the subject. The nback parameter tells the news service to send the previous nback messages of the subject (if available) to the subscriber. news_clear(slist, subject); This routine is used by a poster (reporter) to clear out (delete) from the news service all messages sent by this process to this subject. news_clear_all(slist, subject); This routine is similar to the previous except that it deletes ALL messages in this subject from the news service. news_cancel(subject); This is called to cancel a subscription to the news service for the given subject. Peter's main concern was the behavior of the news facility when the subscriber list in the news service becomes full. Currently the subscriber list is implemented as a fixed size array and is thus subject to the limit imposed at compile time. In a typical situation one could simply recompile this limit to a high enough value for the application at hand. However, in the case of Peter's user group, the applications in development go through a period of testing in which a process will not necessarily cancel it's subscription to a news subject, for example the process is aborted before it gets a chance. The ISIS V2.1 and earlier version of News does not recognize that a client (subscriber) has failed and as such, these table entries can become filled with the addresses of dead processes. Peter's solution (which is available from me as a patch to news.c) was to create a special news group called "SUBJECT_LIST". Processes interested in the news service subscribe to this news group. When a subscriber fails to join a new news group because the list is full, the news service will delete the group, and send resubscribe notices to all members of the news group, via the entry for "SUBJECT_LIST". Upon receipt of such a message, the process, if it is still interested in the subject, should resubscribe to the news group. This way these useless slots become free, and the new subscriber is likely to successfully subscribe on a second try. While this solution has a few disadvantages, such as losing messages retained by the news service for that news group, and making applications responsible for resubscribing, it nonetheless is suitable in Peter's situation where messages are posted with a backlog value of 0 (no retained messages), and where his applications are willing to pay this price. We have addressed these needs, as well as other shortcomings, in a new ISIS news facility in the following ways: 1) The new ISIS News facility uses dynamic linked lists to maintain the list of subscribers. This means memory is being spent where it is used, and per site tuning of the news facility is no longer necessary. Limits are thus now based on the amount of traffic (i.e. diffusion group size) the broadcast facility can handle, rather than table sizes imposed by the news facility. 2) The news facility now monitors the death of subscribed process, and deletes their entries accordingly. So no dead entries exist. In addition to addressing Peter's immediate needs, the new facility also addresses the following: 1) News servers are no longer referred to by the sites where they reside, they now belong to a group called the "news_service" and are addressed as such. Thus the news service is resilient to failures of the sites where the news service resides. News servers can come and go at any time, replicated state is maintained consistently between them. 2) The news service takes advantage of the new, efficient, broadcast protocols being developed for ISIS, in particular it uses the diffusion groups that Ken has talked about in the past, and the underlying fast multicast transport protocols. 3) Greater control is given over message expiration. Messages can be tagged by the poster, and later expired by any process with the proper message tag. The backlog semantics are also retained for backwards compatibility and they can be used or not as desired. 4) Greater control is given over message delivery. Subscribers can register with a subject with a list of interests. These interests describe a list of keywords that the subscriber is interested in. When a reporter posts a message it can specify a list of keywords that the message is relevant to. The special keyword "all" indicates that the message should go to all subscribers of the newsgroup regardless of their interests. If a subscriber uses the keyword "all" as an interest, it indicates that it wants to receive all messages posted to the subject. The following routines form the proposed new interface to ISIS News. They are designed to make the transformation of old code under the old interface to the new interface easy, and yet provide the new interface in a clean way. void init_news_service() This routine installs a single news entry for receipt of all news messages, user routines are called transparently from this interface. This is called before isis_start_done. int news_post(subj, msg_p [, key, arg [, key, arg [, key, arg]]], 0) int news_apost(subj, msg_p [, key, arg [, key, arg [, key, arg]]], 0) These are similar to their old counterparts. Key corresponds to one of three values NEWS_MSG_BACKLOG, NEWS_MSG_TAG, NEWS_KEYWORDS, the argument following the key corresponds to the key value. For instance, the NEWS_KEYWORDS key should be followed by a char * containing the list of keywords relevant to the message. void news_expire(subj, tag) This function allows a process to expire a tagged message (or messages) from the given subject. int news_install_reporter(subj) This installs the process as a reporter to the subject. Processes should call this if they intend to post to the subject. This allows the process to benefit from the new fast multicast protocols. int news_remove_reporter(subj) This is the counterpart to the previous routine, and should be called when a process is no longer interested in posting. int news_subscribe(subj, routine, backlog, [NEWS_INTERESTS, interests,] 0) This routine registers a process with the news service as a subscriber. Subscribers can specify an optional list of interests that provides finer selection of messages within a subject. The backlog field acts as it does in the old interface. Notice that the routine takes the address of a user routine rather than an ISIS entry number. This saves on ISIS entry slots, and should simplify the initialization sequence of applications. int news_cancel(subj) This is analogous to the old routine. int news_add_interests(subj, interests) This routine allows a process to dynamically change the selection criteria for message filtering. int news_remove_interests(subj, interests) The counterpart to the previous routine. char *news_query_interests(subj) This allows the process to obtain the list of current interests held for it. void news_clear(subj) void news_clear_all(subj) These retain the same semantics as the old interface. The types of the arguments are as follows: char *subj; void (*routine)(msg_p); int backlog; message *msg_p; int key; char *interests; char *keywords; Again we would appreciate hearing about how you use the ISIS News facility, and what features you would like to see us support in the future. Feel free to post here or send me mail. -Brad. Bradford B. Glade | glade@cs.cornell.edu Dept. of Computer Science | Tel. (607) 255-2219 (Office) 4162 Upson Hall Cornell Univ. | Tel. (607) 539-6801 (Home) Ithaca, NY 14850 |