The purpose of a module's C code is to handle communication with the simulator over the socket. Unlike other remote display applications, such as [9], which exchange text messages over a socket, the simulator and display exchange binary data. We use XDR (external data representation) [10] routines to convert data to and from network form. This allows the display and simulator to be run on architectures with different binary representations. The initialization code, not shown here, installs a channel handler for the socket that reads raw data from the socket into an XDR buffer. The channel handler then passes the XDR buffer to the appropriate module's handler based on the response type. (Recall that simulator responses must be self-identifying because the display is stateless.)
The path module initialization code is shown in Figure 4. The initialization code simply registers a new command with the Tcl interpreter to allow a Tcl script to request a path display.
Figure 5 illustrates the code for the request procedure. We create an XDR buffer with a call to xdrmem_create, and then encode each element of the request using XDR functions. In this case, the request consists of the request type, D_PATH, a flag indicating the path's persistence, and the session ID to be displayed. When the request has been assembled, we send the entire XDR buffer to the simulator over the Tcl socket (PORT.socket) between them.
When a response is received from the simulator, the channel handler servicing the socket reads the data from the network into an XDR buffer. Based on the response type, the appropriate module's handler function will be invoked. The code in Figure 6 will be invoked for all responses of type D_PATH. The path module expects responses to be in the format indicated in Figure 3. HandlePath reads all of the data from the XDR buffer and then parses it into Tcl strings by printing into temporary character arrays. Lists are assembled as shown in Figure 3 before invoking the Tcl procedure to display the path information.
