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.