DESIGN 5.38 KB
Newer Older
1 2 3 4 5 6
OVERVIEW
********

The testbed event system is composed of four parts: (1) the event
library, which implements a simple, transport-independent API that
clients may use to trigger and respond to events; (2) the event
7 8 9 10 11 12
scheduler, an event system client that triggers events at specified
future times; (3) frontends that take events specified by the user as
input and pass them to the event scheduler; and (4) backends that
respond to various system events on behalf of the testbed.  Each
of these four parts are described in more detail in the following
sections.
13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

Event library
=============

Clients in the system trigger and respond to events using the event
library.  The event library is currently implemented as a layer above
the Elvin publish/subscribe system (see "ELVIN OVERVIEW" below for a
brief overview of how Elvin works).  A library and API separate from
Elvin exists for several reasons:

    - The event library provides a much simpler interface than Elvin,
      providing only the functionality that should be needed in
      the testbed.  This should make it significantly easier to write
      clients that use the event system.

    - The event library API is independent of Elvin, so if we change
      to a system other than Elvin in the future (or write our own),
      only the event library will need to be ported.  In particular,
      no event system clients should need to be changed.

    - The event library API is significantly simpler than the Elvin
      API, so it should be much easier to implement in environments
      such as the Linux kernel, the OSKit, or Scout.

37
The event library is currently available as a C library on Unix.
38 39 40 41 42
The C API is described in the API file.

Event representation
--------------------

43 44 45 46 47 48 49 50
Events are represented by Elvin notifications that contain two system
defined fields: (1) "host", which specifies the hostname of the
testbed node that should receive the event notification, or "*" if the
event notification should be sent to all nodes; and (2) "type", which
specifies the event type.  In addition to the system defined fields,
event notifications may contain additional attributes (in
the form of name/value pairs) that may be used to provide additional
information about the event that has occurred.
51 52 53 54 55

Event scheduler
===============

The event scheduler is an event system client responsible for
56 57 58 59 60 61 62 63 64 65 66 67
triggering future events.  To schedule an event for firing at a
future time, event system clients may call the event library API
function event_schedule.  event_schedule accepts a notification
and a firing time, alters the notification to change the type
attribute to EVENT_SCHEDULE and add a firing time attribute, and
then sends the altered notification using event_notify.  The event
scheduler subscribes to EVENT_SCHEDULE notifications.  As they
arrive, it restores the type in the notification to that of the
original event and enqueues the notification in a priority queue
for firing at the indicated time.  When the time arrives, the
scheduler removes the notification from the queue and resends it
using event_notify.
68 69 70 71

Frontend support
================

72 73 74 75 76 77 78 79
[ Note that the event system currently has no frontend support. Such
  support needs to be added for each system event type that needs to
  be supported, e.g. traffic generation control. ]

The frontend for static events is the NS script. Frontend support
for static events consists of a set of modifications to the NS
parser that extracts events from the NS script and passes them to
the event scheduler. For example, the NS command
80 81 82

    $ns at 0.5 "$cbr0 start"

83 84 85
might cause a event with type=TRAFGEN_START and host=<hostname of the
node $cbr0 is attached to> to be scheduled by the event scheduler for
execution in 0.5 seconds.
86 87 88 89 90 91 92 93

The frontend for dynamic events could be a GUI that either triggers
events directly (using the event library) or schedules events to be
triggered in the future (using the event scheduler).

Backend support
===============

94 95 96 97
[ As with frontend support, the event system currently has no backend
  support. Such support needs to be added for each system event
  type that needs to be supported, e.g. traffic generation control. ]

98 99
The backends are event system clients responsible for responding to
certain events on behalf of the testbed.  For example, traffic
100
generation nodes might be event system backends that start generating
101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122
traffic when they receive the TRAFGEN_START event notification
and stop generating traffic when they receive the TRAFGEN_STOP
event notification.

ELVIN OVERVIEW
**************

The testbed event system currently uses the Elvin publish/subscribe
system for communicating between event producers and event consumers.
Elvin uses a client/server architecture for delivering notifications.
The server accepts subscriptions from clients and routes notifications
from producers to the consumers that wish to receive them.
Notifications are arbitrary-length lists of name/value pairs (e.g.,
"type: NODE_FAILED, time: 23"), and subscriptions are expressed using
a simple syntax (e.g., "type == NODE_FAILED && time > 20").  Clients
can be both producers and consumers in the same session.  Clients may
be written in C, C++, Java, Python, and Emacs Lisp.  For more
information about how Elvin works, please see http://elvin.dstc.com/.

Elvin supports wide-area federations of Elvin servers; we can use this
feature to enable a global event namespace across multiple testbeds in
different geographic locations when the time comes.