Is controlled by a new configure variable called TIMESTAMPS - if this
variable is set, prints out a timestamp, along with its arguments (so
that you can distinguish between the timesteamps.) Otherwise, does
nothing. The basic idea is that we can sprinkle calls to this in the
code, and only enable it on devel trees.

(we should remove the old ones soon)

These allow zooming and present (optionally)
  - Node type
  - Node IP listing
  - Link characteristics
     - always shows bw
     - shows latency if > 0
     - shows loss if > 0%

Added links in shownsfile.php3 for specifying zoom and more/less detail.

Added new vis tools.
(we should remove the old ones soon)

parser runs. The staticroutes script is a wrapper for Chad's route
solver. The network optimization is currently turned off; use -t to
turn it on, until I know if its correct.

Note that Chad gets credit for routecalc.cc; I'm just committing the
file for him, with a couple of trivial changes that I made.

requested by Jay. The info is sent in the email, but I am not
bothering to store it in the DB.

now do this under either FreeBSD or Linux.

Note that for NSE models (eg. FullTCP), we still explicitly use FBSD-STD,
because we don't run NSE on Linux.

out can be fed directly to mysql to fix up the database.

Also fixed up some weird capitalization that sneaked in somehow.

drop out virt_lans than include virtual nodes, until I get Chad's
stuff integrated. Drop any pretense of supporting virtual nodes in a
LAN; just die. Add tunnels table DB upload; tunnels are created
in place of a vlan when the link includes a virtual node. The tunnel
info is based on the virt_lans info of course, so that the user gets
virtual devices with the appropriate IP address. There is some goo for
determining who is the server and who is the client, and making sure
that we start just a single server (in case a node has multiple
tunnels). Also add post pass over virt_trafgens table to make sure
that port assignments are unique (using new DB table). Oop, need to
add something to make sure that IP addresses are unique too!

Oh, clear out some obsolete code.

in the NS file in one of two ways:

$ns cost $nodeA $nodeB 2
or
$link0 cost 3
(The latter form can also be used for LANs)

This information is stored in the database in the cost column of the
virt_lans table.  It's important to note that cost data is _not_
divided between the two sides of the link, as things like delay and
rdelay are. Since there are no physical devices (ie.  delay nodes)
node that this configuration needs to be split up between, doing so
would just be unnecessary work.

remote, be local someday).

BIG CHANGE: Start using the last_reservation table to auto reload
nodes that are reallocated before they are reloaded by the reload
daemon.

Add call to vnode_setup -k when swapping out.

remote node. Called out of os_setup and tbswapout (-k option to tear
down the vnodes). Invokes the proper script on the remote node, with
the vnodeid (vronXXX) as the key (which is passed along in tmcc to
distinguish vnodes from each other).

post pass the table and reassign the port space (in assign_wrapper).

1) Merge in the accounts code that I did for ron. Instead of resetting
   the password file on each reboot, look at the node status to
   determine if the password/group file should be reset. If the
   node is free, reset it. Otherwise, we track changes to the password
   and group file now, so that users can change it and not have their
   changes wiped out at each reboot. I had to do this for the ron
   nodes so that the testbed software would not alter or delete
   already existing accounts; I keep a couple of little dbm files
   listing all the accounts/groups added. The only downside right now
   is if a node is reallocated before it is wiped clean; I plan to add
   an os_teardown phase to experiment termination asap.

2) Add tunnels support. New DB table (tunnels) provides information
   for running vtund to link up to remote nodes. Creates a vtund.conf
   file on the fly, and fires them off. The complication is that you
   cannot do the ifconfigs or the routes until the tunnels are
   connected, so that stuff has to be configured within the vtund.conf
   file on a per tunnel basis. vtund.conf has some sections for
   running commands when tunnels are brought up or down.

3) Damage the routing configuration code that Mike did. To support
   tunnels, as noted above, rc,route is no longer a simple list of
   commands, but a program that adds/dels routes based on the netmask,
   with a special "enable" section for the other stuff. This allows me
   to call it from vtund.conf for up/down on each tunnel'ed
   interfaces, as needed. Quite gross, but no way around it.

4) For remote nodes, add a vnodesetup script, invoked from boss when
   experiments are setup/torndown. This gets the tunnel/route/trafgen
   configuration and runs them. It then goes into the background
   waiting for a death signal, at which time it brings them down and
   cleans out the vnode state.

rough estimate of the bandwidth between each pair of nodes, and is
in kilobits per second.