installed anyplace yet ...

be a worse problem with remote nodes, where we will not be able to
keep everyone up to date like we can in the local testbed case. I ran
into this yesterday with the key distribution stuff for RON nodes,
which require incompatable changes to the accounts info that is
returned. So, tmcc now takes a [-v version] argument, which is passed
through to tmcd in the request field. tmcd passes that version number
(assumed to be an int) down, and the routines should look at that. We
will need to make some structural changes in tmcd as we get more
version skew, but for now this is fine. Anyway, tmcd/tmcc have a
compiled in DEFAULT_VERSION (see decls.h). If no version is supplied,
assume DEFAULT_VERSION (2), which covers all of the old images and yet
to be updated current images. As the new tmcc makes it out, versions
will be sent through. VERY IMPORTANT: The current version is placed in
libsetup.pm. When you make incompatible changes, bump the version
number is decls.h and libsetup.pm, recompile and install a new tmcc
and the new libsetup.pm on the clients (and of course, tmcd on the
server).

Fixes to termination; Add signal handlers for HUP,INT,TERM, and make
sure all the children get killed off before exiting. We still have
some problems though; I think the children should wait until the
current request is completed before exiting. I'll give that some more
thought though since it easy to mess that stuff up (leave zombies).

Add build_info[] to startup message to syslog. Good for debugging.
Some minor cleanup and restructuring. Mike is gonna hate it.

a chance to react. Otherwise, we sometimes try to start the new one
before all the children have released the port number (socket).

to listen on the socket.  Since tmcd requests are basically
request/reply, each child is independent of the other, and so there
was no need to bring real threads into the picture. There is a new
option [-a num] to control the number of children in the pool;
defaults to 5. I set it up so that children that die are replaced with
new children. Hopefully this will add a little robustness, making sure
that tmcd is always running.

Oh, fix about a 100 -Wall warnings!

debugging. Make sure it gets passed through to udp case (-u), although
the udp case is going to get killed when we ssl'ize tmcd.

Also added the virt_agents table, which apparently hadn't made it
into CVS yet.

Queue events have a new parameter in the arg list for link events:

	ARGS="PIPE=pipe0 THRESH=8"

This is kinda hacky right now; I do not have time to get all the stuff
just right. The convention is that pipe0 is the first pipe in the list
(left to right) and pipe1 is the other. We can worry about cleanup
later.

daemon that receives the events that tmcd sends.

queue in each direction is in.

This is accomplished with SWIG, so that we can basically just call the
C functions from perl, and avoid a parllel implementation. Some glue
code is required, particularly for callbacks, macros, and functions
that return data through arguments.

Currently lacks support for a few functions, but is functional enough
to re-write the example C programs.

running program objects as particular users. For now, run the program
agent as the creator of the experiment.

grok them, it gets confused.

what the best approach is for running program objects as particular
users.

notification. Essentially a wrapper around the the elvin equivalent.

To be used by the forthcoming perl event system module.

request.

write call with some code to retry failed writes. Will retry once
every second for a few seconds before deciding to quit.

read call with some code to retry failed read attempts. Will retry
every 100ms for a few seconds before deciding to quit. While I think
about it though, we should probably retry longer to protect against the
situation when plastic crashes; any running Frisbee's will choke.

provides a mapping from an object ($cbr0) to the node on which the
agent is running ($nodeA). It also includes the type of agent
(TRAFGEN, LINK, etc). There were a number of reasons for adding this
table:

* To avoid a series of specialized table lookups in the event
  scheduler to map from a name (link0) to the node on which the agent
  is running. Previously, it was looking the delays table and the
  virt_trafgens table. Well, now it just needs to look at this one
  table and store the mapping internally. When a dynamic event comes
  in, we can figure out where to send it easily.

* For NSE traffic generation. Unlike the simple TG based CBRs, Shashi
  wants to be able to send events to any of the objects in the config
  (udp0, telnet0, ftp0, etc). Well, the virt_trafgens table certainly
  does not store that info, and it would have been painful to work
  this into it. For every agent/application, just add an entry in the
  virt_agents table and the scheduler knows where to send the events.

* It nicely supports the new program object; just plug an entry in the
  virt_agents table.

Okay, there is one messy aspect; delays nodes! Delay nodes are not
computed until after assign wrapper runs, so in addition to munging
the static event list in assign_wrapper, we now munge the virt_agents
table as well. Not much to do about this; delay nodes are handled
outside the normal path everywhere.

Note, this is going to change soon when we make dynamic events real;
will need to start a scheduler with every experiment.

freebsd. No biggie, just some minor script changes.

originally anticipated, but I was worried about confusion with the
Agent/Application API that NS provides, and which is substantially
different than this. Anyway, I added support for this syntax:

	set prog0 [$ns program]
	$prog0 set node $nodeA
	$prog0 set command "/bin/ls -lt >& /users/stoller/logs/foo"

Kinda obvious, although whats not obvious is that without events to
start and stop them, these will never run. So, I added support for
this:

	$ns at 10 "$prog0 start"
	$ns at 20 "$prog0 stop"

You can start and stop programs as much as you like, but you cannot
start a program that is already running; you have to stop it first.
You can also issue these dynamically using the same api:

	tevc -e testbed/Tevents now prog0 start \
		"command=/bin/ls -lt / >& /users/stoller/logs/foo"
	tevc -e testbed/Tevents now prog0 stop

Note the quotes when using a multiword command. I also had intened to
support a KILL command so that you could send arbitrary signals to a
process. I added that, but I will not bother to document it yet; since
I invoke /bin/csh to process the command line, the issue of signals is
a little fuzzy. Sending a signal like -HUP to the parent process (the
csh) is not really what we want to do. I think we can support this,
but I need to poke around and see what the right way is.