How Calendar Server Interacts with ENS

Figure 1–1 shows how ENS interacts with Calendar Server through the alarm queue and two daemons, csadmind and csnotifyd.

Figure 1–1 ENS in Calendar Server Overview

Calendar Server Alarm Queue

ENS is an alarm dispatcher. This decouples alarm delivery from alarm generation. It also enables the use of multiple delivery methods, such as email and wireless communication. The csadmind daemon detects events by sensing changes in the state of the alarm queue. The alarm queue’s state changes every time an alarm is placed in the queue. An alarm is queued when a calendar event generates an alarm. The following URIs represent these kind of events:

for events:

enp:///ics/eventalarm?calid=calid&uid=uid&rid=rid&aid=aid

for todos (tasks):

enp:///ics/todoalarm?calid=calid&uid=uid&rid=rid&aid=aid

where:

• calid is the calendar ID.

• uid is the event/todo (task) ID within the calendar.

• rid is the recurrence id for a recurring event/todo (task).

• aid is the alarm ID within the event/todo (task). In case there are multiple alarms, the aid identifies the correct alarm.

The publisher csadmind dequeues the alarms and sends notifications to enpd. The enpd daemon then checks to see if anyone is subscribed to this kind of event and sends notifications to the subscriber, csnotifyd, for any subscriptions it finds. Other subscribers to alarm notifications (reminders) can be created and deployed within an Calendar Server installation. These three daemons interacting together implement event notification for Calendar Server.

Calendar Server Daemons

Calendar Server includes two daemons that communicate to the ENS daemon, enpd:

• csadmind

  The csadmind daemon contains a publisher that submits notifications to the notification service by sending alarm events to ENS. It manages the Calendar Server alarm queue. It implements a scheduler, which lets it know when an alarm has to be generated. At such a point, csadmind publishes an event. ENS receives and dispatches the event notification.

  To ensure alarm transfer reliability, csadmind requires acknowledgment for certain events or event types. (See Alarm Transfer Reliability.) The csadmind daemon uses Reliable Event Notification Links (RENLs) to accomplish acknowledgment.

• csnotifyd

  The csnotifyd daemon is the subscriber that expresses interest in particular events (subscribes), and receives notifications about these subscribed-to events from ENS, and sends notice of these events and todos (tasks) to its clients by email.

  Though the ability to unsubscribe is part of the ENS architecture, csnotifyd does not bother to unsubscribe to events for the following two reasons: there is no need to unsubscribe or resubscribe during normal runtime; and due to the temporary nature of the subscriptions store (it is held in memory), all subscriptions are implicitly unsubscribed when the connection to ENS is shutdown.

  The csnotifyd daemon subscribes to enp:///ics/alarm/. The todo (task) or event is specified in a parameter.

Alarm Transfer Reliability

To ensure that no alarm ever gets lost, csadmind and csnotifyd use the RENL feature of ENS for certain types of alarms. For these alarms, csadmind requests an end-to-end acknowledgment for each notification it sends, while csnotifyd, after successfully processing it, generates a notification acknowledgment for each RENL alarm notifications it receives.

For these RENL alarms, should the network, the ENS daemon, or csnotifyd fail to handle a notification, csadmind will not receive any acknowledgment, and will not remove the alarm from the alarm queue. The alarm will, therefore, be published again after a timeout.

Calendar Server Example

A typical ENS publish and subscribe cycle for Calendar Server resembles the following:

1. The event subscriber, csnotifyd, expresses interest in an event (subscribes).

2. The event publisher, csadmind, detects events and sends notification (publishes).

3. ENS publishes the event to the subscriber.

4. The event subscriber cancels interest in the event (unsubscribes). This step happens implicitly when the connection to ENS is shut down.

Figure 1–2 illustrates this cycle and Table 1–1 provides the narrative for the figure.

Figure 1–2 Example Event Notification Service Publish and Subscribe Cycle for Calendar Server

Table 1–1 Sample ENS Publish and Subscribe Cycle

Action	ENS Response
1. The csnotifyd daemon sends a subscription request to ENS.	ENS stores the subscription in the subscriptions database.
2. The csadmind daemon sends a notification request to ENS.	ENS queries the subscriptions database for subscriptions matching the notification.
3. The csnotifyd daemon receives a notification from ENS.	When ENS receives a notification from a publisher, it looks up its internal subscription table to find subscriptions matching the event reference of the notification. Then for each subscription, it relays a copy of the notification to the subscriber who owns this subscription.
4. Currently, csnotifyd does not bother sending cancellation requests to ENS.	Because the subscriptions store is in memory only (not in a database), all subscriptions are implicitly unsubscribed when the connection to ENS is shutdown.