better graphics

thesis/content/02-background.tex

@@ -12,7 +12,4 @@ This chapter provides explanations and background information on relevant techno
 
 \section{Web 3.0 - Decentralized Applications (dApps)}
 \label{sec:dapps}
-\input{content/02-background/dapps}
-
-\section{Summary}
-\label{sec:background-summary}
+\input{content/02-background/dapps}

thesis/content/02-background/software-system-architecture.tex

@@ -2,16 +2,32 @@ The software system architecture describes the relationships and properties of i
 
 In the following, the characteristics and peculiarities of the different architectures are described in detail.
 
+
 \begin{figure}[h!]
 	\centering
-	\includegraphics[width=1.0\textwidth]{network-architectures}
+	\begin{subfigure}[c]{0.32\textwidth}
+		\includegraphics[width=\textwidth]{architecture-centralized}
+		\caption{Centralized}
+		\label{fig:architecture-centralized}	
+	\end{subfigure}
+	\begin{subfigure}[c]{0.32\textwidth}
+		\includegraphics[width=\textwidth]{architecture-decentralized}
+		\caption{Decentralized}
+		\label{fig:architecture-decentralized}
+	\end{subfigure}
+	\begin{subfigure}[c]{0.32\textwidth}
+		\includegraphics[width=\textwidth]{architecture-distributed}
+		\caption{Distributed}
+		\label{fig:architecture-distributed}
+	\end{subfigure}
 	\caption{Schematic representation of various software system architectures. In centralized applications (A), all clients (blue) are in connection with a central server (red), while in decentralized applications (B) several servers provide for improved stability. In distributed applications (C), all nodes have the same role with the same tasks, hence they are called peers (green).}
 	\label{fig:software-system-architecture}
 \end{figure}
 
+
 \subsection{Centralized Applications}
 \label{sec:centralized-applications}
-In a centralized application, the software essentially runs on a central node with a static address with which all other nodes communicate. This central node is called a server and the nodes connected to it are called clients. The clients use the services of the server.
+In a centralized application (see Figure \ref{fig:architecture-centralized}), the software essentially runs on a central node with a static address with which all other nodes communicate. This central node is called a server and the nodes connected to it are called clients. The clients use the services of the server.
 
 Typically, web applications are designed as centralized applications. The clients are usually (mobile) apps or browsers that act as the interface to the user. Examples are social networks such as Facebook and Twitter.
 
@@ -23,7 +39,7 @@ With regard to web platforms like Facebook, having access to all the data can be
 
 \subsection{Decentralized Applications}
 \label{sec:decentralized-applications}
-What are the advantages and disadvantages of centralized applications, is mostly reversed in decentralized systems. Unlike centralized applications, decentralized applications do not have a single point of failure. However, there is no node in the system that has all the data which makes accessing information sometimes hard. There is any number of nodes that perform the tasks of a server and by exchanging with other servers in total form a complete system.
+What are the advantages and disadvantages of centralized applications, is mostly reversed in decentralized systems. Unlike centralized applications, decentralized applications do not have a single point of failure (see Figure \ref{fig:architecture-decentralized}). However, there is no node in the system that has all the data which makes accessing information sometimes hard. There is any number of nodes that perform the tasks of a server and by exchanging with other servers in total form a complete system.
 
 Another advantage is that each server only handles the number of users covered by its resources. New servers contribute additional resources to the overall system. Distributed applications cannot be disabled easily because a new server can be started at any time that does not fall under a lock. Because the data are not centrally available, they cannot be processed, so that user data are better protected. Also, there is no longer a prominent attack target. So, hacking a single server loses lucrativeness.
 
@@ -33,7 +49,7 @@ Examples of decentralized applications are the social networks diaspora* and Mas
 
 \subsection{Distributed Applications}
 \label{sec:distributed-applications}
-A feature of distributed applications is the computation across all nodes. At the same time, a single task is executed in parallel on several nodes of a system, and the entire system delivers the result in total. The boundaries between decentralized and distributed networks are becoming blurred. A decentralized network consisting only of servers corresponds quasi to a distributed network.
+A feature of distributed applications is the computation across all nodes (see Figure \ref{fig:architecture-distributed}). At the same time, a single task is executed in parallel on several nodes of a system, and the entire system delivers the result in total. The boundaries between decentralized and distributed networks are becoming blurred. A decentralized network consisting only of servers corresponds quasi to a distributed network.
 
 In distributed applications, there is no hierarchy with servers or clients. Each node is equal to the other nodes with everyone performing the same tasks. For this reason, a node in this architecture is called a peer. The structure is then referred to as \ac{P2P}. With such structures, there are no scaling problems, since each node contributes the required resources itself. Thus, the resources of the entire system grow with each new node added.
 

thesis/content/04-concept/solution-strategy-architecture.tex

@@ -2,19 +2,32 @@ Various models can be used to implement a secure data exchange between the users
 
 \begin{figure}[h!]
 	\centering
-	\includegraphics[width=1.0\textwidth]{solution-strategy-architecture}
-	\caption{Architectures for secure data exchange among users: (a) by the use of an additional server, (b) via a \ac{P2P} network connecting all users or (c) via a hybrid \ac{P2P} network with servers acting as super-peers}
-	\label{fig:solution-strategy-architecture}
+	\begin{subfigure}[c]{0.32\textwidth}
+		\includegraphics[width=\textwidth]{solution-architecture-a}
+		\caption{}
+		\label{fig:solution-architecture-a}	
+	\end{subfigure}
+	\begin{subfigure}[c]{0.32\textwidth}
+		\includegraphics[width=\textwidth]{solution-architecture-b}
+		\caption{}
+		\label{fig:solution-architecture-b}
+	\end{subfigure}
+	\begin{subfigure}[c]{0.32\textwidth}
+		\includegraphics[width=\textwidth]{solution-architecture-c}
+		\caption{}
+		\label{fig:solution-architecture-c}
+	\end{subfigure}
+	\caption{Architectures for secure data exchange among users: (a) by the use of an additional server, (b) via a \ac{P2P} network connecting all users or (c) via a hybrid \ac{P2P} network with servers acting as super-peers.}
 \end{figure}
 
-One possibility is to use an extra infrastructure to store the data, as shown in Figure \ref{fig:solution-strategy-architecture}.a. An additional server stores and distributes the private data to be protected. Using a server has the advantage that the data are always available and there are no dependencies to other hybrid \ac{OSN} users. Furthermore, resources only have to be available centrally and not locally on the user's device. At the central location, the data can be indexed and explicitly queried. However, the operation and maintenance of one or more servers are problematic. In principle, the question for the service provider has to be clarified, because the reliability of the infrastructure is essential. FaceCloak (see Chapter \ref{sec:facecloak}) used an architecture based on this structure.
+One possibility is to use an extra infrastructure to store the data, as shown in Figure \ref{fig:solution-architecture-a}. An additional server stores and distributes the private data to be protected. Using a server has the advantage that the data are always available and there are no dependencies to other hybrid \ac{OSN} users. Furthermore, resources only have to be available centrally and not locally on the user's device. At the central location, the data can be indexed and explicitly queried. However, the operation and maintenance of one or more servers are problematic. In principle, the question for the service provider has to be clarified, because the reliability of the infrastructure is essential. FaceCloak (see Chapter \ref{sec:facecloak}) used an architecture based on this structure.
 
 Instead of operating a separate, additional server, it would also be possible to use a third-party, existing infrastructure. These include, for example, blockchains or \ac{P2P} file-sharing networks that could be used for data exchange. Since no influence can be exerted on existing infrastructure, its use entails further restrictions and potential risks.
 
-A decentralized solution strategy would create a network among users of the hybrid application (see Figure \ref{fig:solution-strategy-architecture}.b). No extra infrastructure would have to be operated. The users would then have a typical peer role. By using this model, it is difficult to keep data available and accessible even if the user is permanently or temporarily offline. The problem needs to be solved.
+A decentralized solution strategy would create a network among users of the hybrid application (see Figure \ref{fig:solution-architecture-b}). No extra infrastructure would have to be operated. The users would then have a typical peer role. By using this model, it is difficult to keep data available and accessible even if the user is permanently or temporarily offline. The problem needs to be solved.
 Furthermore, the resources on the devices are limited, so that effective and economical solutions are needed. Another challenge is the addressing of peers. Since they typically do not have a static \ac{IP} address, solutions have to be found for accessibility. Since there is no central, global index, finding data is even more difficult.
 
-Adding servers to the \ac{P2P} network would create a hybrid solution (see Figure X). In this model, the servers would take on the role of a super peer, permanently reachable at a fixed address, thus stabilizing the \ac{P2P} network. The problem of data availability could be limited by storing much of the data at super peers. The problem of addressing would also be solved by establishing connections to other peers via the known super peers. However, the problem would remain with the cost and maintenance of the servers.
+Adding servers to the \ac{P2P} network would create a hybrid solution (see Figure \ref{fig:solution-architecture-c}). In this model, the servers would take on the role of a super peer, permanently reachable at a fixed address, thus stabilizing the \ac{P2P} network. The problem of data availability could be limited by storing much of the data at super peers. The problem of addressing would also be solved by establishing connections to other peers via the known super peers. However, the problem would remain with the cost and maintenance of the servers.
 
 Table \ref{tab:solution-strategy-architecture-comparison} lists the advantages and disadvantages of the different strategies for the hybrid \ac{OSN} architecture.
 

thesis/content/05-proof-of-concept/building-block-view.tex

@@ -22,8 +22,14 @@ Infura\footnote{https://infura.io/} is a service that provides access to Ethereu
 
 \subsection{White Box View}
 \label{sec:white-box}
+The Ionic framework uses Angular in the core. Accordingly, the Hybrid \ac{OSN} app is in principle an Angular application. The essential building blocks are components, pages, and providers (see Figure \ref{fig:building-block-view-level1}). In the following, these components are described in detail and examples are given of where they are used in Hybrid \ac{OSN}.
 
-The Ionic framework uses Angular in the core. Accordingly, the Hybrid \ac{OSN} app is in principle an Angular application. The essential building blocks are components, pages, and providers. In the following, these components are described in detail and examples are given of where they are used in Hybrid \ac{OSN}.
+\begin{figure}[h!]
+	\centering
+	\includegraphics[width=1.0\textwidth]{building-block-view-level1}
+	\caption{.}
+	\label{fig:building-block-view-level1}
+\end{figure}
 
 \subsubsection{Providers}
 \label{providers}

thesis/content/05-proof-of-concept/runtime-view.tex

@@ -16,7 +16,7 @@ On the write-tweet page, new tweets can be written and posted using a form. In a
 
 \begin{figure}[h!]
 	\centering
-	\includegraphics[width=1.0\textwidth]{post-tweet-building-block-view}
+	\includegraphics[width=1.0\textwidth]{block-view-write-tweet}
 	\caption{Building block view of the interaction between the different modules when posting a new tweet}
 	\label{fig:post-tweet-building-block-view}
 \end{figure}
@@ -44,7 +44,7 @@ When opening the home page, the logged in user gets the latest tweets of the acc
 
 \begin{figure}[h!]
 	\centering
-	\includegraphics[width=1.0\textwidth]{home-timeline-building-block-view}
+	\includegraphics[width=1.0\textwidth]{block-view-home-page}
 	\caption{Building block view of the interaction between the different modules when loading the home timeline of a user}
 	\label{fig:home-timeline-building-block-view}
 \end{figure}