# FLINT: Flows for the Internet of Things
## 6 Discussion  
Other platforms, such as INTER-IoT and Eclipse node-wet have been around to provide interoperability in the IoT. However, INTER-IoT has become a rather complex platform that provides multi-layer interoperability for large scale projects. Eclipse node-wet, implemented in Node.js, merely focuses on interoperability, rather than scalability.  
These observations led to the initial design of FLINT with the main objective to interconnect non-interoperable IoT networks that are characterised by intermittent connectivity. FLINT was designed to support five levels of interoperability--syntactic interoperability,  
\begin{table}
\begin{tabular}{c c c c c c c c c} \hline \hline _req/s_ & **4500** & \multicolumn{2}{c}{**10,500**} & \multicolumn{2}{c}{**14,500**} & \multicolumn{2}{c}{**17,500**} & \multicolumn{2}{c}{**All**} \\ \hline  & \(L\) _(s)_ & \(G\) & \(L\) _(s)_ & \(G\) & \(L\) _(s)_ & \(G\) & \(L\) _(s)_ & \(G\) & _Payload size_ (B)_ \\ \hline
**Node-RED (1)** & 0.007 & 0.98 & 11.633 & 0.5 & 20.843 & 0.53 & 26.278 & 0.54 & 259 \\
**Node-RED (6)** & 0.0016 & \(1\) & 0.0008 & 0.99 & 0.0006 & 1 & 0.0007 & 0.99 & 259 \\
**Eclipse Hono** & 0.007 & \(1\) & 0.004 & 0.99 & 0.003 & 0.99 & 0.003 & 0.99 & 259 \\
**FLINT (direct)** & 0.003 & \(1\) & 0.002 & 0.98 & 0.004 & 0.98 & 0.002 & 0.99 & 513 \\
**FLINT (mapper)** & 0.005 & 0.99 & 0.012 & 0.97 & 0.022 & 0.78 & 0.025 & 0.64 & 1102 \\
**FLINT (dummy)** & 0.007 & 0.98 & 0.04 & 0.63 & 0.05 & 0.41 & 0.054 & 0.33 & 1202 \\ \hline \hline \end{tabular}
\end{table}
Table 2: The Latency (L) in seconds, the Goodput (G) and the Payload size in bytes for the evaluated platforms.  
Figure 12: Comparison of a very simple load balancing method. The first configuration runs every component on the same machine, while in the second configuration the broker is moved to a different machine.  
semantic interoperability, device interoperability, network interoperability and platform interoperability. The modularity of the design, consisting of a _sink_ and _agent_, allows the recycling of existing programs through the use of a socket connection, while still being able to scale.  
We implemented FLINT to support our design choices and to show how the implementation behaves against different loads on comparable platforms. Our evaluation showed that Node-RED performs best in terms of latency and goodput. However, this requires to break apart the application in order to take advantage of the available CPU cores of the system. Eclipse Hono and FLINT show similar results. However, due to its flexible design using the _sink_, developers require only little understanding of the underlying protocols and can use any language that supports UDP sockets. Integrating business logic in Eclipse Hono, on the contrary, requires both an AMQP library and understanding of the protocol.  
The evaluation showed that FLINT is able to deliver good performance in a scalable, container based system. However, both the performance evaluation of the _Mapper_ adapter and the resource consumption of the basic load balancing approach show the impact of a single, central message bus. Since every message has to pass through the broker and, if configured, the _Mapper_ adapter, this forms a bottleneck for the system. Therefore, other distributed streaming platforms, such as Apache Kafka or Pulsar can be used in the future to provide support for use cases that require higher data rates.