FIxes

Author: Moritz Thomas

chapters/ch09-summary.tex

@@ -12,7 +12,7 @@ \section{Design Concepts}
 \section{Implementation}
 \label{sec:summary-implementation}
 Chapter \ref{chap:implementation} shows an exemplaric implementation of the monolithic design concept discussed in section \ref{sec:design-1} under the working title \enquote{net-riot}. The monolithic design concept was chosen for implementation due to its proven core ideas and its comparatively high maturity. The second example scenario presented in section \ref{sec:example-scenarios} was used for reference because it features a nested communication stack and a corresponding testbed has already been implemented in section \ref{sec:prototype-testing}. For this implementation, Python is used because of its flexibility, low barrier of entry and rich package ecosystem.\\
-Since the reference scenario makes use of the \ac{HTTP}, \ac{WS} and \ac{MQTT} protocols that used \ac{TCP} as an underlying transport protocol, \ac{TCP} gateways are implemented in net-riot as a \ac{MITM} interface that external devices such as \ac{IoT} devices and cloud server can connect to. For \ac{HTTP} (de-)serialization, net-riot implements a custom encoder while for \ac{WS} and \ac{MQTT} existing libraries are used.\\
+Since the reference scenario makes use of the \ac{HTTP}, \ac{WS} and \ac{MQTT} protocols that used \ac{TCP} as an underlying transport protocol, \ac{TCP} gateways are implemented in net-riot as a \ac{MITM} interface that external devices such as \ac{IoT} devices and cloud servers can connect to. For \ac{HTTP} (de-)serialization, net-riot implements a custom encoder while for \ac{WS} and \ac{MQTT} existing libraries are used.\\
 For representation of stacked communication protocols (such as \ac{MQTT} being transported via \ac{WS}), network stacks and state-machines were implemented: network stacks bundle a series of connected pipes that perform operations on messages, such as (de-)serializing and manipulating messages. State-machines allow selecting which network stacks to actively use by binding them to individual states. State-machines regularly evaluate their context and check whether states should be changed dependent on their registered transitions' rules. These ScriptRules execute scripts which can examine and manipulate the states' and state-machines' context information.\\
 A central task left open for implementation by the design concept is the configuration of the proxy application for specific scenarios and the resulting dynamic instantiation and parametrisation of state-machines and network stacks. In net-riot, \ac{JSON} files and schemas were used for configuration specification and validation. Also, a recursive variance of the abstract factory design pattern was implemented for dynamic instantiation of objects defined in the configuration files. Figure \ref{fig:cloc} shows the output of the \enquote{cloc} utility program executed on net-riot's source code.\\
 While net-riot implemented all components required by the scenario it was designed for, bugs in the implementation and challenging debugging ultimately lead to net-riot being unable to operate correctly in the testbed.

chapters/ch10-conclusion.tex

@@ -5,7 +5,7 @@ \chapter{Conclusion}
 %The monolithic design concept proposes a single application that can be deployed on a single machine, thus it is comparatively easy to deployment. This monolithic architecture implies a severe constraint though: the application dictates which programming language or framework may be used for development of extensions and integration of such extensions  may require recompilation and re-redeployment of the whole application.\\
 %Contrary to this, the distributed design concept decouples extensions (and thus, development and deployment thereof) from the central proxy application. Extensions are implemented as separate units and may be run on separate machines independent of the central application. Both parties communicate via \ac{RPC} techniques.\par
 An exemplaric implementation of the monolithic design concept, net-riot, realized core components used for routing, (de-)serializing and transforming \ac{HTTP}, \ac{WS} and \ac{MQTT} packets. Due to bugs in its implementation that affect the stacking of its \ac{MQTT} and \ac{WS} protocol implementations and the lack of time to fix these, net-riot is not operable in the scenario it was designed for yet. However, tests conducted with network stacks incorporating \ac{HTTP} and \ac{WS} communication were successful. While these bugs can most likely be resolved, future effort might instead be better invested in completing the distributed design concept and basing an implementation on it.\\
-Especially the complex runtime behaviour and high amount of abstraction required to design protocol-agnostic interfaces proved to be challenges during the work on this thesis. Therefore, future work on this topic should aim to reduce the impact of these challenges by taking them into account during the development process:
+Especially the complex runtime behaviour and high amount of abstraction required to design protocol-agnostic interfaces, proved to be challenging during the work on this thesis. Therefore, future work on this topic should aim to reduce the impact of these challenges by taking them into account during the development process:
 \begin{itemize}
     \item Flat data-structures and hierarchies can improve the traceability of data flow and thus support debugging.
     \item A contact person that is proficient in penetration testing and familiar with its challenges and requirements should be interviewed and asked for feedback on a regular basis.
@@ -16,7 +16,7 @@ \section{Outlook}
 \label{sec:outlook}
 While the work on this thesis is completed, the project of designing and implementing a modular proxy application for testing \ac{IoT} applications is not. There is a set of opportunities to continue this work:
 \begin{itemize}
-    \item The distributed design concept promises attractive quality attributes attributes such as even better deployment and capabilities and extensibility. Also, its flattened hierarchy of \acp{FSM} and network stacks improve the debugging process. However, it was not fully defined and further work is required to fully define its components and interfaces.
+    \item The distributed design concept promises attractive quality attributes such as even better deployment capabilities and extensibility. Also, its flattened hierarchy of \acp{FSM} and network stacks improve the debugging process. However, it was not finished and further work is required to fully define its components and interfaces.
     \item Consequently, an implementation based on the distributed design concept promises to be more feasible than net-riot's implementation based on the monolithic concept. The barrier of entry to such an implementation is lowered further due to the fact that the separation of proxy application and extensions allows free choice of multiple programming languages, platforms and frameworks for the systems.
-    \item Of course, an evaluation of the usefulness of the modular proxy application is still an interesting endeavour. Whether it is based on the monolithic or the distributed design concept is not relevant since, from a black-box perspective, they perform the same tasks. Therefore future work could either begin at finishing net-riot or finalizing the distributed design concept.  
+    \item Furthermore, an evaluation of the usefulness of the modular proxy application is still an interesting endeavour. Whether it is based on the monolithic or the distributed design concept is not relevant since, from a black-box perspective, they perform the same tasks.
 \end{itemize}