Software Architecture of NetSimQ
Software Architecture
A common strategy to implement simulation engines is to globally define the event types and use a ``switch'' statement in the simulation engine to dispatch all the events to their appropriate event handlers. Although conceptually straightforward, this implementation strategy makes future extension for new events difficult. Each time a new event is added, perhaps as the result of incorporating a new network architecture (i.e., a change in the specific network architecture layer), the switch statement in the simulation engine has to be modified accordingly. The consequence is that a change in a higher layer may trigger changes in a lower layer, which violates the design principle of object-oriented programming.
To facilitate future extension, we adopt a totally different implementation strategy and separate event execution from event handling. Specifically, we put the event handler in the event class, i.e., each event now carries its own event handler. When the simulation engine takes an event, it does not have to tell the event type (and hence the corresponding event handler to invoke), but simply invokes the event handler carried by the event. That is, we delegate the responsibility of assigning appropriate event handlers to events to the specific network architecture layer.
To facilitate debugging and step-by-step demonstration of instantaneous network changes, we also include in the simulation layer the {\sf EventMonitor} class that provides a facility to monitor events currently handled by the simulation engine or an event handler.
Specifically, this layer subclasses the Network class and the Node class from the corresponding classes in the generic network component layer, with the addition of several session operations, such as session creation, session setup, and session termination. Moreover, it also defines the Session class and the superclasses for the traffic description (Traffic class), the unicast/multicast routing algorithms (Routing class), the resource management protocol (RsrMgt class), the admission control facility (Admission class), and the message scheduling algorithm (Link class, which inherits from the Link class in the generic network component layer), respectively. The superclasses are defined here to keep generic attributes of a set of similar objects. Specific objects (that implement specific algorithms/protocols) can be extended from superclasses with their own specific methods. The superclasses (and, in particular, the programming interfaces of those superclasses) have been carefully defined to encompass a wide spectrum of algorithms/protocols in the algorithm layer.
Demonstrations and user interfaces that are related to the network architecture are also defined in the specific network architecture layer. The user interfaces allow users to configure the network of interest in terms of network topology, sessions and their traffic/QoS characteristics, and algorithms/protocols used in the various components of the QoS framework. In particular, we define two superclasses NetUIPage and NetDisplay. Each NetUIPage is in charge of one network attribute, e.g., network topology, network configuration, session configuration, and simulation run. Only one page can be active at a time. NetDisplay displays the network topology: it takes mouse events (click and move) from the user and passes them to the active NetUIPage which in turn performs appropriate actions in response to the mouse events. SimulationBroker acts as a bridge between user interface objects and the other simulation objects.
The NetworkStat and SessionStat classes calculate and keep the global network and per-session performance statistics, respectively, while the LinkDemo class facilitates display of the packet schedule at a link and/or the buffer usage at a node. Also defined in the specific network architecture layer is the ``stimuli'' to the simulation, i.e., the session generation engine (SessionGenerator class) which generates sessions according to the user-specified probability distributions, and the session generation handler (SessionGenerateHandler class) which interacts with the simulation engine to continuously generate relevant events.
The above figure shows the execution flow of NetSimQ. NetSimQ_Applet and NetSimQ_Panel act as the front end of NetSimQ. NetSimQ_Applet may run as a Java applet or a Java application. NetSimQ_Panel implements the main control window which interacts with users. It allows users to construct a simulation scenario from scratch through the four NetUIPages and to save/load a simulation scenario to/from a configuration file. SimulationBroker acts as a bridge between user interface objects in the NetSimQ_Panel and the other simulation objects. When a user constructs a simulation scenario and starts the simulation, SimulationBroker builds the simulation objects from the user's inputs, and starts the simulation engine. During the course of simulation run, SimulationBroker is responsible for obtaining information from the simulation objects in response to users' requests.
Return
to NetSimQ Overview Page
