Runlet: A Cross-platform IoT Tool for Interactive Job Execution Over

Heterogeneous Devices with Reliable Message Delivery

Vandr

e Leal C

andido

and Fl

avio de Oliveira Silva

Faculty of Computing, Federal University of Uberl

andia, Brazil

Keywords:

Runlet, Internet of Things, AMQP, RabbitMQ, Interactivity, Reliability.

Abstract:

IoT uses different hardware and software components in a mixed environment, and for the management of

the devices, interoperability and reliability are key issues. Interactive job execution is another important con-

cept for the management in different scenarios. The literature lacks a tool with such characteristics. This

work ﬁlls the gap in the state-of-the-art by introducing a tool that achieves interactive job execution over a

network of heterogeneous devices with reliable message delivery. The tool leverages the power of the pro-

tocol Advanced Message Queuing Protocol (AMQP) and the message broker RabbitMQ. AMQP is an open

standard Machine-to-Machine (M2M) publish/subscribe messaging protocol optimized for high-latency and

unreliable networks that enables client applications to communicate with conforming messaging middleware

brokers. RabbitMQ is an open-source message broker that supports various message protocols. The architec-

ture of Runlet is discussed in detail, including the reasoning behind architectural decisions. The evaluation

is conducted through an experimental approach that assesses interactivity and reliability on a testbed of de-

vices composed of single-board ARM computers and laptop devices. The experimental results show that the

application offers interactivity under different scenarios and provides reliable message delivery after node and

server failures.

1 INTRODUCTION

The heterogeneous and dynamic nature of the Inter-

net of Things (IoT) creates challenges that go beyond

the traditional computer-based network model. These

challenges are commonly related to the unpredictable

mixture of devices with individual capabilities that

may pose a barrier to achieving interoperability and

managing devices in the context of IoT (Elkhodr et al.,

2016).

The IEEE describes interoperability as “the abil-

ity of two or more systems or components to ex-

change information and to use the information that

has been exchanged” (Geraci et al., 1991). Achiev-

ing interoperability is indispensable for devices across

different networks and a difﬁcult task given the IoT’s

competitive nature and rapidly evolving wireless tech-

nologies. This commonly results in integration is-

sues where heterogeneous devices cannot communi-

cate with one another (Elkhodr et al., 2016).

In addition to that, IoT solutions need to handle

unique management scenarios that go beyond the tra-

https://orcid.org/0000-0001-7737-8878

https://orcid.org/0000-0001-7051-7396

ditional capabilities of remote control, monitoring,

and maintenance of devices. For example, a sys-

tem that supports remote monitoring of tasks across

a ﬂeet of heterogeneous devices may highly beneﬁt

from a tool that offers the ability to monitor and trou-

bleshooting errors in real-time.

This work ﬁlls the gap in the state of the art by pre-

senting a tool that achieves interactive job execution

over a network of heterogeneous devices with reliable

message delivery. The tool, named Runlet, grants the

user the capability of interacting with the shell from

any connected device during job execution, which is

particularly useful in a scenario that requires user in-

put for successful script execution. A few potential

use areas include Continuous Integration (CI), Con-

tinuous Delivery (CD), and remote monitoring and

management of devices.

Runlet is a cross-platform application that runs

across many architectures and operating systems. It

uses both the protocol AMQP and the broker Rab-

bitMQ for reliable message delivery. The protocol

AMQP is an open standard M2M publish/subscribe

messaging protocol optimized for high-latency and

unreliable networks that enables client applications to

260

Cândido, V. and Silva, F.

Runlet: A Cross-platform IoT Tool for Interactive Job Execution Over Heterogeneous Devices with Reliable Message Delivery.

DOI: 10.5220/0010467702600267

In Proceedings of the 11th International Conference on Cloud Computing and Services Science (CLOSER 2021), pages 260-267

ISBN: 978-989-758-510-4

communicate with middleware brokers. RabbitMQ

is an open-source lightweight message broker that

supports various messaging protocols and can be de-

ployed on-premises and in the cloud.

An experimental evaluation assesses interactivity

and reliability on a testbed of heterogeneous devices

ranging from single-board ARM computers to laptop

devices. The results show that Runlet is interactive

under different use cases and that message delivery is

reliable after node and server failures.

This paper is organized as follows. Section 2 eval-

uates the related work. Section 3 describes the ap-

plication and the reasoning behind architectural deci-

sions. Section 4 describes the experimental evaluation

used to evaluate interactivity and reliability. Finally,

Section 5 presents our conclusions.

2 RELATED WORK

There are several studies that evaluate messaging pro-

tocols and distributed message brokers. However, to

the best of our knowledge, there is no other academic

study pursuing the goal of performing interactive job

execution across a ﬂeet of network devices with reli-

able message delivery.

A selection of academic studies is presented next,

ranging from monitoring systems to surveys that eval-

uate messaging protocols and message brokers. How-

ever, no mention is made of interactive job execution

in none of the studies.

(Krishna and Sasikala, 2019) introduces a health-

care monitoring system that monitors patients’ vitals

in real-time and sends the information to a web server

for persistence and decision-making. Sensors are con-

nected to a Raspberry Pi that acts as a gateway and

sends the data to a server using AMQP through the

board’s Wi-Fi.

(Liang and Chen, 2018) introduces the design of a

real-time data acquisition and monitoring system for

medical data on smart campuses. The design includes

both AMQP and RabbitMQ for data exchanging and

the HL7 protocol to facilitate information manage-

ment via standard-compliant messages. The HL7

standard applies to the exchange of medical records

before different medical systems, which is also the

main difference between this study and (Krishna and

Sasikala, 2019) given that both introduce a similar

concept for healthcare monitoring.

(Kostromina et al., 2018) presents a concept for

a resilient meteorological monitoring system using

AMQP. The system design considers the need for sta-

ble and resilient delivery of data without losses, even

in case of network outages and a predictive monitor-

ing system that monitors memory usage on single-

board computers to prevent system crashes caused

by lack of available memory. RabbitMQ is the se-

lected message broker since it implements the proto-

col AMQP and has features like federation, cluster-

ing, and persistence.

(Krishna and Sasikala, 2019) is the only study that

presents the prototype’s screen captures alongside this

study. Interactive job execution is not applicable in

none of the studies apart from Runlet, which is further

motivation for conducting this study.

3 RUNLET

This study aims to ﬁll the lack of a tool for interactive

job execution by introducing an interactive job execu-

tion approach with reliable message delivery across

heterogeneous devices. The queuing protocol and the

message broker are two key elements discussed in this

section, which also details the architecture and rea-

soning behind technology choices.

Runlet is a cross-platform application that features

a daemon and a desktop manager. The desktop man-

ager includes both the daemon and a full-featured

GUI that provides an easy to use interface for manag-

ing jobs across a ﬂeet of connected devices. The Ad-

vanced RISC Machine (ARM) distribution supports

ARMv6, ARMv7, and ARM64.

Next, we present the reasoning and choices for the

queuing protocol and the message broker. In the se-

quence, we present Runlet’s architecture.

3.1 The Queuing Protocol

CoAP and XMPP protocols are discarded due to some

of their characteristics described in the previous chap-

ter. XMPP does not provide any Quality of Ser-

vice (QoS) options (Dhas and Jeyanthi, 2019), which

makes the protocol not suitable for Runlet, ensuring

reliable message delivery is a crucial aspect of the

application. CoAP seems like a great option from

a resource usage and network bandwidth standpoint.

However, it is discarded due to its lack of support

for the publish/subscribe model (Karagiannis et al.,

2015). The publish/subscribe model is a must-have

for reaching optimal performance as job logs are up-

dated continuously.

MQTT is an excellent option and very similar to

AMQP in many aspects. They both have brokered ar-

chitectures, support the publish/subscribe model, use

TCP for transport and TLS/SSL for security, offer

QoS levels for reliability, with MQTT having the ad-

vantage of smaller header size (Dhas and Jeyanthi,

Runlet: A Cross-platform IoT Tool for Interactive Job Execution Over Heterogeneous Devices with Reliable Message Delivery

261

2019). However, extra features provided by AMQP

made the trade-off advantageous despite the increased

overhead and latency. AMQP has the advantage

of having ﬂexible message routing, reliable message

queues with ﬁne-grained control over bindings, and

multiple types of exchanges (AMQP, 2020). After

a detailed analysis of the different protocols, we se-

lected the AMQP protocol.

3.2 The Message Broker

RabbitMQ is the selected broker for the following rea-

sons (RabbitMQ, 2020):

• Web management UI for short-term metric col-

lection and monitoring offers many administrative

features convenient for development.

• Built-in support for using long-term metric visu-

alization tools such as Prometheus and Grafana in

production.

• Concise documentation and tutorials.

• Feature ﬂag subsystem for upgradability.

ActiveMQ Artemis also comes with a web manage-

ment console, supports metric tools, and has well-

organized documentation and active community (Ac-

tiveMQ, 2020). Nonetheless, the decision ultimately

came down to a personal preference for RabbitMQ’s

management tool and built-in support to Prometheus

and Grafana in production. Qpid Broker-J and Qpid

C++ Broker, on the other hand, fall short on develop-

ment tools and lack support for metrics (Qpid, 2020).

The Qpid community is also not as active and engaged

as both RabbitMQ and ActiveMQ communities.

3.3 Architecture

This section details the conceptual architecture com-

posed of the following components: GUI, daemon,

server, database, and cloud storage. Fig. 1 shows the

conceptual architecture and communication ﬂow be-

tween components.

3.3.1 GUI

The Graphical User Interface (GUI) is a cross-

platform application that runs on all major operat-

ing systems such as Mac, Linux, and Windows. It

provides a friendly interface for the management and

monitoring of devices and applies reactive program-

ming concepts to observe, compute, and react to

changes.

The GUI is built with JavaScript, HTML, and CSS

on top of well-adopted open-source libraries such

as Electron, React, TypeScript, MobX, Blueprint,

Figure 1: Runlet Conceptual Architecture.

Xterm.js, and Jest. Electron is a library developed

by GitHub for building cross-platform desktop appli-

cations by combining Chromium and Node.js into a

single runtime environment system (Electron, 2020).

Chromium is used for rendering pages, while the

Node.js API is used for lower-level system actions

such as managing process events and interacting with

the ﬁle system.

3.3.2 Daemon

The daemon, written in Golang, is responsible for job

orchestration and has an internal queue that executes

jobs in the received order, ’First In, First Out’ (FIFO),

as well as a parallelism controller that helps to prevent

CPU throttling by limiting the number of jobs that run

in parallel. It runs on machine startup as a background

process capable of recovering from crashes through a

process restart.

Each daemon communicates with the server di-

rectly. It acts both as a producer and a con-

sumer simultaneously, meaning that jobs are trig-

gered and executed from any active node in the net-

work. It supports the execution of selected methods

via Command-Line Interface (CLI) by appending the

term runlet to method names, which is useful for

script automation and remote access on devices with-

out a graphical interface.

CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science

262

The daemon is also responsible for End-to-End

Encryption (E2EE) of logs, local disk persistence, and

data dispatch for cloud storage. Logs are ﬁrst en-

crypted and persisted on the local disk for quick ac-

cess and then submitted to the cloud storage server.

Logs are only retrieved from the cloud when the local

copy is outdated, according to the rules:

1. If the Log Does Not Exist Locally: a local copy

is created from the remote copy and used for read-

ing operations.

2. If Log Exists Locally: the hash of the local copy

is sent to the server and compared with the hash

present in the metadata of the remote copy. The

remote copy replaces the hash’s local copy if it is

different, and the remote copy has a more recent

modiﬁcation date. Otherwise, the local copy is

used for reading operations, avoiding unnecessary

updates.

3.3.3 Database

Runlet uses PostgreSQL, an open-source object-

relational database that uses the Structured Query

Language (SQL) language and is highly scalable both

in the amount of data it can manage and in the number

of concurrent users it accommodates (PostgreSQL,

2020). The database stores data from users and jobs.

It also provides relational operators to manipulate

data, is highly scalable in terms of data it can store

and supports many concurrent users.

However, the database does not store job logs.

They are shared between devices using RabbitMQ’s

messaging system. This decision reduces security

concerns related to leakage of sensitive information

that records may have and improves performance by

ensuring that updates are queued and delivered reli-

ably without the need for querying and storing large

amounts of data from a database.

3.3.4 Cloud Storage

A cloud-based solution is used exclusively for log

storing. This eliminates ownership costs associated

with managing a data storage infrastructure and en-

sures data durability, availability, and security.

Log storing is accomplished with MinIO, an open-

source distributed object storage server designed to be

cloud-native, performant, scalable, and lightweight.

The server runs as lightweight containers by external

orchestration services and is highly efﬁcient in its use

of CPU and memory resources (MinIO, 2020).

3.3.5 Server

The server is the central point of the architecture and

consists of a NestJS API, a RabbitMQ message bro-

ker, and metric tools Prometheus and Grafana for

monitoring. It orchestrates the communication be-

tween daemons and the message broker through an

API, persists data in the database, and ﬁles in the

cloud.

RabbitMQ is the message broker that handles

message exchanging between network devices. It has

two subcomponents: (1) a server operator where all

broker features are conﬁgurable, such as clustering,

high availability, persistence, and access control; and

(2) a web-based tool for external management, moni-

toring, and short-term visualization of broker events.

A topic exchange is created for each user. This

type of exchange is used for multicast routing of mes-

sages as it routes messages to one or many queues

bound with a matching binding key. All exchanges

are durable and survive broker restart. On the other

hand, queues are temporary and short-lived to re-

duce workload and avoid leaving unused queues be-

hind failed connections. They are both exclusive, and

auto-deleted, meaning that they are only used by their

declaring connections and are automatically deleted

when the last consumer is gone or cancels its sub-

scription.

Queues are also created following the single re-

sponsibility principle that dictates that each queue has

a single concern. That means that jobs end up having

multiple queues to control execution rather than hav-

ing a single queue for everything.

4 EXPERIMENTAL EVALUATION

This section describes the experiments that evaluate

Runlet in regards to interactivity and reliability. The

server, currently hosted on DigitalOcean, is a stan-

dard droplet with two (2) vCPUs, four (4) GB RAM,

ﬁfty (50) GB SSD storage, and four (4) TB of data

transfer. A vCPU is a processing power unit that cor-

responds to a single hyperthread on a processor core

(DigitalOcean, 2020). The testbed of devices used

for the experiments is presented in table 1, including

device model, CPU, RAM, operating system, and a

nickname used for study reference.

4.1 Interactivity

Two (2) experiments are conducted to evaluate the

user’s capability to interact with job executions and

make decisions when requested.

Runlet: A Cross-platform IoT Tool for Interactive Job Execution Over Heterogeneous Devices with Reliable Message Delivery

263

Table 1: Testbed Devices.

Nickname Device Model CPU RAM Operating System

win Dell G5

Intel Core i7-9750H

@ 2.60GHz

16GB Windows 10

mac

Macbook Pro

Late 2013

Intel Core i5-4288U

@ 2.60GHz

8GB macOS Catalina 10.15.3

pi-1

Raspberry Pi

Model B Rev 2

Broadcom BCM2835

ARMv6 @ 700MHz

512MB Raspbian GNU/Linux 10

pi-2

Raspberry Pi 2

Model B Rev 1.1

Broadcom BCM2836

ARMv7 @ 900MHz

1GB Raspbian GNU/Linux 10

pi-3

Raspberry Pi 3

Model B Plus Rev 1.3

Broadcom BCM2837B0

ARMv7 @ 1.4GHz

1GB Raspbian GNU/Linux 9.11

The ﬁrst experiment veriﬁes the ability to trigger

a macOS job from a Windows manager. The job

is called brew-cask-upgrade and executes two com-

mands: (1)neofetch and (2) brew cu -a. neofetch

is a command-line system tool written in bash that

displays information about the operating system and

hardware (dylanaraps, 2020). brew cu -a is a com-

mand from a brew-cask-upgrade tool, a command-

line tool for upgrading outdated apps installed by

Homebrew Cask (buo, 2020). Homebrew Cask is a

tool that extends Homebrew and is used for instal-

lation and management of macOS applications dis-

tributed as binaries (Homebrew, 2020).

The second experiment shows how a Raspberry PI

can be remotely monitored using htop, which is an in-

teractive text-mode process viewer for Unix systems

(Muhammad, 2020). This viewer is highly conﬁg-

urable and gives the option to view information such

as CPU load, memory consumption, hostname, tasks,

load averages, and uptime.

4.2 Reliability

Reliability stands for the system’s ability to deliver

queued messages after failures. This study investi-

gated two types of failures: (1) node failure and (2)

server failure.

1. Node Failure: the number of nodes in the clus-

ter is downscaled from four (4) nodes to a single

node. This change does not cause any issues as

RabbitMQ tolerates individual nodes’ failure as

long as there are other known nodes in the clus-

ter at the time. It may also not affect queues as

the current infrastructure uses queue mirroring to

replicate queues across nodes.

2. Server Failure: the single node is removed for

a brief period to observe how the broker reacts in

the absence of nodes. It does not cause any signiﬁ-

cant issues to the server apart from becoming tem-

porarily unavailable as the broker is conﬁgured to

use lazy queues, a policy that moves messages

from a large number of queue types to disk as

early as possible and loads them in memory only

when requested. These messages are expected to

be retrieved from the disk after new nodes become

operational. All queues are also likely to return.

4.3 Discussion

This section describes the results obtained from ex-

periments. The results presented throughout this sec-

tion are supported by screenshots of executed jobs and

metrics from Prometheus and Grafana.

4.3.1 Interactivity

The ﬁrst experiment triggers a job on a Windows

desktop manager to update system applications on a

macOS device using homebrew. Fig. 2 shows the

output of command (1) neofetch.

Figure 2: Output of (1) neofetch.

Fig. 3 shows an excerpt of the output generated by

(2) brew cu -a. The initial output lists all installed ap-

CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science

264

Figure 3: Output of (2) brew cu -a before conﬁrmation [y].

Figure 4: Output of (2) brew cu -a after conﬁrmation [y].

plications, including current and latest versions, and

a list of outdated apps. The option -a passed with

brew cu indicates that applications with the auto-

update functionality are also listed. The question ”Do

you want to upgrade 7 apps or enter [i]nteractive

mode [y/i/N]?” is shown after the list of outdated apps

and requires user interaction. Fig. 4 shows an ex-

cerpt of the upgrading process that takes place after

user conﬁrmation [y]. The progress of each upgrade

is displayed individually, which helps to visualize the

overall progress.

Figure 5: Initial output of htop.

Figure 6: htop setup results for keyword ’runlet’.

The second experiment triggers a job on a Windows

desktop manager to display running processes of a

Raspberry PI using htop. Fig. 5 shows the initial out-

put of htop, which is a list of system processes includ-

Runlet: A Cross-platform IoT Tool for Interactive Job Execution Over Heterogeneous Devices with Reliable Message Delivery

265

ing PID, user, percentage of CPU and memory used,

virtual memory, and time in execution. The bottom

bar has all the options that are available through func-

tion keys.

Fig. 6 shows all the options available under setup

when the key F2 is pressed. These options can cus-

tomize meters shown at the top and change display

options, colors, and active columns. Navigation using

arrow keys is done with no hassle as Runlet can cap-

ture all keyboard strokes. The key F10 can be pressed

at any time to indicate that the setup is done and return

to the previous screen.

4.3.2 Reliability

Reliability is investigated by observing the broker’s

behavior considering two failure events. The impact

is observed through a Grafana dashboard that moni-

tors the following metrics using Prometheus:

• Total number of nodes, queues, connections, and

channels.

• Per-node memory available.

• Messages published, delivered, and routed to

queues in a per-node and per-second granularity.

• Total number of queues, channels, and connec-

tions per node per second.

The ﬁrst experiment investigates how the broker be-

haves to node failure by changing the cluster compo-

sition from four (4) nodes to a single node at about

16:15. Figure 7 shows that all messages, queues,

channels, and connections are kept in the remaining

node after removing three (3) nodes, meaning no mes-

sages are lost.

Grafana may use different colors to indicate the

same node across graph panels. For example, green

is designated for node one (1) on messages published,

delivered, and routed to queues, while yellow is des-

ignated to the same node for total queues, channels,

and connections.

A slight increase in memory consumption happens

on the remaining node as it starts to handle all the

load. The difference between the number of messages

published and routed to queues for delivery may be

attributed to messages routed to multiple queues. The

number of queues, channels, and connections varies

according to the workload of messages.

The second experiment investigates how the bro-

ker reacts to a server fail by removing the only active

node at about 16:25. Figure 8 shows that messages

stop being transmitted for about 5 minutes during the

fail, but the process resumes as soon as the node joins

the cluster again to take over. The node establishes all

the old connections and recovers persisted messages

Figure 7: Cluster after node failure.

Figure 8: Cluster after server failure.

and queues, resulting in no lost messages. The num-

ber of channels drops signiﬁcantly as previous con-

nections and channels are closed. Grafana changes

the color from yellow to green to differentiate in-

stances of the same node.

5 CONCLUSIONS

This study introduces a tool that achieves interactive

job execution across heterogeneous devices using the

protocol AMQP and the message broker RabbitMQ.

CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science

266

The approach ﬁlls a gap in the state-of-the-art, as con-

ﬁrmed by the ﬁndings in section 2. A few potential

use areas include Continuous Integration (CI), Con-

tinuous Delivery (CD), and remote monitoring and

management of devices.

The protocol AMQP was selected due to its ﬂex-

ible message routing, reliable message queues, and

multiple exchange types. The message broker Rab-

bitMQ was selected based on a personal preference

for the built-in web management tool and support for

Prometheus and Grafana. This combination proved

very useful in the experimental evaluation as the bro-

ker could recover messages and queues after node and

server failures with no messages lost.

The architecture and motivation behind architec-

tural decisions are discussed in detail in section 3, in-

cluding a conceptual view that introduces all the com-

ponents. The experimental evaluation is conducted in

section 4. It shows that interactive job execution on

heterogeneous devices is achieved under various sce-

narios and that message delivery is reliable even after

node and server failures.

The application has been released on GitHub and

is easily found over the internet. The website with

more information is available at https://runlet.app.

The roadmap for future work includes an exper-

imental evaluation to benchmark scalability by mea-

suring message throughput and latency as the network

grows. Also, the analysis of the security measures that

are put in place to ensure data protection from cyber-

attacks.

REFERENCES

ActiveMQ, A. (2020). Apache activemq. https://activemq.

apache.org. [Online; accessed 15-December-2020].

AMQP (2020). Advanced message queuing protocol. https:

//www.amqp.org. [Online; accessed 15-December-

2020].

buo (2020). homebrew-cask-upgrade. https://github.com/

buo/homebrew-cask-upgrade. [Online; accessed 15-

December-2020].

Dhas, Y. J. and Jeyanthi, P. (2019). A review on internet

of things protocol and service oriented middleware.

In 2019 International Conference on Communication

and Signal Processing (ICCSP), pages 0104–0108.

IEEE.

DigitalOcean (2020). Droplets. https://www.digitalocean.

com/products/droplets. [Online; accessed 15-

December-2020].

dylanaraps (2020). neofetch. https://github.com/

dylanaraps/neofetch. [Online; accessed 15-

December-2020].

Electron (2020). Electron. https://electronjs.org. [Online;

accessed 15-December-2020].

Elkhodr, M., Shahrestani, S., and Cheung, H. (2016).

The internet of things: new interoperability, man-

agement and security challenges. arXiv preprint

arXiv:1604.04824.

Geraci, A., Katki, F., McMonegal, L., Meyer, B., Lane,

J., Wilson, P., Radatz, J., Yee, M., Porteous, H.,

and Springsteel, F. (1991). IEEE standard computer

dictionary: Compilation of IEEE standard computer

glossaries. IEEE Press.

Homebrew (2020). homebrew-cask. https://github.com/

Homebrew/homebrew-cask. [Online; accessed 15-

December-2020].

Karagiannis, V., Chatzimisios, P., Vazquez-Gallego, F., and

Alonso-Zarate, J. (2015). A survey on application

layer protocols for the internet of things. Transaction

on IoT and Cloud computing, 3(1):11–17.

Kostromina, A., Siemens, E., and Yurii, B. (2018). A con-

cept for a high-reliability meteorological monitoring

system using amqp. In Titel: Proceedings of the 6th

International Conference on Applied Innovations in

IT. Bibliothek, Hochschule Anhalt.

Krishna, C. and Sasikala, T. (2019). Healthcare monitoring

system based on iot using amqp protocol. In Interna-

tional Conference on Computer Networks and Com-

munication Technologies, pages 305–319. Springer.

Liang, Y. and Chen, Z. (2018). Intelligent and real-time data

acquisition for medical monitoring in smart campus.

IEEE Access, 6:74836–74846.

MinIO (2020). Minio. https://min.io. [Online; accessed

15-December-2020].

Muhammad, H. (2020). htop. https://hisham.hm/htop. [On-

line; accessed 15-December-2020].

PostgreSQL (2020). Postgresql. https://www.postgresql.

org. [Online; accessed 15-December-2020].

Qpid, A. (2020). Apache qpid. https://qpid.apache.org.

[Online; accessed 15-December-2020].

RabbitMQ (2020). Rabbitmq. https://www.rabbitmq.com.

[Online; accessed 15-December-2020].

Runlet: A Cross-platform IoT Tool for Interactive Job Execution Over Heterogeneous Devices with Reliable Message Delivery

267