How EXAMS works
Next figure depicts EXAMS overall design.
EXAMS overall design
We can see that EXAMS receives as input the NS-2 trace file, a proper implementation of the occupied routing protocol and the user’s visualization preferences. The NS-2 trace file provides the simulation data which constitute the basis for the visualization, the routing protocol implementation encapsulates the semantics of the protocol which controls how the simulation data are presented and finally the visualization preferences are a simple way to handle additional animation issues like color preferences and file locations.
As the trace file is the primary source for the visualization process, it is absolutely necessary to provide EXAMS with all the necessary data for a proper presentation of the protocol under examination. Fortunately the NS-2 layered architecture permits each protocol to add its own information to each related event inside the trace file. This enables the protocol designer to serialize protocol’s related data and store them as a string representation. Then as the trace file is fed to EXAMS input, it is able to get back this information and visualize it.
Programmatically a protocol implementation for EXAMS is a Java class. As EXAMS parses the trace file it identifies the name of the routing protocol and expects to find a class file with exactly the same name under a specific classpath. This Java class is the protocol’s implementation for EXAMS and is used to handle everything that is protocol dependent. This procedure is possible due to Java Reflection Mechanism, which enables a Java application to load and use a class at the run time given the class file location. Put simply the goals of an EXAMS protocol implementation is the proper parsing of the protocol related data inside the trace file and their visualization according to protocol’s semantics.
Next figure illustrates a more detailed view of the EXAMS architecture and the way it uses the protocol implementation to get the desired results.
As it seems at the core of EXAMS lays the Model class which provides the principal functionality of event traversing. We want the user to be able to see the state of the whole network at every event of the simulation and make random event jumps. On the other hand an NS-2 trace file is only a set of lines, each one corresponding to a simulation event which in turn is related to one node only (e.g packet sender, or receiver). In order to visualize the whole network at every event, Model has an internal array to store the state of the nodes of the network. As a next line of the trace file is processed, the Model can update the state of the corresponding node but keep the remaining nodes at the previous known state. The Model is also responsible for a number of things like calling Parser to read the trace file, load the Protocol implementation class, keep statistics of the network traffic, handle agent packets, calculate network partitions and other.
Another important class is the Animator class which is responsible for the visualization process itself. It uses the Model to know each time the state of each node and creates a visual representation of the network. This includes the nodes themselves, unicast and multicast packet transmission at routing and agent level and the outlining of network partitions with different colors. Animator can plot either on the screen or create a screenshot of the network into an image file. One issue has to do with positions of the nodes at the start of the simulation, because there are some routing protocols which do not specify the initial nodes layout. EXAMS handles this problem with an early positioning of the nodes. It scans the trace file and sets the initial position of each node as indicated by the first event related to that node. Early positioned nodes are shown grayed until their initial settlement.
As regards statistics EXAMS keeps packet counters at both network and node level. Each node has two sets of counters; one set is used for the routing layer and the other one for the agent layer. At each layer EXAMS counts the number of bytes being sent, received, forwarded or dropped. A same couple of counter sets is used to measure the total number of bytes being transferred into the network at routing and agent layer. Both these sets of counters are available to the protocol developer and can be used as the basis for the calculation of more complex statistics.
Every protocol implementation for EXAMS should implement the Protocol Java interface or alternatively extend the DummyProtocol class which is a naive implementation of the same interface.
||createNode(int address, double x, double y, HashMap <String, String> properties)
||updateNode(MobileNode n, HashMap<String, String> properties, int eventIndex)
Protocol Java interface
Table above shows the methods of the Protocol interface. The most important methods are createNode, updateNode, copyNode and notifyEvent. One major responsibility of a class implementing the Protocol interface class is to create the MobileNode objects through the createNode method. Each MobileNode object represents a mobile node and contains all the data about the state of the node. Moreover a protocol developer can subclass the MobileNode class and create a more suitable version for the specific protocol with its unique data structures and functionality. After the initial creation of the MobileNode objects, EXAMS calls periodically the updateNode method in order to update node’s stored information and keep up to date the network. CopyNode method is a necessity for the system in order to make deep copies of the MobileNode objects. At last the notifyEvent method is called by the Animator class each time the user sends a UI event like a mouse click on a node or a transmission arrow. This in turn enables the Protocol class to further handle the user event according to protocol’s semantics.
EXAMS programming model
According to figure above, there is a routing protocol named MyProtocol, so a Java class with the same name should be implemented. This class can either implement directly the Protocol interface (as described in Table 1) or extend the DummyProtocol. Optionally protocol’s designer can implement a subclass of MobileNode to encapsulate protocol’s internal data structures as described above. The most interesting part of Figure 4 is the Visualizer class. It is a wrapping of EXAMS engine and aims to relieve protocol developer from the complexity of EXAMS internals. A protocol class can obtain a Visualizer object by calling a static method and use it as a service provider. Visualizer provides access to main screen’s tables, simulation events, packet counters, visual settings and in general whatever a protocol may need to handle the services provided by EXAMS infrastructure.
Next » EXAMS example