1. Object / Notification Service (v0.1)

2. Hypothetical tree that stores the information about workstations a user is logged in to. Each o is a node. Although only leaf nodes are shown here with values (for clarity). Any node may have a value … even non-leaf nodes This node has a path-name: \frank\logons\home_pc And has a value of: 184.208.161.5 So, the tree is much like an ordinary hierarchical file system with files and folders. One key exception is that folders, like files, can have data (ie, a value) pinned to them. So, theres no real distinction between leaf nodes (ie, files) and non-leaf nodes (ie, folders) in our tree. For now, think of data that may be stored at a node as arbitrary binary data. 1. Object/Notification service (v.0.1) Service provides a tree of named nodes. Each node stores a value. Each node has a unique path name.

3. Service allows clients (processes that run at a machine and operate on behalf of a user) to receive notifications of changes that occur in the tree Clients lease subscriptions. A subscription says which user to notify and which part of the tree to watch. A subscription is placed on the root of the subtree to watch. Part of the subscription says how far down the tree, away from the node on which the subscription is placed, to watch for changes. Frank A subscription for user Frank with depth <= 2 placed on this node means watch for changes to the subtree in the dashed box that occur at most 2 steps away from the root of this subtree. In this example, notifications of changes that occur on filled nodes will be sent to user Frank but not the unfilled nodes. These nodes are >2 steps away, so no notifications get to Frank! 2. Object/Notification service (v.0.1)

4. Nodes can basically set limits for how far the notifications they produce will travel up through the parent nodes. Nodes can also impose notification blockades on themselves, such that notifications originating in their childrens subtrees will propagate no further than those notification blockades. Notifications only go as far as the Notification Blockade A notification blockade wont let notifications pass through it. So, if an infinite notification node (one whose notifications will propagate all the way to the root of the tree) passes a notification up the tree, it will still not pass the blockade. If this node has a propagation of 2, any notification originating there will travel up the tree only two levels. This allows a limitation on notifications coming from high-traffic nodes. 012 3. Object/Notification service (v.0.1)

5. This is just some basic subscription information for the server. More complicated instances and ideas to follow… Since every node is essentially identical in that each can contain some arbitrary binary data, then also any node can be subscribed to. Every subscription can only travel down. Ie, in subscribing to a node, one can only receive information from that node and its child nodes and trees; not its parents. Subscriptions can have a specified depth. So, you can subscribe to a node with a subscription depth of 2, which will afford notifications up to two levels beneath the subscribed node. 4. Object/Notification service (v.0.1) – Subscriptions Part 1 If the subscribed node in the diagram is subscribed to with a depth value of 2, it will receive notifications from a maximum of two levels beneath it. No notifications will reach the subscribed node from above (ie, from parent nodes) Assuming the same subscription depth of 2, no notifications from the furthest child nodes will reach the subscribed node.

6. 5. Object/Notification service (v.0.1) – Subscriptions Part 2 Leased Subscriptions: This is most likely a very good idea. Takes checking for living / dead clients out of the hands of the server (in essence, the server would be sending out are you there? messages to clients, otherwise). The responsibility of ensuring existence falls to the client subscribing to a particular set of things. Each user (this term needs revision and agreement between us) has a contract with the service which must have a time limit specified with it. Before that time contract runs out, it is the responsibility of the subscriber to renew their contract or risk being removed from the subscription list. Each user manages their own subscription list, it is not up to the server to manage it, only the connections and notifications. (this point may be deprecated; also, this point only applies if were implementing expiry on a per-node basis and not just leaf-nodes, which I think we are) if data in a particular node expires, and subscriptions for it still exist, the node will not disappear. Only a node with no remaining subscriptions can be removed by the service from expiry. The idea is that subscribers may still be interested in old data to which they are connected. Some subscribed entity, user Other stored information about the subscribed entity / user / whatever /root/…/some_path/some_node1/ /root/…/some_path/some_node2/ /root/…/some_path/some_node3/ /root/…/some_path/some_node4/ Contract = 30000 milliseconds (?) Subscriptions stored as part of the data structure Subscriptions are stored as paths to nodes that a particular user is subscribed to. This list is managed by the client (I am interested in these things) and internal connections to the nodes themselves are handled by the service. Notifications are delivered by using the stored attributes of the user who is connected. The contract field holds the subscription contract of the connected user or entity being described by this structure. We could do this as either a time to expire at (so, time and date … note this is probably best), or a length of time until expiry (may also have advantages however). Responsibility to renew this contract is solely that of the entity / user.

7. 6. Object/Notification service (v.0.1) – Subscriptions Part 3 Subscription maintenance – it is up to the subscriber to renew their leased contract before the expiry date and time are reached. If there is a failure to renew a contract (which can contain several subscriptions) all of those subscriptions are implicitly expired, and are removed from their subscribed nodes. If the reason for this is a temporary loss of contact between the client and the service, when the client reconnects the most recent information will be fetched anyways. Quality of service – there are two ways to treat failed notifications: 1.In one instance, a failed notification on a given subscription will necessitate that the subscription and its contract will immediately expire. If connection is re- established, the most recent data will be retrieved anyways. 2.The other way to treat subscriptions is to maintain them even when notifications fail until they expire naturally. Delivery guarantee – from the second point above, there are three different ways to treat notification events and classify them in terms of how subscribers have responded (or not) to them). Basically after a notification event, subscribers will fall into one of three categories: 1.Delivered and received – this means that a notification message was sent out and that a particular subscriber has received it. The read-receipt can be implemented as a simple time stamp on the subscriber list to the node that sent out the notification. 2.Delivered and not received – in this case, the notification was sent but was not received. If the Subscriber has requested a significant enough quality of service, the notification will be cached until either the client receives it on reconnection or the contract expires (in which case the notification as cached will disappear) 3.Not delivered – this means that the notification was sent, and was not received by the subscriber. Additionally, the quality of service as requested by the subscriber has dictated that the notification will not be cached for any future reference. Possibly, a time-stamped subscription could look like this and be compared to the time and date that the most recent notification had been sent out to determine a read-receipt or not: /home/joe_blow/11/13/2000/17:10:43

8. 7. Object/Notification service (v.0.1) – Subscriptions Part 4 The subscription pool is something that may or may not be included. The idea with the subscription pool is that there can be one common location that several users who are interested in common information can subscribe to. The goal is to allow notifications from a varied number of sources to be posted to one common location, reducing subscription counts. How this would be implemented is not quite clear. It could be as easy of having a subtree in the architecture reserved solely for different types of subscription pools. Arbitrary subscribers somewhere in the hierarchy. They subscribe to one common location to receive a variety of different notifications. In this case, one subscription yields notifications from three different locations Subscription Pool Some arbitrary subtree in the hierarchy notifications

9. 8. Object/Notification service (v.0.1) – whats in a node? Whats in a node? Node Name (unique in subtree) Arbitrary Binary Data (some maximum amount) Link to immediate parent Notification propagation count (subscription barrier?) Subscribers list (links into a table of subscribers?) (point to pool?) Expiry date / time This is stuff that needs to be explicitly tracked for a node in the tree. These things may not be exhaustive, and similarly, they may not exist within the same db table. Im not really sure how to go about doing that, though, so it would take a little bit of learning on my part. Whats in a subscription? Subscription ID (contract number) Subscriber name Subscriber IP / Port (specific contact info) Subscription expiry date / time Subscription list (links into the tree to specific nodes?) This is what constitutes a subscription contract. The list may or may not be exhaustive. Im not sure if its altogether possible to have a list of subscriptions in the database as a field that dynamically grows. Possibly just have another db table that includes the Subscription ID and the Node Name / path for the subscription. This could basically link a list of subscribers and nodes through two primary keys. One problem with this is that its not very rich (ie, not much you can do with it … but is more needed?)