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 web application has been created that provides an
-interactive management console for the \gls{mTask} system. This interface
-provides functionality to list \glspl{SDS}, add and remove \glspl{Task},
-administrate devices and view the state of the system.
-
-\subsection{Device Specification}
-The server stores a description for every device available in a record type.
-From the macro settings in the interface file, a profile is created that
-describes the specification of the device. When the connection between the
-server and a client is established, the server will send a request for
-specification. The client serializes its specification and send it to the
-server so that the server knows what the client is capable of. The exact
-specification is shown in Listing~\ref{lst:devicespec} and stores the
-peripheral availability, the memory available for storing \glspl{Task} and
-\glspl{SDS} and the size of the stack. Not all peripheral flags are shown for
-brevity. The encoding for this interface
-
-\begin{lstlisting}[label={lst:devicespec},
- caption={Device specification for \gls{mTask}-\glspl{Task}}]
-:: MTaskDeviceSpec =
- { haveLed :: Bool
- , haveLCD :: Bool
- , have...
- , bytesMemory :: Int
- , stackSize :: Int
- , aPins :: Int
- , dPins :: Int
- }
-\end{lstlisting}
+managing devices, \glspl{Task} and \glspl{SDS} are available. Furthermore, an
+interactive web application has been created that provides an interactive
+management console for the \gls{mTask} system. This interface provides
+functionality to list \glspl{SDS}, add and remove \glspl{Task}, administrate
+devices and view the state of the system.
\subsection{Device Storage}
Everything that a device encompasses is stored in the \CI{MTaskDevice} record
-type. This includes management for the \glspl{SDS} and \glspl{Task} stored on
-the device. The \CI{MTaskDevice} definition is shown in
-Listing~\ref{lst:mtaskdevice} accompanied with the necessary classes and sub
-types.
+type which is in turn stored in a \gls{SDS}. This includes management for the
+\glspl{SDS} and \glspl{Task} stored on the device. The \CI{MTaskDevice}
+definition is shown in Listing~\ref{lst:mtaskdevice} accompanied with the
+necessary classes and sub types. Devices added to the system must be reachable
+asynchronously. This implicates that the programmer only needs to keep hold of
+the reference to the device and not the actual device record.
\begin{lstlisting}[caption={Device type},label={lst:mtaskdevice}]
:: Channels :== ([MTaskMSGRecv], [MTaskMSGSend], Bool)
-:: BCState = ... // Compiler state, explained in later sections
+:: BCState = ... // Compiler state, explained in later sections
+:: MTaskDeviceSpec = ... // Also explained in later sections
+:: MTaskMSGRecv = ... // Message format, explained in later sections
+:: MTaskMSGSend = ... // Also explained in later sections
:: MTaskResource
= TCPDevice TCPSettings
| SerialDevice TTYSettings
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}}.
+The implementation and semantics for the \CI{MTaskMSGRecv} and
+\CI{MTaskMSGSend} types is given in Section~\ref{sec:communication}.
Besides all the communication information, the record also keeps track of the
\glspl{Task} currently on the device, the compiler state (see
format are explained in the following section.
\subsection{Shares}
+\Glspl{SDS} on the device are synchronized in the server and thus stored both
+on the server and on the client. In this way the communication is kept to the
+bare minimum because no communication with the device is needed for a
+\gls{SDS} read operation. In this case the \gls{Task} requesting can just be
+provided with the synchronized value. As mentioned before, the device has to
+explicitly publish an update. This has the implication that the server and the
+client can get out of sync. However, this is not a problem since it is well
+documented and by design.
+
+% TODO
The system keeps track of the \glspl{SDS} stored on the client in a big
\gls{SDS} containing a list of devices. Client-\glspl{SDS} can be stored on one
device at the same time. This means that if an \gls{SDS} updates, everyone
repositories / msc-thesis1617.git / blobdiff