Object / Notification Service (v0.1)

1
Object / Notification Service(v0.1)
2
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.
This node has a path-name \frank\logons\home_pc A
nd has a value of 184.208.161.5
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
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.
3
2. Object/Notification service (v.0.1)
Frank
A subscription for user Frank with depth lt 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.
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.
These nodes are gt2 steps away, so no
notifications get to Frank!
4
3. Object/Notification service (v.0.1)
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.
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.
0
1
2
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.
5
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.
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.
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
Subscriptions stored as part of the data structure
Some subscribed entity, user
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.
Other stored information about the subscribed
entity / user / whatever
Contract 30000 milliseconds (?)
/root//some_path/some_node1/
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.
/root//some_path/some_node2/
/root//some_path/some_node3/
/root//some_path/some_node4/
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.
7
6. Object/Notification service (v.0.1)
Subscriptions Part 3

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.

• 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
• 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.
• 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

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/171043
8
7. Object/Notification service (v.0.1)
Subscriptions Part 4
Some arbitrary subtree in the hierarchy
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.
notifications
Subscription Pool
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
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. ?
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?)
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?)