The Thunder and Lightning protocol simulator has stringent memory requirements as it must track every ATM cell in the simulated network to ensure that no cells are lost. When simulating a relatively simple 4 x 2 mesh of ATM switches and the data sources connected to it, the network simulator must keep track of over 2 million ATM cells, or 100 MB of data. While novel data representation techniques [6] allow us to reduce the memory requirements of the simulator significantly, it is clear that, while simulating more complex networks, the simulator may consume all of the available memory in its host machine. In addition, the simulation process is entirely compute-bound. Thus, any extra computation the host machine must perform negatively impacts the speed of the simulation.
Therefore, in designing the simulator display, we had the following goals:
We minimized the memory requirement of display code within the simulator by making the user interface a separate application. Whereas a typical Tcl/Tk application integrates the user interface into the application, we split the application and the user interface into two separate processes using TCP/IP sockets to provide the interprocess communication. As a result, the display process can run on a separate machine. This not only reduces the size of the simulation code but also implies that the window system (e.g., X Windows) does not have to run on the machine performing the simulation, thereby increasing the amount of memory available for use in the simulation.
While executing the user interface on a separate machine helps reduce the computational load on the machine running the simulation, employing a client/server relationship between the display and the simulator further reduces the computational cost. The simulation does not constantly send status information to the display over the communication channel. Instead, the display requests (only) the information needed to satisfy the user demands. The simulator responds to display requests with the appropriate information, and the display process then manipulates the received data into a form suitable for display. In this way, the simulator is interrupted from normal processing only when a specific request is received; if the display is idle or not running, no processing time is wasted.
Finally, display flexibility is provided through the use of the Tcl/Tk scripting language [4]. As described in Section 3 below, almost all of the graphics-related code is written as compact Tcl/Tk scripts, which allow for rapid coding of new window types. The display uses only a small amount of C code to initiate requests and to convert the binary response data into string lists that the scripts can use.