






SPEW Iteration 1 Design
Team SPEW Conceptual Architecture and Rationale

The architecture that we are using is a Pipe and Filter architecture. We are using a Pipe and Filter architecture because of the natural flow of logging data from the simulation into a input form which can be graphically displayed. We also considered different architectures such as an event driven one, but ultimately chose Pipe and Filter for the reasons explained below.
ODIN User:
The ODIN user wants to design and run a peer-to-peer network simulation and have a log of all peer activity that can be used in post processing to visualize the network, wants to visualize the entire peer-to-peer network layout in an easy to understand graphical format, wants to see how the network is affected over time, wants to have different views of the graphical network structure, wants alternative presentation of the simulation, wants the ability to inspect a specific area of the network topology, or a large view of the entire network.
ODIN Simulation
The ODIN simulation builds many peers and randomly simulates a peer-to-peer network based on configuration settings and the trace file.
ODIN Peers
ODIN peers send messages and queries to each other. When this happens, a log event is sent to the preprocessor.
The ODIN toolkit already existed prior to this project and its design is documented here and here. We have made minor tweaks by adding a new log level and log messages, but these changes wouldn't be reflected well by a uml class diagram or sequence diagram.
Preprocessor
The preprocessor performs two tasks:
- Merges network events across peers. If the preprocessor is receiving ODIN network event logs from two or more ODIN peers (as opposed to a (single) ODIN discrete event simulation), it will merge these logs into one stream, ordered by event timestamps. (If receiving events from a simulation this would be a no-op.)
- Offloads expensive analyses and passes through the event log. If there are any time-consuming analyses that will often be performed on the combined event log, it will be performed here (as opposed to by the Visualization GUI each time it opens a event log). Also if there is a task that requires making a pass across the event log (e.g. building an adjacency matrix that represents whether two nodes were neighbors at any point during the ODIN run), it should probably be performed here. The results of these analyses will be written to the end of the output file, in such a way that the visualization GUI component can directly access them. (What these analyses and passes are will be driven by the layouts supported, and are subject to change.)
We expect that the preprocessor will only require one pass over the event log data, and thus will only have to output to a file. However the dotted arrow above represents the possibility where the preprocessor has to make multiple passes and will read in the file it has just written.
If the visualization component does in fact rely on pass(es) as we anticipate, it will not be able to render a live ODIN network. Instead an ODIN run will have to be performed, and only after the run can it be visualized. This is not be a big concern for our customer. On the other hand, once the preprocessor has finished the output file it can be rendered quicker (which will be a win if the same run is displayed several times) and by being a single file will be more suitable for distribution to others (e.g. as an accompaniment to an academic paper).
Because the visualization component may want to first access the post-pass results (e.g. to determine node layout prior to displaying any network events), we can't generalize the connection between the preprocessor and visualization component to a stream/pipe. We have restricted the preprocessor's output to a file to allow the visualization component to jump to the results and to ensure quick replay of an ODIN run.
Data
The preprocessor will combine all log events from ODIN into a single data set. These events will give information about what is happening to the network. Example events are:
Timestamp | Peer1 | Action | Peer2 | Parameters
51 2.0.1.143:2000 connect 1.2.3.4:2000 10001
51 2.0.1.143:2000 sendmessage 1.2.3.4:2000 10001 102
71 1.2.3.4:2000 sendmessage 2.0.1.143:2000 10001 103
72 1.2.3.4:2000 disconnect 2.0.1.143:2000 10000
92 1.2.3.4:2000 disconnect 2.0.1.143:2000 10001
Also, statistical data can be collated and calculated for easier visual representation.
File System
The file system will store the data so that it can be read by the Visualization GUI.
Visualization GUI
The visualization component will read the output data from the file system and display a running animation of what took place during the simulation of the peer-to-peer network. The network will be represented using a connected graph structure in which each peer is a node in the graph and each connection is represented by a link. The links will have weights corresponding to how heavy network traffic is in that specific location. For example is network traffic was congested, a link would turn red.
Usage Scenarios:
Export peer-to-peer network activity from ODIN run.
ODIN User configures property file, trace file, and content map to their liking. ODIN User executes ODIN with log level 3 (the minimum level for visualization). ODIN Simulation is running and output is redirected to the log file. ODIN Simulation is successfully terminated. Log file contains all node creations, link establishments, and message sending.
Display animation of network topology formation.
ODIN User starts the viewer. ODIN User loads the ODIN log file. The Visualization GUI tool parses the log file and starts to build the network using a connected graph structure. Subsequent animations of the ODIN simulation are graphically displayed on the screen.
Allow user to switch layout algorithm and graph display heuristics.
The ODIN User selects the desired layout from a list. The screen is cleared and a new layout is drawn at the correct point in time in the simulation. The ODIN Simulation animation continues using the new layout.
Alternative Designs:
We originally considered having an event driven architecture in which events from ODIN are fed automatically into the Visualization GUI via network connections. This has several disadvantages that ultimately made us choose the design described above.
1) Networks can be unreliable and hard to troubleshoot.
2) It is unknown whether the visualization GUI would be able to support network connections from hundreds or perhaps thousands of nodes.
3) It would be more difficult to save the animation for viewing in the future. With the architecture above, this is already designed into the system.
Team SPEW Iteration 1 Design
The visualization GUI component, as opposed to the preprocessor, has been the focus of our iteration 1 development. Here is a class diagram for it:


Link to this Page