|
|
|
|
@ -244,7 +244,8 @@ performing analysis of the Topology, enhancing it with additional data (e.g.
|
|
|
|
|
ping response times from other system), or specifying parameters for
|
|
|
|
|
visualisation. As a part of Birdvisu itself, we ship several anotators:
|
|
|
|
|
TopologyDifference outputs the differences between the reference and current
|
|
|
|
|
Topology, and ShortestPathTree marks the edges of the shortest path DAG.
|
|
|
|
|
Topology, and ShortestPathTree marks the edges of the shortest path DAG. The
|
|
|
|
|
next section describes how Annotators aid visualising the data.
|
|
|
|
|
|
|
|
|
|
The last important object related to annotation is the AnnotatedTopology. It
|
|
|
|
|
serves as a coordinator for running Annotators. It does two main things:
|
|
|
|
|
@ -273,6 +274,131 @@ does not need this functionality, so it is not implemented at the moment.
|
|
|
|
|
|
|
|
|
|
\section{Visualisation}
|
|
|
|
|
|
|
|
|
|
\XXX{Layouting (nonexistent), why not graphviz, why not consensual metrics, how we are re-using annotations internally. Saving layouts}
|
|
|
|
|
The visualisation is split into two parts: computing the appearance and
|
|
|
|
|
actually showing the result. For the former we reuse the Annotator
|
|
|
|
|
infrastructure. The latter is handled by Qt's Graphics view framework.
|
|
|
|
|
|
|
|
|
|
The appearance is described by a styling dictionary. For vertices, it contains
|
|
|
|
|
a position and a highlighting colour. Edges can have a colour, line width and a
|
|
|
|
|
highlighting colour. However, more styling properties can be defined in the
|
|
|
|
|
future.
|
|
|
|
|
|
|
|
|
|
To provide those styling dictionaries, a subclass of Annotators is created,
|
|
|
|
|
StyleAnnotator. StyleAnnotators only differ from regular Annotators in that
|
|
|
|
|
they only tag vertices and edges with styling dictionaries. This provides
|
|
|
|
|
something similar to an interface, helping to uncouple the style from the
|
|
|
|
|
specific Annotator that provided the respective data. Each Annotator which
|
|
|
|
|
provides data worth showing has a companion StyleAnnotator to provide the
|
|
|
|
|
respective style.
|
|
|
|
|
|
|
|
|
|
The styling dictionaries are then combined in a MegaStyler, another
|
|
|
|
|
StyleAnnotator. The MegaStyler ensures other StyleAnnotators are run and
|
|
|
|
|
combines the styles in order of importance (the bitwise-or operation on
|
|
|
|
|
dictionaries is used, so that the styles for more important StyleAnnotators
|
|
|
|
|
override the previous appearance).
|
|
|
|
|
|
|
|
|
|
We considered using stylesheets similar to CSS, but we think that
|
|
|
|
|
approach is too heavy-weight. Rather, assigning priorities to the
|
|
|
|
|
StyleAnnotators could allow a more flexible order of applying styles, but at
|
|
|
|
|
this point this also seems like a unnecessary complication of the project.
|
|
|
|
|
|
|
|
|
|
We let the user decide, where the vertices should be placed, because they might
|
|
|
|
|
have some idea or understanding of the system that is not present in the
|
|
|
|
|
topology. For this reason, we also ignore classical metrics of graph drawing,
|
|
|
|
|
like the crossing number of the layout. This can be demonstrated on the default
|
|
|
|
|
Gennet topology: while it forms a planar graph, it makes more sense to let the
|
|
|
|
|
edges cross, because the layered structure is more important.
|
|
|
|
|
|
|
|
|
|
To store the placement, we reuse the ospffile format. An example is shown in
|
|
|
|
|
listing~\ref{lst:visufile}. The top-level contains a \verb|visualisation|
|
|
|
|
|
directive, so that other information may be stored in the same file in the
|
|
|
|
|
future. Level-2 contains vertex specification in the same format as in dumps
|
|
|
|
|
from BIRD. On level-3 there is a \verb|position| directive with the
|
|
|
|
|
coordinates, but for transit networks, additional details (DR or address) can
|
|
|
|
|
be provided to specify the correct network. Similarly, we allow a \verb|router|
|
|
|
|
|
level-3 directive to be used in the \verb|stubnet| block.
|
|
|
|
|
|
|
|
|
|
\begin{lstlisting}[float=h,label=lst:visufile,caption=Vertex placement description]
|
|
|
|
|
visualisation
|
|
|
|
|
router 192.0.2.14
|
|
|
|
|
position 200 200
|
|
|
|
|
network 192.0.2.0/28
|
|
|
|
|
position 0 1500
|
|
|
|
|
dr 192.0.2.14
|
|
|
|
|
\end{lstlisting}
|
|
|
|
|
|
|
|
|
|
This format allows using BIRD's output as the basis for the visualisation file
|
|
|
|
|
and could be extended by other directives if needed in the future. The
|
|
|
|
|
visualisation file is loaded by the PlaceVerticesFromFile Annotator.
|
|
|
|
|
|
|
|
|
|
We try to place vertices without known position in proximity to already placed
|
|
|
|
|
neighbours, so that the user can easily locate them. Since the neighbours can
|
|
|
|
|
also have unknown position, BFS is used: we place the vertices of known
|
|
|
|
|
positions, then their neighbours in their proximity, then the neighbours'
|
|
|
|
|
neighbours and so on. When there is a completely unplaced component, we place
|
|
|
|
|
one of its vertices at random. However, disconnected topologies are of little
|
|
|
|
|
interest to us.
|
|
|
|
|
|
|
|
|
|
We tried using Graphviz\cite{graphviz} for laying out the vertices, but we
|
|
|
|
|
were not satisfied with its result. To demonstrate, the
|
|
|
|
|
listing~\ref{lst:graphviz} describes the topology of our home network with
|
|
|
|
|
Gennet attached. Figure~\ref{fig:graphviz} then shows how each of Graphviz's
|
|
|
|
|
layout engines draws the topology. While it could be possible to tweak the
|
|
|
|
|
engine setings, we believe the user still knows better, so we did not continue
|
|
|
|
|
exploring this idea.
|
|
|
|
|
|
|
|
|
|
\lstinputlisting[float=h,label=lst:graphviz,caption=Author's home topology]{../img/graphviz-fail/source.dot}
|
|
|
|
|
|
|
|
|
|
% Imagine the figure here, but LaTeX does not re-order figures.
|
|
|
|
|
|
|
|
|
|
The display of the topology is then straight-forward. We just take the
|
|
|
|
|
Annotation from MegaStyler and create graphics objects for each vertex and
|
|
|
|
|
edge. The Graphics view framework allows us to set z-values of the sprites,
|
|
|
|
|
which we exploit when highlighting objects -- we create a bigger
|
|
|
|
|
semi-transparent object below the actual one. An example of the graphical representation is on figure~\ref{fig:ui-highlight}
|
|
|
|
|
|
|
|
|
|
\begin{figure}[b]
|
|
|
|
|
\centering
|
|
|
|
|
\X{fig:ui-highlight}
|
|
|
|
|
\caption{An example of a highlighted vertex and an edge}
|
|
|
|
|
\label{fig:ui-highlight}
|
|
|
|
|
\end{figure}
|
|
|
|
|
|
|
|
|
|
The Qt framework has built-in support for dragging items, so our GUI can also
|
|
|
|
|
be used to modify the positions of vertices.
|
|
|
|
|
|
|
|
|
|
\begin{figure}[t]
|
|
|
|
|
\centering
|
|
|
|
|
\begin{subfigure}[b]{0.8\textwidth}
|
|
|
|
|
\centering
|
|
|
|
|
\includegraphics[width=\textwidth]{../img/graphviz-fail/dot.pdf}
|
|
|
|
|
\caption*{dot}
|
|
|
|
|
\end{subfigure}
|
|
|
|
|
\begin{subfigure}[b]{0.8\textwidth}
|
|
|
|
|
\centering
|
|
|
|
|
\includegraphics[width=\textwidth]{../img/graphviz-fail/circo.pdf}
|
|
|
|
|
\caption*{circo}
|
|
|
|
|
\end{subfigure}
|
|
|
|
|
\begin{subfigure}[b]{0.45\textwidth}
|
|
|
|
|
\centering
|
|
|
|
|
\includegraphics[width=\textwidth]{../img/graphviz-fail/sfdp.pdf}
|
|
|
|
|
\caption*{sfdp}
|
|
|
|
|
\end{subfigure}
|
|
|
|
|
\begin{subfigure}[b]{0.45\textwidth}
|
|
|
|
|
\centering
|
|
|
|
|
\includegraphics[width=\textwidth]{../img/graphviz-fail/neato.pdf}
|
|
|
|
|
\caption*{neato}
|
|
|
|
|
\end{subfigure}
|
|
|
|
|
\begin{subfigure}[b]{0.45\textwidth}
|
|
|
|
|
\centering
|
|
|
|
|
\includegraphics[width=\textwidth]{../img/graphviz-fail/fdp.pdf}
|
|
|
|
|
\caption*{fdp}
|
|
|
|
|
\end{subfigure}
|
|
|
|
|
\begin{subfigure}[b]{0.45\textwidth}
|
|
|
|
|
\centering
|
|
|
|
|
\includegraphics[width=\textwidth]{../img/graphviz-fail/twopi.pdf}
|
|
|
|
|
\caption*{twopi}
|
|
|
|
|
\end{subfigure}
|
|
|
|
|
\caption{The unpleasant results of Graphviz's layout engines}
|
|
|
|
|
\label{fig:graphviz}
|
|
|
|
|
\end{figure}
|
|
|
|
|
|
