When the user wishes to display a particular piece of information, the display sends a request to the simulator. Each request consists of a single integer request-type field followed by a request-type-specific number of arguments. Figure 3 illustrates the format of the request message used to obtain session routing information from the simulator. The request-type field holds the constant integer value, D_PATH, assigned to path requests. Routing information requests have two arguments. The flags field argument indicates whether the path display should be persistent or transient, while the session ID field indicates the simulated connection that should be displayed.
To aid in the concurrent development of the simulator and the display, the display application is stateless with respect to communication. When the display makes a request on behalf of the user, it does not maintain any record of the request. This enables the simulator to ignore unrecognized requests, while not causing the display to hang awaiting a response that will never be received. Similarly, if the display cannot handle a response from the simulator, the response may be discarded without affecting the simulator.
Stateless communication also allows the display application to be used virtually unchanged with the real Thunder and Lightning switch. The Thunder and Lightning switch runs a small daemon process which implements the subset of simulator responses that apply within the context of a real switch. For example, the daemon responds to buffer occupancy requests, but silently ignores requests to edit or create simulation events. The interface presented to the user is the same whether the display is connected to a simulation process or a real switch.
The fact that communication is stateless, however, requires all responses from the simulator to contain sufficient information about the original request to enable the display to process the response appropriately. Figure 3 shows the format of a path response message from the simulator. Because no request state is maintained, the response includes both the session ID and the flags fields transmitted in the original request message. In fact, the simulator completely ignores the flags field when processing the request; the persistence information for the path display must be transmitted to the simulator in the request message for the sole purpose of returning it in the response message. In addition to information from the original request, the response also contains the source and destination IDs of the path, a set of triples containing information about each hop along the path, and a field indicating the length of the set. Each triple identifies the switch ID and the ports on which the session enters and exits that switch. As described later in Sections 3.2 and 3.3, the display converts these integers to Tcl lists in C code and then to display-specific alphanumeric canvas tags in order to choose the correct canvas items to highlight on the topology display.
