Moooore

fix bib, reorder citations, reword, why basic OSPF, ch3

en/bibliography.bib

@@ -255,9 +255,9 @@
 
 @inbook{as-topologies,
 	author = {Canbaz, M Abdullah and Bakhshaliyev, Khalid and Gunes, Mehmet},
-	year = {2018},
-	month = {02},
-	pages = {243-257},
+	year = 2018,
+	month = feb,
+	pages = {243--257},
 	title = {Router-Level Topologies of Autonomous Systems},
 	isbn = {978-3-319-73197-1},
 	doi = {10.1007/978-3-319-73198-8_21}

en/chap01.tex

@@ -12,7 +12,8 @@ this we derive a set of properties Birdvisu should fulfil.
 Several approaches to network monitoring and status visalisation already exist.
 These can be approximately split into several types: visualisation of existing
 data, traffic visualisation, host monitoring systems and integrated system
-management platforms. We \X{uuuuuuuuuu}.
+management platforms. Here we introduce them shortly and explain their
+potential disadvantages, compared to visualisation of routing data.
 
 \subsection{Visualisation of existing data}
 
@@ -125,9 +126,10 @@ currently work. % Pls don't tell the dorms :-)
 We want Birdvisu to:
 
 \begin{itemize}
-	\item Be a simple tool, easy to run on a regular laptop
+	\item Be a simple tool, easy to run on a regular laptop,
 	\item Leverage the knowledge of topology, which is common in the system,
-		without needing to collect data from other hosts
+		without needing to collect data from other hosts,
+	\item Help administrator quickly recognise issues in the network,
 	\item Allow to be enhanced by other data and to export own data to other
 		projects, in the future.
 \end{itemize}

en/chap02.tex

@@ -13,10 +13,10 @@ BIRD routing daemon.
 
 \section{OSPF overview}
 
-OSPF is a link-state routing protocol, which means that routers try to understand
+OSPF\cite{rfc2328,rfc5340} is a link-state routing protocol, which means that routers try to understand
 the whole topology of the network and find the best path using an algorithm for
 finding the shortest paths. Usually, Dijkstra's algorithm \X{ref?} is used.
-OSPF was designed to provide dynamic routing in a whole autonomous system, but
+OSPF was designed to provide dynamic routing in an entire autonomous system, but
 running it on a much smaller scale is also possible.
 
 OSPF requires routers to share information about the state of the topology in
@@ -94,6 +94,13 @@ RFCs that update the base specifications\cite{rfc2328,rfc5340}. Therefore, we
 do not implement the protocol ourself, but rather find a suitable routing
 daemon \X{glos} to determine the current topology.
 
+Many improvements of the protocol only affect the topology construction (e.g.
+NSSA areas\cite{rfc3101}) or change the data exchange between routers
+(Multi-instance extensions\cite{rfc6549}, authentication\cite{rfc5709}, \dots).
+By extracting the topology from a routing daemon, we can support many OSPF
+extensions for free. For this reason, it is mostly sufficient to only consider
+the base specifications of OSPF.
+
 \section{Routing daemon selection}
 
 While we were mostly determined to use BIRD\cite{bird} from the start, since we already
@@ -121,7 +128,7 @@ two-part metric\cite{rfc8042}.
 \section{BIRD interface}
 
 The BIRD daemon is controlled through a UNIX domain socket using a text
-line-based protocol slightly resembling SMTP\X{cite?}. The client may send
+line-based protocol slightly resembling SMTP. The client may send
 commands to the daemon, which provides responses. The response may be long and
 possibly formatted into a table. This interface is primarily aimed at human
 users, so a rather simple client, \texttt{birdc}, is provided in the BIRD's
@@ -171,7 +178,7 @@ of the \texttt{show ospf state} command is still the only the viable option of
 getting a topology description. The following subsection describes the syntax of
 the response to this command.
 
-\subsection{Retrieving the OSPF state}
+\subsection{Retrieving the OSPF state}\label{ss:ospffile}
 
 Let us look in depth at the \texttt{show ospf state} command, since we will be
 using it and the format of its output a lot.
@@ -429,7 +436,7 @@ across the area, unless there is another change in topology (for example, if
 this is caused by a cable connected to a wrong port, the network will probably
 be stub).
 
-\section{Area structure}
+\section{Area structure}\label{s:areas}
 
 It is also worth to consider the expected size and structure of an OSPF areas
 where Birdvisu might run. While it is up to the administrator and they may be

en/chap03.tex

@@ -1 +1,44 @@
 \chapter{Design}\label{ch:design}
+
+We now explain the design of Birdvisu in depth. First, we explain some
+important decisions and present the overall structure of the project, then we
+look into individual parts of the program.
+
+Birdvisu is implemented in Python, using PySide6, the official bindings for
+Qt6, for drawing on screen. We decided to use Qt, because it provides a lot of
+pre-made widgets and tools and since it is widely used, it is easy to find help
+for it on the Internet. The decision to use Python was not hard either. Not
+only Qt has official bindings for it, but we use the language very often and
+thus are comfortable writing in it. We do not expect the potential slowness of
+Python to be an issue, because for handling graphics we are using Qt, which is
+written in C++. Also, as we have analysed in section~\ref{s:areas}, we expect
+the topologies to be quite small.
+
+The project comprises of three main parts: data collection, annotation and
+presentation part. The data collection part is tasked with finding out the
+current topology and creating a usable representation of such topologies and
+their combinations. In the annotation part, we add additional information to
+the topologies like the difference from the expectation or graph properties of
+the topology. Finally, when we have all the needed information, we draw the
+topology on the screen, highlighting the relevant information.
+
+\section{Recurring and general patterns}
+
+\XXX{dictionaries everywhere, hashable recipes. ospffile with comments as a reusable format. Format of VertexID}
+
+\section{Data collection: providers and parsing}
+
+\XXX{sub-parts, why a topology is not a graph, stacking topologies with
+multiedges, fake-freezing, why is everything static. Graph representation, selection of BIRD's
+instance}
+
+\section{Annotations}
+
+\XXX{scoping, annotator creation, advantages of storing data in annotations and
+not vertices. Annotator protocol and posibility of export. Various uses of annotators: enhancing, analysis, visualisation}
+
+\section{Visualisation}
+
+\XXX{Layouting (nonexistent), why not graphviz, why not consensual metrics, how we are re-using annotations internally. Saving layouts}
+
+