From: Mart Lubbers Date: Fri, 23 Jun 2017 17:22:42 +0000 (+0200) Subject: results X-Git-Tag: hand-in~61 X-Git-Url: https://git.martlubbers.net/?a=commitdiff_plain;h=ea7fe3a71df1e5a5da335057b956fe69c4718249;p=msc-thesis1617.git results --- diff --git a/introduction.tex b/introduction.tex index 66d6b66..1c72858 100644 --- a/introduction.tex +++ b/introduction.tex @@ -71,12 +71,11 @@ Chapter~\ref{chp:dsl} discusses the pros and cons of different embedding methods to create \gls{EDSL}. Chapter~\ref{chp:mtask} shows the existing \gls{mTask}-\gls{EDSL} on which is extended upon in this dissertation. -Chapter~\ref{chp:arch} shows the architecture used for \gls{IoT}-devices that -are a part of the new \gls{mTask}-system. Chapter~\ref{chp:mtaskcont} shows the extension added to the \gls{mTask}-\gls{EDSL} that were needed to make the system function. -Chapter~\ref{chp:itasksint} shows the integration with \gls{iTasks} that was -built to realise the system. +Chapter~\ref{chp:arch} shows the architecture used for \gls{IoT}-devices that +are a part of the new \gls{mTask}-system. It covers the client software running +on the device and the server written in \gls{iTasks}. Chapter~\ref{chp:conclusion} concludes by answering the research questions and discusses future research. Appendix~\ref{app:communication-protocol} shows the concrete protocol used for diff --git a/results.arch.tex b/results.arch.tex index 0573033..20f0402 100644 --- a/results.arch.tex +++ b/results.arch.tex @@ -206,33 +206,19 @@ available for storing \glspl{Task} and \glspl{SDS} and the size of the stack. } \end{lstlisting} -\subsection{Device Storage} -All devices available in the system are stored in a big \gls{SDS} that contains -a list of \CI{MTaskDevice}s. The exact specification is defined as in -Listing~\ref{lst:mtaskdevice} accompanied with the used classes and types. - -The \CI{deviceResource} component of the record must implement the -\CI{MTaskDuplex} interface that provides a function that launches a \gls{Task} -used for synchronizing the channels. The \CI{deviceTask} stores the -\gls{Task}-id for this \gls{Task} when active so that it can be checked upon. -This top-level task has the duty to report exceptions and errors as they are -thrown by setting the \CI{deviceError} field. All communication goes via these -channels. If the system wants to send a message to the device, it just puts it -in the channels. Messages sent from the client to the server are also placed -in there. In the case of the \gls{TCP} device type, the \gls{Task} is just a -simple wrapper around the existing \CI{tcpconnect} function in \gls{iTasks}. In -case of a device connected by a serial connection, it uses the newly developed -serial port library of \gls{Clean}\footnote{\url{% -https://gitlab.science.ru.nl/mlubbers/CleanSerial}}. +\section{iTasks} +The server part of the system is written in \gls{iTasks}. Functions for +managing devices, \glspl{Task} and \glspl{SDS} have been created to support the +functionality. An interactive application has been created that allows an +interactive management console for the \gls{mTask} system. This interface +provides functionality to list \glspl{SDS}, add \glspl{Task}, remove +\glspl{Task}, administrate devices and view the state of the system. -Besides all the communication information, the record also keeps track of the -\glspl{Task} currently on the device, the compiler state (see -Section~\ref{sec:compiler}) and the according \glspl{SDS}. Finally, it stores -the specification of the device that is received when connecting. All of this -is given in Listing~\ref{lst:mtaskdevice}. The definitions of the message -format are explained in the following section. Specialized shares are available -per device. The internal mechanism for this is given in -Chapter~\ref{chp:itasksint}. +\subsection{Device Storage} +All devices that have been connected to the server are stored in a \gls{SDS}. +The \gls{SDS} contains a list of \CI{MTaskDevice}s. The \CI{MTaskDevice} +definition is shown in Listing~\ref{lst:mtaskdevice} accompanied with the used +classes and types. \begin{lstlisting}[caption={Device type},label={lst:mtaskdevice}] deviceStoreNP :: Shared [MTaskDevice] @@ -261,16 +247,29 @@ class MTaskDuplex a where synFun :: a (Shared Channels) -> Task () \end{lstlisting} -\section{iTasks} -The server part of the system is written in \gls{iTasks}. Functions for -managing devices, \glspl{Task} and \glspl{SDS} have been created to support the -functionality. An interactive application has been created that allows an -interactive management console for the \gls{mTask} system. This interface -provides functionality to list \glspl{SDS}, add \glspl{Task}, remove -\glspl{Task}, administrate devices and view the state of the system. +The \CI{deviceResource} component of the record must implement the +\CI{MTaskDuplex} interface that provides a function that launches a \gls{Task} +used for synchronizing the channels. The \CI{deviceTask} stores the +\gls{Task}-id for this \gls{Task} when active so that it can be checked upon. +This top-level task has the duty to report exceptions and errors as they are +thrown by setting the \CI{deviceError} field. All communication goes via these +channels. If the system wants to send a message to the device, it just puts it +in the channels. Messages sent from the client to the server are also placed +in there. In the case of the \gls{TCP} device type, the \gls{Task} is just a +simple wrapper around the existing \CI{tcpconnect} function in \gls{iTasks}. In +case of a device connected by a serial connection, it uses the newly developed +serial port library of \gls{Clean}\footnote{\url{% +https://gitlab.science.ru.nl/mlubbers/CleanSerial}}. + +Besides all the communication information, the record also keeps track of the +\glspl{Task} currently on the device, the compiler state (see +Section~\ref{sec:compiler}) and the according \glspl{SDS}. Finally, it stores +the specification of the device that is received when connecting. All of this +is given in Listing~\ref{lst:mtaskdevice}. The definitions of the message +format are explained in the following section. \subsection{Integration} -When the system starts up the devices from the previous execution still +When the system starts up, the devices from the previous execution still residing in the \gls{SDS} must be cleaned up. It might be the case that they contain \glspl{Task}, \glspl{SDS} or errors that are no longer applicable in this run. A user or programmer can later choose to reconnect to some devices. @@ -282,20 +281,21 @@ startupDevices = upd (map reset) deviceStoreNP where reset d = {d & deviceTask=Nothing, deviceTasks=[], deviceError=Nothing} \end{lstlisting} -An image of the management interface is shown in Figure~\ref{lst:manage}. -The system management is done by a single \gls{Task} called \CI{mTaskManager}. -To manage the system, a couple of different functionalities are needed and -are launched. The left sidebar of the interface shows the list of example -\glspl{Task} that are present in the system. When clicking a \gls{Task}, a -dialog opens in which you can select the device to send the \gls{Task} to. The -dialog might contain user specified variables. All example \glspl{mTask} are of -the type \CI{Task (Main (ByteCode () Stmt))} and can thus ask for user input -first. - -The bottom panel shows the device information. In this panel, the devices can -be created and modified. Moreover, this panel allows the user to reconnect with -a device after a restart of the server application. - +The system's management is done through the interface of a single \gls{Task} +called \CI{mTaskManager}. To manage the system, a couple of different +functionalities are needed and are launched. An image of the management +interface is shown in Figure~\ref{lst:manage}. The left sidebar of the +interface shows the list of example \glspl{Task} that are present in the +system. When clicking a \gls{Task}, a dialog opens in which you can select the +device to send the \gls{Task} to. The dialog might contain user specified +variables. All example \glspl{mTask} are of the type +\CI{Task (Main (ByteCode () Stmt))} and can thus ask for user input first if +needed for parameterized \glspl{mTask}. The bottom panel shows the device +information. In this panel, the devices can be created and modified. Moreover, +this panel allows the user to reconnect with a device after a restart of the +server application. + +\todo{redo this image} \begin{figure}[H] \centering \includegraphics[width=\linewidth]{manage} @@ -303,31 +303,42 @@ a device after a restart of the server application. \end{figure} \subsection{Shares} -The architecture of the system needs to keep track of the \glspl{SDS} stored on -the client. \glspl{SDS} can be stored on only one device at the same time. -that also stores the of devices. This means that if a \gls{SDS} updates, -everyone watching it will be notified. This would result in to a lot of -notifications that are not ment to be for the listener. Moreover, when a client -updates the \gls{SDS} this is processed by the connection handler and results -in an update of the real \gls{SDS}. -Finally, the \gls{SDS} of a client must be synchronized with the actual device. -There are several ways of tackling this problem each with their own pros and -cons and their own level of abstraction. - -\begin{itemize} - \item Instantiate an actual \gls{iTasks}-\gls{SDS} for every \gls{SDS} used - in a client. - - \item Instantiate a \gls{iTasks}-\gls{SDS} for every device that stores all - their \glspl{SDS}. - - \item Use only one \gls{iTasks}-\gls{SDS} for all devices. -\end{itemize} +The architecture of the system keeps track of the \glspl{SDS} stored on +the client in the big devices \gls{SDS}. Client-\glspl{SDS} can be stored on +one device at the same time. This means that if a \gls{SDS} updates, everyone +watching it will be notified. This would result in to a lot of notifications +that are not meant for the listener. Moreover, when a client updates the +\gls{SDS} this is processed by the connection handler and results in an update +of the real \gls{SDS}. Finally, the \gls{SDS} of a client must be synchronized +with the actual device. Thus, when an \gls{iTasks}-\gls{Task} writes the +client-\gls{SDS}, it must be propagated to the real device. There are several +ways of tackling this problem each with their own pros and cons and their own +level of abstraction. + +First an actual \gls{iTasks}-\gls{SDS} for every \gls{SDS} used in a client can +be instantiated with one \gls{iTasks}-\gls{Task} listening to the \gls{SDS} and +synchronizing it with the device when an update occured. This approach is very +expensive as it requires a lot of listening \glspl{Task}. + +Improved on this, a single \gls{iTasks}-\gls{SDS} can be created for every +devices that stores the respective \glspl{SDS}. Using the \CI{mapReadWrite} +functions, a single \gls{SDS} per device can be created as a lens that allows +mapping on a single client-\gls{SDS}. However, This approach still requires +\glspl{Task} listening to the \gls{SDS} and when a \gls{SDS} is written, +everyone is notified, even if the \gls{Task} wanted to only watch a single +different \gls{SDS}. + +Ultimately, the current approach --- a single \gls{SDS} for the entire system +--- was explored. To create \glspl{SDS} per device or per client-\glspl{SDS} a +\CI{mapReadWrite} can be used but it suffers the same problem as mentioned +before. Moreover, a \gls{Task} still has to watch the \gls{SDS} and communicate +the client-\gls{SDS} updates to the actual device. Both of these problems can +be solved using a tailor made share heavily depending on parametric lenses. The +type signature of the share then is as listed in Listing~\ref{lst:actualdev}. \begin{lstlisting}[label={lst:actualdev},% - caption={Real types for the device \gls{SDS}}] -deviceStoreNP :: Shared [MTaskDevice] -deviceStore :: RWShared (Maybe (MTaskDevice, Int)) [MTaskDevice] [MTaskDevice] + caption={Device \gls{SDS}}] +deviceStore :: Shared [MTaskDevice] \end{lstlisting} \subsection{Parametric Lenses}