TorXviz Example

Here we show how the TorXviz tools are used in a typical test session with TorX.

The following figure shows the TorXviz tools that are running in a typical session with TorX, and the data flow between them.

architecture of TorXviz tools in typical TorX session

At the bottom, in the big box 'Generic' we see the generic TorXviz programs that we discussed on the TorXviz introduction page.
At the top, in the big box 'TorX-specific' we see torx-specific programs that provide the visualization data for the generic programs: TorX itself, and a number of utilities (small filters) that translate data from torx-specific formats to the generic formats that the TorXviz tools expect. The 'fat' (bold) arrows represent the data in 'generic' format that flows from the TorX-specific programs to the generic TorXvis programs.

In the figure the normal boxes represent (running) programs, and ellipses represent files. The yellowish normal boxes are TorXviz client programs that are started directly by the user. The greenish normal boxes are TorXviz server programs that are started via the TorXviz client programs -- the user does not need to be aware of their existence. The blueish normal box reprents all non-visualization components of TorX. The reddish normal box represents the TorX-specific 'glue' programs that are needed to translate TorX-specific data into the 'generic' format expected by the TorXviz client programs.

The boxes with rounded rectangles represent the windows that the user sees. The normal arrows represent data that flows from one program to another over a reliable medium, usually a pipe or a tcp connection. The stippled arrows show which (server) programs create and control which windows.

The dashed arrows represent the synchronisation connection between the various visualization programs that allows them to simultaneously show (switch to) the same step in the visualization sequence.

When we study the figure more closely we see that all windows are created (controlled) by server ('srv') programs, and that all communication between a TorX-specific program and a server program flows via a dedicated instance of the client program for the particular server.
We also see that we use the same filter program (log2anifsm) in three different ways to filter out different information from the log. In two cases (for 'spec' and 'impl') log2anifsm only derives animation commands ('ani' in the figure) that are used to color nodes and edges of a graph given in a pre-generated dot file ('spec.dot' resp. 'impl.dot'). In the third case (for 'testrun') the graph is dynamically created while test testing takes place, so there log2anifsm derives also graph node and edge creation commands ('dot' in the figure, hence the 'dot + ani' arrow).

This page has last been updated by Axel Belinfante on Wednesday, 8 March 2006.