From wbell@CS.Cornell.EDU Wed Nov 28 21:22:16 2001 Received: from postoffice.mail.cornell.edu (postoffice.mail.cornell.edu [132.236.56.7]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fAT2MFT11463 for <egs@cs.cornell.edu>; Wed, 28 Nov 2001 21:22:15 -0500 (EST) Received: from [192.168.1.100] (syr-66-24-16-64.twcny.rr.com [66.24.16.64]) by postoffice.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id VAA28482 for <egs@cs.cornell.edu>; Wed, 28 Nov 2001 21:22:14 -0500 (EST) Subject: 615 PAPER #65 From: Walter Bell <wbell@CS.Cornell.EDU> To: egs@CS.Cornell.EDU Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.1+cvs.2001.11.07.16.47 (Preview Release) Date: 28 Nov 2001 21:21:52 -0500 Message-Id: <1007000535.2006.21.camel@brute> Mime-Version: 1.0 65) Herald: Achieving a Global Event Notification Service This paper discusses the desirable axes on which to build a global event notification service, where the scalability requirements force the ability for it to be deployed on the global Internet. They are concerned with fine grained message / event delivery for interactive activities such as instant messaging. They've taken the approach that like the Internet itself, any global event service must view the Internet as a set of mutually untrusting federations of machines, owned by separate entities. They also insist that the scale of node must be variable in that single nodes of one federation might be equivalent to thousands of nodes in another federation. This view really pushes the view that the goal is the unite several large federation services into one coherent service, versus starting from the ground up. With this view, it would be only necessary to implement gateways from current massive event services into the herald system in order to interoperate. Since the paper is light on details and is more a treatise on design issues in this space, it's only reasonable to inspect their decisions in the design space. My major problem was the disconnection of naming from this entire picture-- they seem to view naming as a completely isolated problem and provide a weak infrastructure for helping a naming service which would be necessary for herald. The fundamental naming problem involves one of distribution of information which is a portion of the problem they wish to solve. They seem to be taking a good view with respect to simplicity-- many of the other event services are very complicated especially with respect to guarantees; I have to believe that any successful global system must be simple with simple guarantees. The Internet has proven that time and time again. It's not clear about their view on soft state and event guarantees; it seems as if a more expressive construct might be required for more diverse applications. I find it very hard to believe that many applications would work reasonably in face of rendezvous points disappearing/forgetting their subscription information without notification. I think they've hit some points very well, but that time will show them they haven't quite captured what is necessary for scalability as well as a useful programming paradigm. From viran@csl.cornell.edu Wed Nov 28 23:02:52 2001 Received: from naismith.csl.cornell.edu (naismith.csl.cornell.edu [132.236.71.13]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fAT42qT28707 for <egs@cs.cornell.edu>; Wed, 28 Nov 2001 23:02:52 -0500 (EST) Received: from localhost (viran@localhost) by naismith.csl.cornell.edu (8.9.3/8.9.2) with ESMTP id XAA23237 for <egs@cs.cornell.edu>; Wed, 28 Nov 2001 23:02:47 -0500 (EST) (envelope-from viran@naismith.csl.cornell.edu) X-Authentication-Warning: naismith.csl.cornell.edu: viran owned process doing -bs Date: Wed, 28 Nov 2001 23:02:47 -0500 (EST) From: "Virantha N. Ekanayake" <viran@csl.cornell.edu> To: egs@CS.Cornell.EDU Subject: 615 Paper 65 Message-ID: <Pine.BSF.4.10.10111282300470.23230-100000@naismith.csl.cornell.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Slides at: <a href="http://www.csl.cornell.edu/~viran/herald.pdf> www.csl.cornell.edu/~viran/herald.pdf </a> <a href="http://www.csl.cornell.edu/~viran/herald.ps> www.csl.cornell.edu/~viran/herald.ps </a> From eyh5@ee.cornell.edu Wed Nov 28 23:30:29 2001 Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fAT4UST03488 for <egs@cs.cornell.edu>; Wed, 28 Nov 2001 23:30:28 -0500 (EST) Received: from photon.ece.cornell.edu (photon.ece.cornell.edu [128.84.81.138]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id fAT4RbM06559 for <egs@cs.cornell.edu>; Wed, 28 Nov 2001 23:27:37 -0500 Date: Wed, 28 Nov 2001 23:27:40 -0500 (EST) From: Edward Hua <eyh5@ece.cornell.edu> X-X-Sender: <eyh5@photon.ece.cornell.edu> To: <egs@CS.Cornell.EDU> Subject: 615 Paper # 65 Message-ID: <Pine.LNX.4.33.0111282326320.29056-100000@photon.ece.cornell.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Herald: Achieving a Global Event Notification Service Luis Felipe Cabrera, Michael B. Jones, Marvin Theimer This paper proposes Herald, a distributed system designed for event notification systems. Its targeted clients are those who subscribe to a certain service for access of information offered by that service. An example of an event-notification system is the MS Instant Messaging. Herald stands apart from other event-notification systems in that it is scalable to millions of users, a task previously achievable only in a centralized system. In fact, Herald is intended to expore the scalability issues involved in building a truly global event notification system with decentralized characteristics. The basic assumption in Herald is that any event notification system can be decomposed into a highly-scalable base layer that has relatively simple semantics and multiple higher-level layers. For this base model, Herald encompasses several functions, including hegerogeneous federation of machines, scalability, resilience, self-administration, etc. In the meantime, it avoids the inclusion of some higher-level functions such as naming, filtering, in-order delivery, and complex subscription queries. One of the core concerns for the researchers developing Herald is that it must be able to withstand network adversity with great tolerance. That is, Herald is presumed to operate in an adverse environment where nodes are mutually suspicious of each other's behavior, node failures are common, and the distributed state information is partial and incomplete. Herald attempts to overcome these adversities via means of service redundancy. The built-in redundancy is deployed to allow greater scalability and enhanced fault tlerance. Also, a time contract is imposed on maintaining the content of the service. This soft-state approach seeks to strike a balance between recycling precious disk space and accommodating the service. Although Herald is a distributed system, it does, according to the designs of its researchers, include an administrative Rendezvous Point that performs the function of notifying all interested parties changes occuring in the Rendezvous Points that house subscribed services. I do not understand why the Rendezvous Points themselves cannot communicate with each other and with service subscribers/publishers/creators about changes in the status of the Rendezvous Points. Employing an administrative Rendezvous Point may not be an efficient approach, and may very well become a bottleneck problem and a single point of failure. From ramasv@CS.Cornell.EDU Thu Nov 29 01:12:53 2001 Received: from exchange.cs.cornell.edu (exchange.cs.cornell.edu [128.84.97.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fAT6CrT20460 for <egs@popsrv.cs.cornell.edu>; Thu, 29 Nov 2001 01:12:53 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: cs615 PAPER 65 Date: Thu, 29 Nov 2001 01:12:44 -0500 Message-ID: <706871B20764CD449DB0E8E3D81C4D4301E7F29A@opus.cs.cornell.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: cs615 PAPER 65 Thread-Index: AcF4nNvneNw95w3tSLSA6PjvQLfWlQ== From: "Venu Ramasubramanian" <ramasv@CS.Cornell.EDU> To: "Emin Gun Sirer" <egs@CS.Cornell.EDU> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sundial.cs.cornell.edu id fAT6CrT20460 Herald: Achieving a Global Event Notification Service This paper describes the desing goals for herald that aims to create a internet scale event notification service. Their proncipal design feature is a rendezvous point that serves as the connection between multiple subscribers and publishers. Their world consists of several rendezvous points that could be created and destroyed by clients that act as subscribers or publishers . In turn for reasons of scalability and resilience each rendezvous point is replicated among several servers. One of the important design goal is to self organize this replication feature and provide scalable interaction among the replicated copies. The authors of this paper seems to favour the use of several thousand small overlay networks to achieve scalability. In their design each rendezvous point would consists of replicated servers at geographically distinct locations forming an overlay network while the system itself could consist of several thoudand rendezvous points. The impact of this architecture on the internet could however be drastic, significantly impairing the generally good functionality of the internet. However, the idea of self-organizing the replication process based on needs of load distribution and fault tolerance appears to be quite useful. From c.tavoularis@utoronto.ca Thu Nov 29 01:21:09 2001 Received: from bureau6.utcc.utoronto.ca (bureau6.utcc.utoronto.ca [128.100.132.16]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fAT6L8T21988 for <egs@cs.cornell.edu>; Thu, 29 Nov 2001 01:21:08 -0500 (EST) Received: from webmail2.ns.utoronto.ca ([128.100.132.25] EHLO webmail2.ns.utoronto.ca ident: IDENT-NOT-QUERIED [port 54544]) by bureau6.utcc.utoronto.ca with ESMTP id <239222-27436>; Thu, 29 Nov 2001 01:20:58 -0500 Received: by webmail2.ns.utoronto.ca id <24413-11979>; Thu, 29 Nov 2001 01:20:43 -0500 To: egs@CS.Cornell.EDU Subject: 615 PAPER 65 Message-ID: <1007014839.3c05d3b73b48e@webmail.utoronto.ca> Date: Thu, 29 Nov 2001 01:20:39 -0500 (EST) From: c.tavoularis@utoronto.ca MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT User-Agent: IMP/PHP IMAP webmail program 2.2.3 Herald is global event notification for distributed systems that can be employed by applications including instant messaging. It uses a federated approach, as opposed to centralized system, such that the defining task is interaction between peers. Herald is a simple system inspired by the Internet to allow scalability in terms of the number of users, the number publishable events, and the rate of event arrival. The gist is that publishers advertise data to a rendezvous point, and subscribers subscribe to the rendezvous points they are interested in. Rendezvous points are located on servers, and can change locations or even exist on multiple servers. Herald is in charge of creating rendezvous points, providing replication, and sending subscribers event notifications. Replication involves having copies of rendezvous points on more than one server. This provides fault-tolerance and load balancing, although all copies of data may not be complete. Information will expire after a time contract and publishers must explicitly refresh data. Herald uses an overlay network to forward information and unicast or reliable multicast can accomplish event notification. Redundant messaging by replicated rendezvous points must be avoided. This not dealt with in this paper, but I think it could be done via some kind of agreement between replications such that they are each responsible for a unique set of subscribers. Of course, this information would have to be maintained and it will reduce the efficiency of replication in the event of a network partition. Herald claims to support of heterogeneous federation, dynamic location of users, self-administration, timeliness and support for disconnections and partitions. The authors do not explain how they handle contradicting or incomplete information at different servers. Although correctness is not an explicit goal, it is possible that a subscriber could miss events over time and therefore Herald is only useful when events are not critical. Also, it would be useful for subscribers to be notified when they have been partitioned from the rest of the network. I think this paper is a work in progress and requires more detail. From papadp@ece.cornell.edu Thu Nov 29 03:35:10 2001 Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fAT8ZAT13198 for <egs@CS.Cornell.EDU>; Thu, 29 Nov 2001 03:35:10 -0500 (EST) Received: from kiki.ece.cornell.edu (kiki.ece.cornell.edu [128.84.83.13]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id fAT8WHM10131; Thu, 29 Nov 2001 03:32:17 -0500 Date: Thu, 29 Nov 2001 03:38:25 -0500 (EST) From: "Panagiotis (Panos) Papadimitratos" <papadp@ece.cornell.edu> To: Emin Gun Sirer <egs@CS.Cornell.EDU> cc: Panagiotis Papadimitratos <papadp@ece.cornell.edu> Subject: 615 PAPER 65 Message-ID: <Pine.GSO.4.05.10111290338060.6948-100000@kiki.ece.cornell.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Review of: "Herald: aChieving a Global Event Notification Service," by L.F. Cabrera, m.B.Jones, M. Theimer Panagiotis Papadimtratos papadp@ece.cornell.edu The authors present a hybrid of a position paper and a list of design directions and goals for a distributed, scalable event notification scheme. The basic concept that provides for the distribution of the system is the 'Rendez-vous point' (RVP) and differentiates this design from other centralized messaging/event notification services. In addition, simplicity, traded for guarantees on the notification delivery, is a major goal for the system that targets global deployment. Herald servers are to reside in numerous machines and publisher and subscriber client processes create and communicate throught the RVP's. Clients create RVP's, events are published and the RVP notifies the subcribed processes for corresponding newly published events. RVP's may be replicated and reside in different Herald machines in order to increase fault tolerance. Soft state is maintained in each RVP (i.e., state becomes obsolete unless explicitly updated) via 'time contracts' and the 'history' is proposed as a means to deal with periods of disconnection and loss of state. The extreme flexibility in the creation of RVP's and the absence of any naming scheme raises the issue of resource location; is this the reason for their proposing the use of agents as the a way to retrieve notifications (with administrative RVP's also dealing with changes)? The replication could indeed contribute to load balancing and thus scaling, but this would also require an explicit way for subscribers to switch from one replica to another, which is not straightforward at all, especially because processes that are assumed to act autonomously have to motivated to do so. Finally, the claim about 'mutually untrusted domains' recurs but apart from a generic statement about Access control policies to be employed (by herald servers? at RVP's?) there is no further explanation on how this parameter is taken into account in the design (or is it merely a re-phrasing of 'open, distributed system'?) From mh97@cornell.edu Thu Nov 29 10:52:32 2001 Received: from postoffice.mail.cornell.edu (postoffice.mail.cornell.edu [132.236.56.7]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fATFqWT01290 for <egs@cs.cornell.edu>; Thu, 29 Nov 2001 10:52:32 -0500 (EST) Received: from mars (syr-66-24-28-66.twcny.rr.com [66.24.28.66]) by postoffice.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id KAA20669 for <egs@cs.cornell.edu>; Thu, 29 Nov 2001 10:52:31 -0500 (EST) From: "hao ming" <mh97@cornell.edu> To: <egs@CS.Cornell.EDU> Subject: 615 PAPER 65 Date: Thu, 29 Nov 2001 10:52:20 -0500 Message-ID: <000701c178ed$d4703430$6901a8c0@mars> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Herald: Achieving a Global Event Notification Service BY Luis Felipe Cabrera this paper presents the design ideas of a global event notification system, hERALD, which can be the base of many currently popular distributed services such as instant messages. on contrast to the current centralized system, Herald consists of a bunch of federated servers cooperating with each other in a decentralized way which, the paper claims, can give it the scalability like the current internet. In my opinion, Herald is not a pure peer-to-peer system because of those federated servers. it is more like a multiple servers + clients architecture. the basic architecture of Herald is as follows: 1. system consists of three building blocks: publishers which generate events; clients which subscribe specific events; a Rendevzous point which is set up by clients and maintains subscription relationship between publishers and clients. events. 2. event publishers send events to corresponding rendezvous points which further send events to subscribing clients. Herald's main design goals are 1. scalability. 2. heterogeneous federation. 3. resilience 4 security 5. timliness 6. partitioned operation. 7. support of disconnection 8. self-administration. these ithink are basic requirement for a system like Herald. one interesting aspect is that Herald pushes many functionalities to hige layers such as naming service, filtering and in-order-delivery. then i am no sure the properties or goals of Herald can still be achieved when those services are added on top of it. in order to increase fault torlerance, assumption that nodes are not reliable is adopted. some compromises are also made to increase the scalability of systems like states are mainted in a soft-consistent way. the main design techniques are: 1. replication for scalability and fault torlerance. 2. overlay networks for multicasting. 3. time contracts are associated with replica states. 4. event history can be bound by time contract and server rejection. 5. administrative rendezvous points for uniform control messages exchange. the main contribution of this paper is combining existing techniques to create a new, globally scalable system. but this paper just discusses some design ptinciples. no results are presented. guess it is still in development. final comments: i doubt decentralized approach. as it is proved, centralized servers can support the traffic like that going through Yahoo.com. in fact, those servers usually consists of many computers, clusters. i do think they will have scalability problems. further, centralized approach is much easier to develop, much less overhead traffic and much easier maintainance. -ming From daehyun@csl.cornell.edu Thu Nov 29 11:43:49 2001 Received: from wilkes.csl.cornell.edu (wilkes.csl.cornell.edu [132.236.71.69]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fATGhnT10541 for <egs@cs.cornell.edu>; Thu, 29 Nov 2001 11:43:49 -0500 (EST) Received: (from daehyun@localhost) by wilkes.csl.cornell.edu (8.9.3/8.9.2) id LAA70227 for egs@cs.cornell.edu; Thu, 29 Nov 2001 11:43:44 -0500 (EST) (envelope-from daehyun) From: Daehyun Kim <daehyun@csl.cornell.edu> Message-Id: <200111291643.LAA70227@wilkes.csl.cornell.edu> Subject: 615 PAPER 65 To: egs@CS.Cornell.EDU Date: Thu, 29 Nov 2001 11:43:44 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit This paper presents Herald which is a highly scalable global event notification system. The main issue in designing Herald is scalability. Event notification systems are already used in many applications such as instant messenger and stock price tracking systems. But, conventional event notification systems are designed to be used in localized setting such as a building and a campus. With advent of generalized e-Commerce, global event notification systems are required which can be used in the internet-scale distributed applications. Herald is intended to transparently scale in all respects - the number of subscribers, publishers and events - and interconnect dynamically changing sets of clients and services. Herald has a simple model. Event is a set of data items provided at a particular point in time by a publisher for a set of subscribers. Each subscriver receives a private copy of the data item by means of a notification message. Herald does not interpret the contents of the event data. The operations sequence is as follows; 1) A Rendezvous Point is created by a client. 2) Clients subscribe the rendezvous point. 3) A client publishes an event to the rendezvous point. 4) Herald sends the subscribers the event. Herald adopts some ideas from the Internet and the Web. Herald assumes neither that component failure is unusual, nor that the states are global and always correct. Specifically, Herald makes the following decisions; First, Herald peers do not assume the correct behaviors of each other. Second, all distributed state is maintained in a weakly consistent soft-state manner and is aged. Third, All distributed state is incomplete and is often inaccurate. The above decisions help Herald be scalable and robust. I think the main contribution of this paper is that Herald extends conventional notification systems to a internet-scale global systems. I think its design decisions to achieve scalability are good. However, because this paper is very short and abridged, they didn't present specific descriptions. There might be a follow-up paper with more detailed explanations. From jcb35@cornell.edu Thu Nov 29 11:53:17 2001 Received: from travelers.mail.cornell.edu (travelers.mail.cornell.edu [132.236.56.13]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fATGrHT12496 for <egs@cs.cornell.edu>; Thu, 29 Nov 2001 11:53:17 -0500 (EST) Received: from travelers.mail.cornell.edu (travelers.mail.cornell.edu [132.236.56.13]) by travelers.mail.cornell.edu (8.9.3/8.9.3) with SMTP id LAA04997 for <egs@cs.cornell.edu>; Thu, 29 Nov 2001 11:53:14 -0500 (EST) From: jcb35@cornell.edu Date: Thu, 29 Nov 2001 11:53:14 -0500 (EST) X-Sender: jcb35@travelers.mail.cornell.edu To: egs@CS.Cornell.EDU Subject: 615 PAPER 65 Message-ID: <Pine.SOL.3.91.1011129113739.1085B-100000@travelers.mail.cornell.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This paper described herald which details the design of a global event notification service. In the Herald event frame, an event refers to a set of data items provided at a particular point in time by a publisher for a set of subscribers. Each subscriber wants to receive a notification message of particular events. Herald uses a Rendezvous point, where all event publications are sent and to which clients subscribe. With respect for scaling, when a rendezvous point starts causing too much traffic, herald will move some or all of the work for that point to another machine. I am not exactly clear how this will help in all cases, say when a lot of subscribers are listening for one popular event which occurs at many publishers - how do you pick and choose who to move, when moving any will cause some events to go unheard at some publishers? To improve herald's fault-tolerance, it will replicate some state (for example, who is subscribing to what and who is publishing what) at a few machines. Herald uses either unicast or local reliable multicast communications to send event notifications out, depending on which is available and more efficient. Herald proposes an sound method for providing global event notification, however I would think the naming mechanism would be key in any global event notification system. From ranveer@CS.Cornell.EDU Thu Nov 29 11:58:33 2001 Received: from exchange.cs.cornell.edu (exchange.cs.cornell.edu [128.84.97.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fATGwXT13487 for <egs@popsrv.cs.cornell.edu>; Thu, 29 Nov 2001 11:58:33 -0500 (EST) Subject: 615 PAPER 65 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Thu, 29 Nov 2001 11:58:33 -0500 content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <706871B20764CD449DB0E8E3D81C4D430232E6BD@opus.cs.cornell.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 615 PAPER 65 Thread-Index: AcF49xQuOK3wEHjCR7ium3e5GNvziw== From: "Ranveer Chandra" <ranveer@CS.Cornell.EDU> To: "Emin Gun Sirer" <egs@CS.Cornell.EDU> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sundial.cs.cornell.edu id fATGwXT13487 Herald: Achieving a Global Event Notification Service Cabrera, Jones, Theimer This paper looks into a new research topic: building a global event notification service. Commercial products for these applications use a centralized approach, with server farms implementing the central server to which all published events are sent. The centralized server then routes these event details to the subscribers. The main problem with these schemes is the scalability. Other problems include the absence of disconnected operation and the huge message overhead. Herald tries to build a global event notification service by targeting several goals: permitting heterogeneous clients, scalability, resilience, security, timeliness, and self-administration. Another key aspect of Herald is to relegate the implementation of stronger properties such as in network filtering and consistency to the higher layers. Therefore Herald aims to provide the Base layer on top of which several stronger protocols can be implemented. Herald uses a Rendezvous Point, which is similar to some of the multicast protocols that have been proposed for the internet(DVMRP). The Rendezvous Point is replicated to ensure scalability. Disconnected and partitioned operation is ensured by permitting a weak consistency among the replicas. A reliable multicast protocol is used to send the event notification to the subscribers. This federated approach as opposed to a centralized one is the research focus of Herald. There are a number of research issues that have been outlined and should provide a good guideline for building the targetted event notification system. The design of a scalable reliable multicast protocol is an area of current research. We know that SRM and RMTP do not scale beyong a few thousand of nodes. Probabilistic protocols give a better performance; however, it would depend on the scalability of the underlying multicast protocols, such as the MBone. The scalability of MBone to millions of users is unknown and would be interesting. From avneesh@csl.cornell.edu Thu Nov 29 12:39:09 2001 Received: from capricorn.ds.csl.cornell.edu (capricorn.csl.cornell.edu [132.236.71.92]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fATHd9T20484 for <egs@cs.cornell.edu>; Thu, 29 Nov 2001 12:39:09 -0500 (EST) content-class: urn:content-classes:message Subject: 615 Paper 65 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 29 Nov 2001 12:42:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <97C142C1212ED545B0023A177F5349C40A0A15@capricorn.ds.csl.cornell.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 615 Paper 65 Thread-Index: AcF4/S192b8QDVHfTeODk0GY1JDqjw== From: "Avneesh Bhatnagar" <avneesh@csl.cornell.edu> To: <egs@CS.Cornell.EDU> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sundial.cs.cornell.edu id fATHd9T20484 Herald: Achieving a global event notification service Summary/Critique: This paper presents a design overview of a global event notification system, which is aimed to be highly scalable spanning dynamically changin sets of clients and services. The main aim is to tolerate the uncertainity and lack of trust as exists in the internet. This is achieved through the design of a rendevous point, which co-ordinates event subscription and publishing for multiple clients. This rendevous point is replicated across several nodes to provide greater fault tolerance. In terms of performance goals, the paper attempts to provide a service targeting heterogeneous clients, robustness and security as well as self organization. The Herald design also chooses not to make naming a research criteria, this would be interesting to see, since naming becomes a considerable issue in the design of a system such as this. There are also some other salient points that might have to be considered: 1. Event notification: Although herald establishes the property of soft state maintanence and history mantainence, details of the event notification mechanism is lacking. There is the issue of asynchronous vs synchronous event notification to the clients. Under the synchronous case, the client has to be alive to receive corresponding events, but in the asynch case (which is required for scalalbility in any case), the rendevous point may need a pending event queue for clients which have to be notified. This raises subtle issues such as change in view of the system, which would require mantainence of this queue. Under a global notification service, this might not scale, which means that there are restictions on event notification guarantees. 2. Agent co-ordination for complex queries 3.Finally there was'nt much of a design description as to how and what security policies( if any) would be enforced. From teifel@csl.cornell.edu Thu Nov 29 12:45:26 2001 Received: from disney.csl.cornell.edu (disney.csl.cornell.edu [132.236.71.87]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fATHjPT21594 for <egs@cs.cornell.edu>; Thu, 29 Nov 2001 12:45:25 -0500 (EST) Received: from localhost (teifel@localhost) by disney.csl.cornell.edu (8.11.3/8.9.2) with ESMTP id fATHjKv49424 for <egs@cs.cornell.edu>; Thu, 29 Nov 2001 12:45:20 -0500 (EST) (envelope-from teifel@disney.csl.cornell.edu) X-Authentication-Warning: disney.csl.cornell.edu: teifel owned process doing -bs Date: Thu, 29 Nov 2001 12:45:20 -0500 (EST) From: "John R. Teifel" <teifel@csl.cornell.edu> To: <egs@CS.Cornell.EDU> Subject: 615 PAPER 65 Message-ID: <20011129110610.A38847-100000@disney.csl.cornell.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Herald: Herald is a highly scalable global event notification system at Microsoft Research. It is a scalable, distributed system that can handle arbitrary number of subscribers, publishers, event subscription points, and event delivery rates. It is fault-tolerant, avoids maintaining most globally consistent states and will scale to millions of users. Herald attempts to provide a distributed implementation for global event notification, which must be real-time. Current notification systems such as IM, chat, stock quotes, multi-player games use centralized systems to support the publish-subscribe information model. The authors do not believe that any centralized scheme can be a truly global solution, and that only a federated approach with multiple, mutually suspicious parties in different domains of trust that interoperate with each other is feasible on a global network. The interesting thing about this is that if Herald turns out to be a feasible global event notification service, it will diminish the importance of Microsoft's own MSN IM, etc. network services. This paper appears simply to be a design overview paper and presents no results, performance measurements, simulations, etc. No hard basis for evaluating whether this is a good or bad idea and whether it is more advantageous than the current centralized systems--which are working just fine at this current time. From andre@CS.Cornell.EDU Thu Nov 29 12:53:02 2001 Received: from sundown.cs.cornell.edu (sundown.cs.cornell.edu [128.84.96.20]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fATHr2T23353; Thu, 29 Nov 2001 12:53:02 -0500 (EST) Received: from khaffy (mail@dhcp99-178.cs.cornell.edu [128.84.99.178]) by sundown.cs.cornell.edu (8.11.3/8.11.3/R-3.6) with ESMTP id fATHr1206728; Thu, 29 Nov 2001 12:53:01 -0500 (EST) Received: from andre by khaffy with local (Exim 3.32 #1 (Debian)) id 169Vm5-0005bJ-00; Thu, 29 Nov 2001 12:19:05 -0600 Date: Thu, 29 Nov 2001 12:19:05 -0600 From: =?iso-8859-1?Q?Andr=E9?= Allavena <andre@CS.Cornell.EDU> To: egs@CS.Cornell.EDU Cc: andre@CS.Cornell.EDU Subject: 615 PAPER 65 Message-ID: <20011129121905.A21523@khaffy> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.23i Sender: =?iso-8859-1?Q?Andr=E9_Allavena?= <andre@CS.Cornell.EDU> Herald: A good introduction to the design of a p2p system, pinpointing down the interesting issues (scalability, none mututal trust; resilience, self-organizing, etc.) Besides that, there is not much interesting going on since they do not enter the details of any of the issues involved, especially how would/can work a weak consistent distributed state. They also say that "If it is broken, don't bother fiwing it" [about the web] it is not clear but they might say that theyu wont to have to overcomming of failure handled on the client side. -- Andr� From samar@ece.cornell.edu Thu Nov 29 13:21:47 2001 Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fATILlT28862 for <egs@cs.cornell.edu>; Thu, 29 Nov 2001 13:21:47 -0500 (EST) Received: from photon.ece.cornell.edu (photon.ece.cornell.edu [128.84.81.138]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id fATIIqM22491 for <egs@cs.cornell.edu>; Thu, 29 Nov 2001 13:18:52 -0500 Date: Thu, 29 Nov 2001 13:18:55 -0500 (EST) From: Prince Samar <samar@ece.cornell.edu> To: <egs@CS.Cornell.EDU> Subject: 615 PAPER 65 Message-ID: <Pine.LNX.4.33.0111291317190.31705-100000@photon.ece.cornell.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Herald: Achieving a Global Event Notification Service This paper presents the requirements and design overview of Herald, a new global event notification system being developed at Mircosoft Research. At each Herald server, Rendezvous Points are created to which subscribers and publishers associate themselves to receive notifications and publish events respectively. The design criteria for Herald are as follows. It is assumed that Herald will be constructed based on interaction between machines within cooperating but mutually suspicious domains of trust. The system should be able to scale without bounds on the internet and should be fault tolerant towards disconnected, malicious or corrupted participants and should provide access control. The system should be able to independently reconfigure and adapt to changes without the need of any external intervention. The events need to be communicated in a timely manner and they should be cached for temporarily disconnected clients. Network partitioning should not affect the operation within each partition. Herald draws inspiration from the development of the internet, applying the lessons learnt to its design. Herald peers treat each other with mutual suspicion and do not depend on the correct behavior of any single peer. All distributed state is maintained in a weakly consistent soft-state manner and expired after a time-out interval. All distributed state is incomplete and may be inaccurate. For scalability and load distribution, the rendezvous points may be replicated. This helps in fault tolerance too in the event of some server going down or getting disconnected. In order to reduce redundant transmission, Herald implements event notification by means of multicast-style overlay distribution networks. All the knowledge about clients, rendezvous points and their replicas are maintained in a soft state, timer based manner. Event history is maintained in a similar manner. Also, administrative rendezvous points are present in the network which notifies interested parties about changes to a rendezvous point. The authors mention a number of still unresolved issues which need to be studied in greater detail for Herald to be successful.