






SPEW Iteration 3 Design
Team SPEW Conceptual Architecture and Rationale
Contents
1) Architecture
2) Usage Scenarios
3) Alternative Designs
4) User Interface Mockups
5) Static Detailed Design
6) Dynamic Detailed Design
1) Architecture:

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 multiple passes 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.
2) 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.
User visualizes traffic flow information.
If the user wants to change the activity level threshold for displayed links, execute extension UC4.1 Change Activity Level Threshold. If the user wants to change the activity transparency level for displayed links, execute extension UC4.2 Change Activity Transparency Level. The user may choose to do neither of these and instead just watch the animation using the initial settings (threshold of zero, transparency level of zero percent).
Create ONA file for several ODIN peers executing in concert.
User configures property files and index files to their liking for each ODIN instance. User creates the directory that will hold the log files for all individual instances on the common file system. If this common directory already exists, execute extension UC5.1 Common Directory Already Exists. User starts the ODIN hostcatcher instance first. This instance should be started with log level 3 (the minimum level for visualization) or higher, and log output should be directed to a unique file in the directory created above. User then starts other instances of ODIN peers. These instances should be started with log level 3 as well, and log output for each should be directed to uniquely named files (e.g. ..log, to enforce that no two peers would have the same log file). User allows time for p2p network activity, likely injecting events (e.g. search requests) into the network using the randomwalkpeer's client. User terminates each non-hostcatcher peer. User terminates the hostcatcher. At this point, the p2p network should no longer exist and the log files in aggregate should contain all node creations, link establishments, and messages sent. User runs preprocessor on the command-line (on any machine that can access the common file system), specifying: 1. the common directory will all log instances and 2. the path to the desired output ONA file.
3) 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. An event-driven architecture would have three advantages for our project:
- Allow the user to see a real-time visualization of the network. They would not have to wait for ODIN to terminate before visualizing the activity.
- No additional file management. No log files would have to be generated for our graph viewer component to consume. Disk space would and file permissions would never be an issue.
- It might be possible to intermittently monitor a long-running ODIN network, even one that's already been started without visualization in mind.
This has several disadvantages to the event-driven architecture that ultimately made us choose the design described above.
- Networks can be unreliable and hard to troubleshoot.
- It is unknown whether the visualization GUI would be able to support network connections from hundreds or perhaps thousands of nodes.
- The event-driven architecture would more than double the activity on the (TCP/IP) network. The overhead of the event-driven architecture could great affect the performance of the ODIN overlay/p2p network, and hinder research.
- 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.
- While real-time playback would be possible, allowing the user to rewind or slow playback would be difficult. These features would probably require writing to disk, thereby cancelling out one of the advantages of the event-driven architecture.
However, our chosen architecture does have some disadvantages. Foremost, the user has to wait for ODIN to terminate before they can visualize activity. There are several files created, which brings in issues of disk space, file permissions and file management. Whereas the event-driven architecture might a user to monitor an already running ODIN network, a user of our design will have to decide they want to visualize network activity before starting ODIN, and then log all activity until ODIN terminates.
4) User Interface Mockups
Visualization Component
Here is a mockup of what we envision the Visualization UI to look like. In "Global Mode" the user sees a list of recently executed log messages:

In "Local Mode" the user sees a variety of statistics about the focus node. This includes uplink and downlink bandwidth, as well as recently executed log messages containing the focus node:

Preprocessor Component
The preprocessor is a command-line application and has no screen mockup. Here is its expected usage:
$ java Merge
Usage: java Merge logfile1 [logfile2 ... logfileN] outputfile.ona
5) Static Detailed Design
Here is the class diagram for the Visualization GUI component:

Here is the class diagram for the Pre-Processor component:

6) Dynamic Detailed Design
Here is a sequence diagram for creating a peer and drawing it:

Link to this Page