# IoT Helper: A Lightweight and Extensible Framework for Fast-Prototyping IoT Architectures
## 3 System Architecture
In particular, the following limitations are listed:  
* _Performance issues_: The number of messages is directly dependent on the number of nodes in the architecture. Since in a common scenario several applications need to communicate with the embedded system, the latter needs to be able to handle multiple connections at the same time. This can be considered as the normal behavior of high-end servers. However, an embedded system, such as Arduino or Raspberry Pi, has limited concurrent capability. In such systems, every new connection will add considerable overhead to the system, with a result of unacceptable response time, especially in a real-time scenario;
* _Network issues_: In order to establish a direct connection, the embedded system must be reachable from external applications. If we consider a common _donotics_ scenario, the embedded system will be connected to the local wireless network, and it can be easily reached by any other devices connected to the same network. However, to be visible to an external device, such as a smartphone connected through a mobile network, an external public IP address is needed, and the routing table of the local network needs to be properly configured. Both of this steps require complex operations that make the adoption of the system in small or home environments burdensome. To solve these problems, we adopt a Publish and Subscribe (P&S) communication model [21]. The **Message Broker** stands at the core of this protocol by decoupling the involved parties, i.e., the message sender (publisher) from the message receiver (subscriber). The publisher and the subscriber, therefore, do not need to establish direct point-to-point connection. We can either have multiple publishers that publish messages to one subscriber or multiple subscribers that receive messages from one publisher at the same time. The broker is responsible for message routing and distribution. The main benefits of the P&S approach are that the embedded systems do not know any other external application but communicates only with the message broker. Adding new subscribers will not need to modify the publisher's behavior when they join the architecture. In addition, publishers and subscribers do not need to be online and ready simultaneously. Still, the embedded system can publish new data as soon as they are ready without waiting for the clients. This allows achieving better performance in real-timeapplications. Finally, the only component that needs to be reachable is the Message Broker. This can be easily obtained by installing the module on a public server or by using a cloud solution. Message exchanges are performed using _channels_ (also called _queues_ or _topics_). A subscriber asks the broker to be notified when a message is published in a channel. Publishers send messages to channels. The Message Broker module acts as a register of all channels and their subscribers and publishers. Several different implementations of the P&S paradigm can be used to deploy the Message Broker component. One of the most popular is the MQTT open standard [22], a lightweight protocol designed to be efficient even on small micro-controllers. The protocols run over TCP/IP, and messages are optimized to reduce network bandwidth. Popular open-source implementations of MQTTs include Mosquito, HiveMQ, EMQX and VerneMQ [23; 24; 25]. By using one of these implementations, a Message Broker can be deployed on a local server, on virtual private server or even on a low budget device. As an alternative to achieving higher scalability and reducing the maintenance cost of this component, a cloud solution can be adopted.