1. 27 Feb, 2003 1 commit
    • Robert Ricci's avatar
      Add a blocking poll, event_poll_blocking(), to the event library. · b6cf32b8
      Robert Ricci authored
      Note the following: (from the API file)
        IMPORTANT: elvin uses timeouts internally. So, this function does
        NOT guarantee that when it returns, either an event has been
        recieved or your timeout has passed. This should not be much of
        a problem, but you have been warned!
      
      The above is not really fixable, without hacking elvin. And it may
      not be entirely fixable even then. In particular, the first call to
      event_poll_blocking() will always return at once, since there are
      leftover timers from connecting to elvind.
      b6cf32b8
  2. 10 Jul, 2002 1 commit
  3. 25 Mar, 2002 2 commits
  4. 18 Mar, 2002 1 commit
    • Leigh B. Stoller's avatar
      First cut at dynamic events. Current status is this: · bf806164
      Leigh B. Stoller authored
      1. The tevc client can run on either a client node or on users. The
         command line syntax is like this:
      
      	Usage: ./tevc [-s server] [-c] event
      	       ./tevc [-s server] -e pid/eid time objname event [args ...]
      	       time: 'now' or '+seconds' or [[[[yy]mm]dd]HH]MMss
      	Examples:
      	       ./tevc -e pid/eid now cbr0 set interval_=0.2
      	       ./tevc -e pid/eid +10 cbr0 start
      	       ./tevc -e pid/eid +20 cbr0 stop
      
         The -s arg defaults to BOSSNODE when not given. Only root can send
         TBCONTROL events (-c), but that part of tevc is probably going to be
         killed off when we convert to sending TBCONTROL via tmcc/tmcd (Rob
         is working on that). The -e option is required for dynamic events,
         and is not defaulted yet.
      
      2. There is no real checking of arguments. The event is sent over to
         the scheduler, which tries to map it into an agent running on a
         node. If the map fails (say, no such trafgen, or no delay node on
         that link), or if the event makes no sense for that agent, the
         event fails and the user never hears about it. The solution for
         this is a back channel so that the scheduler can generate an error
         condition that the user sees.
      
      3. To facilitate better checking, I think we need to change the DB
         tables so that there is a mapping between the type of agent
         (object) and the kinds of events it can take. This would replace
         the flat event_eventtypes table. The event_scheduler could load
         this table at init time so that it can do a quick check on dynamic
         events when they arrive and return an error when we support error
         values.
      
      4. The scheduler initialization phase tries to determine what agents
         are valid for an experiment (thats where you can send events) so
         that when a user sends an event to cbr3, the event scheduler can
         determine what/where that is. My method for determining this is
         totally ad-hoc right now; read the virt_trafgens and delays table.
         These are the only two types of configurable agents we support.
         This is rather bogus! I think assign_wrapper or some other script
         in the front end needs to collect this data into a single table for
         the scheduler to read. Not sure yet; needs more thought. Anyway, I
         build a mapping table that can be searched when a dynamic event
         comes in; this avoids a DB table lookup in the critical path.
      bf806164
  5. 05 Mar, 2002 1 commit
  6. 27 Feb, 2002 1 commit
  7. 26 Feb, 2002 1 commit
  8. 21 Feb, 2002 1 commit
    • Leigh B. Stoller's avatar
      Some whacking of the event system. I have implemented the addressing · 8305021f
      Leigh B. Stoller authored
      scheme that we discussed in email. Notifications and subscriptions now
      take an "address_tuple" argument (I know, crappy name) that is a
      structure that looks like this:
      
      	char		*site;		/* Which Emulab site. God only */
      	char		*expt;		/* Project and experiment IDs */
      	char		*group;		/* User defined group of nodes */
      	char		*host;		/* A specific host */
      	char		*objtype;	/* LINK, TRAFGEN, etc ... */
              char		*objname;	/* link0, cbr0, cbr1, etc ... */
              char		*eventtype;	/* START, STOP, UP, DOWN, etc ... */
      
      These can be a specific value, ADDRESSTUPLE_ANY if you are a
      subscriber, or ADDRESSTUPLE_ALL if you are a producer. The reason for
      the distinction is that you can optimize the match expression with the
      extra bit of information, and the above structure can make for a
      fairly lengthy match expression, which takes more time of course.
      You should use address_tuple_alloc() and address_tuple_free() rather
      than allocating them yourself. Note that host above is actually the
      ipaddr of control interface. This turns out to be more convenient
      since free nodes do not have virtual names.
      
      Also added a new tbgen directly. This directory includes 3 programs in
      the making:
      
      tbmevd: Is the Testbed Master Event Daemon, to be run on boss and will
      handle TBCONTROL events (reboot, reload, etc). It is just a shell of a
      program right now, that takes the events but does not do anything
      useful with them. Have not defined what the events are, and what DB
      state will be modified.
      
      tbmevc: Is the Testbed Master Event Client (akin to tmcc). It
      generates TBCONTROL events which the tbmevd will pick up and do
      something useful with. This program is intended to be wrapped by a
      perl script that will ask the tmcd for the name of the boss (running
      the event daemon).
      
      sample-client: This is a little client to demonstrate how to connect
      to the event system and use the address tuple to subscribe to events,
      and then how to get information out of notifications.
      
      Note that I have not created a proper build environment yet, so new
      programs should probably go in the event dir for now, and link using
      the same approach as in tbgen/GNUmakefile.in.
      8305021f
  9. 19 Feb, 2002 1 commit
  10. 31 Jan, 2002 1 commit
  11. 29 Jan, 2002 1 commit
    • Ian Murdock's avatar
      * Added event_schedule to the event API, which allows events · e9f9388a
      Ian Murdock authored
      to be scheduled at a later time. The interface to event_schedule is
      identical to event_notify, except it takes an additional struct
      timeval argument that specifies when the event should be fired.  We
      assume time synchronization between nodes.
      
      * Revamped the attribute interface. Rather than a single get and put
      function that takes a union "type" argument, we now have separate
      event_notification_get_<type> and event_notification_put_<type>
      functions, where <type> is one of "double", "int32", "int64",
      "opaque", "string". These changes should greatly simply the attribute
      interface. The opaque attribute type is new, and allows
      arbitrary data structures to be added to notifications as attributes.
      
      * Added event_notification_remove, which deletes an attribute from a
      notification.
      
      * Modified the event notification callback to take "host" and "type"
      parameters, which contain the "host" and "type" attributes from the
      event notification, respectively.
      e9f9388a
  12. 06 Nov, 2001 2 commits
  13. 01 Nov, 2001 1 commit