![](bg4.png)
as indicated by the text Tor Address in the figure.
These hashes are unique and identify components.
The client is periodically polling the server for in-
formation and instructions to be executed on the mi-
cro computing system. All communication is initi-
ated by the client and targeted outwards of the net-
work. The server provides work instructions as work
instruction packages in a queue, which is synchro-
nised with an information storage component to en-
sure the consistency of instructions. Conceptually,
the work instruction packages are self-contained com-
pressed packages, that are cryptographically signed
and encrypted. In these packages, the required in-
structions, software, and data can be included, thus,
enabling function shipping.
Fig. 3 depicts the composition and distribution of
the components of the system. The DeploySupport
component consists of BASH scripts, that facilitate in-
stallation and configuration of the client system on the
micro computing system. These components are de-
scribed in the following at a high level.
The installer acquires an image of the latest Arch-
Linux OS distribution and prepare a storage medium
for use in the micro computing system with it. In our
case, this storage medium is an SD-card. Alterna-
tive deployment strategies and mechanisms, such as
Tosca4IoT (Ebner et al., 2017), can be used to deploy
the system onto the micro computing system. For fur-
ther iterations of this software, the extension and us-
age of alternative, automated and controlled, deploy-
ment strategies and mechanisms is intended.
4.2 Prototypical Implementation
Conceptually the client is created from one central,
continually running loop, which checks for internal
state, such as connectivity and utilisation, and per-
forms subsequent actions.
The initial action of the client, prior to entering
the control loop, hardens its execution environment to
make it more robust against attacks.
The following action of the client checks for the
required binaries and scripts in the respective paths
of the operating system. In case the required binaries
and scripts are unavailable, the execution of the client
is terminated. If all required software is present, then
the configuration information is processed. Configu-
ration information is stored locally to enable consis-
tent utilisation over reboots and system interruptions.
The configuration consists of information such as a
unique identifier, the remote endpoints and encryption
components. The main loop of the client repeatedly
checks the following information in the specific order:
• Status of the client daemon itself; checking if the
client software is still running on the system and
if the watchdog is present. The client watchdog
is a component to prevent the client from hanging
and restarts the system in case of aborts or errors.
• Connectivity; checking the connectivity of the
system in general, i. e., checking if a network con-
nection is established, if name resolution can be
performed, if certain hosts on the Internet are
reachable and if the central server can be con-
nected with.
• Remaining disk space and space utilisation;
Checking if sufficient disk space for the down-
loading of work instruction packages is available.
In case the disk space is low and insufficient, fur-
ther execution, i. e., fetching of instructions, is
paused and this status is communicated with the
central server.
In case the periodic checks are completed suffi-
ciently, the client polls the central server for work.
This polling for work queries a specific RESTful end-
point and the result of this poll is either the infor-
mation that currently no work is expected to be per-
formed or information on the number of work pack-
ages and logical location of the work packages. If the
client has work to perform, the information on the ex-
isting work packages is used to query for the work
packages on another specific RESTful endpoint. The
work package is then transferred over an encrypted
HTTP transport over Tor and stored locally. The work
package is decrypted, deflated and checked for in-
tegrity and correctness. In case the correctness and
integrity checks are sufficient, the work package is
deployed into a jailed environment, for additional se-
curity, and executed. During the execution, the output
of the work package is acquired and, alongside, the
resulting information of the work package, stored for
historical and analytical purposes. This information
is submitted to the server with additional information.
The client execution environment then cleans the tem-
porary and execution folders to avoid space issues and
data leakages.
Independent of this main loop there is a secondary
loop executed periodically. This secondary loop ac-
quires status information on the host operating system
and the micro computing system in general and sub-
mits this information to the central server which can
be considered health data. This data includes infor-
mation on the system’s uptime, its CPU and memory
utilisation, the status of network adapters and mem-
ory devices. It is executed completely independent of
the main loop.
As depicted in Fig. 3, the Execution Engine is
part of the client package and executes the acquired
work packages locally. For the execution of the
CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science
30