We need to log system activity for three reasons.
The first two are relatively straightforward. The third is much more complex.
The "outside" part of the demo will be performed at Dartmouth. We must record demo activity so that we can replay it for the Washington audience in November. The first and easiest thing that we need to replay is what the soldier and analyst actually saw on their screens during the demo.
Making a complete recording (e.g., every mouse movement) is difficult and unnecessary. Instead we can just selectively record most of the agent messages that are sent to the soldier's and analyst's GUI. In the case of the analyst, we would record all of the GPS positions coming from the soldiers as well as all of the SALUTE reports. As we are replaying the recorded events, we can freeze the playback and do any desired queries or send any desired confirmation requests through the normal GUI, as if the demo were happening live. In the case of the confirmation requests, we will establish a dummy soldier's GUI that will just make a dummy response to the confirmation request.
In the case of the soldier's GUI, we would record all GPS positions, all order updates coming from Battalion HQ, all confirmation requests coming from Battalion HQ, and all network-sensing alarms coming from the network-sensing system. As we are replaying the recorded events, we can freeze the playback at any point and generate a SALUTE report through the normal GUI. We will establish a dummy analyst's GUI to receive the confirmation responses and the SALUTE reports.
What actually happened during the demo might be different than what any of the soldier's or analyst's saw on their map. For example, suppose a group of three soldiers breaks away from the main group, creating a network disconnection. None of the other soldiers or the analysts will see what that small group does during this period, simply because position broadcasts from the small group can not be transmitted across the disconnection.
Thus the Aprl 2 system on each laptop must log every addition/removal (to/from the routing table) of a neighbor machine, the GPS system on each laptop must continually log the laptop's position, and the active-networking system must log the queue entry and exit times of every message plus the alarms coming from the network-sensing system. By merging these logs after the demo is over, we can build and replay a complete view of where each laptop was at any point in time, which laptops could reach which other laptops at any point in time, and what happened to observations and query agents during a network disconnection (i.e., they were queued at the disconnection boundary).
Logging enough information to analyze the performance of demo components is the most difficult logging task, and the one that we have discussed the list. For now, I just list data that we might want to collect. We must decide which of these data we actually want to collect, and which of this data we can collect given the tight development timeframe (i.e., do we have time to write the logging code needed in some of the more complex cases?).
NOTES:
By agent type, I mean a search agent that queries a particular database, vs. an active-networking agent that carries an observation out of the wireless network, vs. a stationary agent that provides an interface to a database, etc.
By query type, I mean a query against a relational black-gray-white database, vs. a query against a text databases, vs. a query against two text databases, etc.
By transmission type, I mean a migrating agent, vs. a probe packet sent out by Harvard's routing algorithm, vs. an alarm sent out by RPI's network-sensing module, etc.
I say "network link" below. I am not sure yet what constitutes a network link inside the wireless part of the network -- we could imagine a conceptual network link between every machine pair, or we could view the air as a single network link, or (perhaps too difficult) we could try to use the position history to break things apart by interference region. Of course, the loggers will be logging on a per-machine basis (so we will end up with machine-pair data), so this is probably more a question of how best to present the data after we get it.
Getting (most of) the time-related data will be relatively straightforward, as long as we use ntp to synchronize the laptop clocks before each demo run. Getting the packet and byte data will require more thought (along with careful examination of the Harvard, RPI and Dartmouth software components).
To get the averages, we will log all agent and active-networking events (arrival on a machine, departure from a machine, broadcast of a network probe packet, etc.) and then postprocess the logs. Among other things, this approach will let us compute a moving average for any of the things below.
DATA:
Overall
Queries and observations
Routing, network-sensing and active networking