# Secure Data Distribution Architecture in IoT Using MQTT
## 2 Problem Statement and Related Works  
The aim of this article is to build an architecture that tackles the issues of cross broker data discovery and dissemination. These problems need to be addressed because without proper data discovery and dissemination MQTT brokers cannot be scaled properly. Therefore, many architectures were proposed in the literature to tackle these two problems. These can be abstractly categorized architectures that require client involvement, those with static topologies and fully peer-to-peer ones. In fixed topology architectures, assumptions about the structure and behavior of the network are made to increase the efficiency of resource utilization [7]. However, such architectures are static by design, therefore, it is difficult to add/remove brokers or migrate clients across brokers at runtime. [PERSON] et al. [8] proposed an MQTT broker architecture for the edge that improves availability while reducing the amount of broadcasting that is performed by the broker. It mainly uses a topic structure that is optimised for geographically distributed IoT applications. Furthermore, [PERSON] et al. [9] explored the use of virtualization technologies to build highly scalable distributed broker clusters. Similarly, [PERSON] et al. [10] proposed a container-based architecture that is designed to scale through decoupling the state of a given broker from its functionality. In architectures that require client involvement, the client is the one responsible for discovering and then connecting to the broker that has the data it needs. The discovery process starts with the client asking its broker about where a certain resource exists in the network. Subsequently, the broker discovers where that resource is either in a peer-to-peer fashion or through a dedicated discovery entity. Upon discovery, the broker redirects the client to that broker which has the resource. Finally, the client connects the broker with the resource as a client to consume that resource. The architecture is illustrated in Figure 1. [PERSON] et al. proposed in [11] that creates multi-cast groups for each topic using an SDN controller which disseminates topic data between brokers through interest information obtained from an assumed root broker. Furthermore, the authors in [12] proposed a Quality of Service (QoS) aware distributed architecture based on MQTT, which is aimed at migrating clients between brokers to enhance performance and achieve desired QoS. [PERSON] et al. [13] proposed an approach for handling the distribution of data at the edge with heterogeneous brokers using an inter-networking layer. This inter-networking layer sits between the end clients and their local brokers at the edge. The authors in [14] proposed a topic management system for MQTT to facilitate the sharing of open data in the context of smart cities. It uses the hierarchical topic model that allows publishers and subscribers to navigate from more generic data to more specific data using a URL-like structure. For example, the topic \"earthquake/west/district9\", would mean that the user is interested in earthquake data coming from District 9 in the west. Furthermore, the subscriber could also subscribe to the more generic topic \"earthquake/west\" to get earthquake data for all districts in the west. The main advantage of this type of architecture is scalability and fault tolerance, because of the following reasons:  
1. Clients directly connect to the brokers that have the resources they need. 2. By design, these architectures implement constructs for client migration which allows for dynamic load balancing and fault tolerance among brokers producing the same resource. Figure 1: Illustration of architectures where the client is involved in the discovery process. However, this type of architecture has the following disadvantages:  
1. The clients have to connect to multiple brokers if the resources they need are scattered. This depletes their resources quickly, especially if they are constrained devices. 2.