The Zephyr Notification Service
Total Page:16
File Type:pdf, Size:1020Kb
The Zephyr Notification Service C. Anthony DellaFera Digital Equipment Corporation Project Athena Massachusetts Institute of Technology Cambridge, MA 02139 [email protected] Mark W. Eichin Robert S. French David C. Jedlinsky John T. Kohl William E. Sommerfeld Project Athena Massachusetts Institute of Technology Cambridge, MA 02139 {eichin,rfrench,opus,jtkohl,wesommer}@ATHENA.MIT.EDU ABSTRACT Zephyr is a notice transport and delivery system under development at Project Athena.1 Zephyr is for use by network-based services and applications with a need for immediate, reliable and rapid communication with their clients. Zephyr meets the high- throughput, high fan-out communications requirements of large-scale workstation environments. It is designed as a suite of ‘‘layered services’’ based on a reliable, authen- ticated notice protocol. Multiple, redundant Zephyr servers provide basic routing, queue- ing, and dispatching services to clients that communicate via the Zephyr Client Library. More advanced communication services are built upon this base. Introduction g Design constraints. This paper is a brief introduction to the g Services provided for users by a notification concept of a notification service in general and to service. the design of the Zephyr Notification Service in g Unsolved problems and topics for future particular. A notification service provides development. network-based services and their clients with immediate, reliable, and rapid communication for While this paper is about Zephyr, Project small quantities of time-sensitive information. Athena’s Notification Service, it is our belief that The sections which follow address the following the concepts presented here can be generalized to issues: fit a broad range of notification services and sys- tems. A good understanding of a notification ser- g Motivation for developing a notification ser- vice can be acquired by comparing the Zephyr vice. Notification Service and a more traditional g Role of a notification service in networked method of workstation message delivery, elec- workstation environments. tronic mail (specifically, sendmail). Table 1 makes this comparison. -2- Table 1. iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii c c iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiA Comparison Between Zephyr And Mail c c c c ic iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiMetric c Zephyr c Electronic Mail c c c Addressingc Implicit/Dynamic: All addressing is c Explicit/Static: Sender must know c c c c c c determined dynamically; an explicit c and explicitly provide the name and c c c ‘‘address’’ is not required. One-to- c address (except for ‘‘local’’ mail) of c c c one addressing is supported by expli- c each recipient. Static mailing list c c c citly specifying of recipient ZID. c support is provided. Only recipients c c c c The notice subscription layered ser- c explicitly named receive messages. c c c c c c vice allows for self-selection by the c c ciiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic recipient. c c c Delivery Methodc Notices are delivered via dynami- c Mail is delivered using a point-to- c c c c cally routed reliable datagrams. No c point TCP/IP connection. Ack- c c c c c c connections need be established or c nowledgments are not supported, per c c c maintained. Multiple levels of c se. Return receipts may be requested c c c notice acknowledgment are sup- c but are not guaranteed to work. c ic iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic ported. c c c c c c c Delivery Actionc Asynchronous/Active: Notices arrive c Synchronous/Passive: Mail must be c c c without user intervention. Notices to c sent and read manually by the user. c c c a particular user are delivered c Mail, in general, is delivered to one c c c automatically and immediately to all c particular place (a ‘‘post office’’ or c c c c of his or her current login sessions. c ‘‘mail drop’’) for each user; s/he c c c c ciiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic c must then actively retrieve it. c c Message Lengthc Short, fixed, notice length with a c Long, typically unfixed, message c c c maximum of approximately 10 lines c length. Mail messages may be and c c c c of 80 characters each. c often are extremely large, on the c c c c c c c order of many pages. When mes- c c c c sage length is fixed it is usually done c c c c so by unpredictable rules that vary c ic iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic c from site to site. c c c c c c Message Persistencec Notices are considered time- c Long time-to-live. Messages typi- c c c sensitive; no queuing is provided. If c cally remain in a mail drop until c c c the client recipient is not logged in, c read. c ic iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic then the notice is flushed. c c c c c c c Message Fan-outc High fan-out: Sending to large lists is c Low fan-out. Sending to large lists c c c efficient. Each client generates one c can consume a great deal of the com- c c c copy of a notice regardless of the c puting resource. If a message is sent c c c number of recipients. Each server c to n users, n copies are generated by c c c c receives one copy of a notice being c the sender, each of which is retained c c c c c c routed regardless of the number of c indefinitely by its recipient. c ciiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic recipients. c c c Traffic Performancec High volume/High throughput: c Medium volume/Low throughput: c c c c Notices may be transmitted in large c Large mail messages can send a rea- c c c c c c numbers due to the low overhead of c sonable volume of data, but slowly c c c dynamically-routed reliable c (as connections need to be esta- c c c datagrams. c blished and routes determined). c c c c c c c c c c c c c c c c c c c c c c c c c ic iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic c c -3- iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii c c iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiA Comparison Between Zephyr And Mail c c c c ic iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiMetric c Zephyr c Electronic Mail c c c System Configurabilityc Dynamically reconfigurable: c Statically reconfigurable: Reconfi- c c c c c c Dynamic resource allocation and c guration of Unix mail systems is c c c configuration within the base notifi- c wizard-level work and has signifi- c c c cation services allows for automatic c cant global impact. No utilities are c c c and simple user-level reconfigura- c provided for dynamic system modifi- c c c c tion of layered services. c cation or reconfiguration. All c c c c c c c changes must be made centrally and c ciiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic c atomically. c c System Maintenancec Low maintenance: Layered services c High maintenance: Mail requires a c c c c dynamically recover unused c post office staff to maintain post c c c c c c resources through time-outs and c office boxes (mail drops), mailing c c c reference counting. c lists, the routing system, and to c ic iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic c manually reroute ‘‘dead letters.’’ c -4- A Solution To Communication Needs Electronic meeting services (conferencing When services designed for use in a time- systems) can notify interested users of new sharing environment are used for a very large sys- transactions, using the notice subscription tem of networked workstations, certain communi- layered service. cation services begin to fail.† They predom- Print Service inantly fail from to their inability to cope with Print servers (and queuing services in gen- large increases in network scale (i.e., an increase eral) can send job status information back in both the number of workstations and the to the job’s submitter. number of interconnected local area networks). MOTD Service After examining how certain of these services Message-of-the-day information (system communicate with their clients, we have identi- wide, service-specific, or local) can be sent fied two primary failure modes. These are the to users, such as when they begin using a inability of a service to cope with increasing particular service in the case of a service- server-to-client fanout and the inability of clients specific MOTD. to deal by the replacement of a local service with On-Line Consulting a remote, distributed service. The Zephyr project The notification service can be used as the was begun to provide a solution to these two underpinning of a dynamic on-line consult- failure modes in the context of time-sensitive ing service. The notice subscription lay- communications. Zephyr has grown into a more ered service can be used to provide topic powerful tool than was originally anticipated; based information routing, user location, what began as the development of a ‘‘desirable’’ and consultant-to-client rendezvous. service soon turned into the development of a ‘‘required’’ service. Host Status Service Broadcast-based host status systems (e.g., The following services are candidate clients ruptime) do not scale to a large