# Secure Data Distribution Architecture in IoT Using MQTT
## 3 Distributed MQTT Architecture
### Authentication Service
Finally, the results are compared across message sizes. Message Sizes of less than 100 bytes are fairly common in many IoT scenarios such as messages sent by temperature sensors. At around 1000 bytes is a common message size for video streaming applications over MQTT, because that is around the maximum payload size of an MQTT message. At 10,000 bytes which is around 10 maximum payload MQTT messages, gives a good approximation of the delay when multiple messages are bundled for the same destination. 2. One publisher and ten subscribers on one broker and ten other subscribers on another broker. In this scenario, the message size is fixed at 100 bytes and the goal is to understand the effect of adding more subscribers globally in terms of overhead and delay. Similar to the previous scenario, we compute our metrics and the same descriptive statistics for the local subscribers and the global ones and compare them. The last scenario was performed on EC2 virtual machines on Amazon Web Services cloud. Five standard EC2 instances running Ubuntu 22.04 with 1 GB of RAM are located in Tokyo and are used to host two broker services, discovery service, authentication service and an instance for client simulation. All instances where running in the same city (Tokyo). The scenario emulates a simple IoT application for collecting temperature data from two sensors running within the same MQTT broker. The simulated sensors publish their data to their MQTT broker on topic \"temp\". Then, two subscribers are setup where one is connected to the same broker and another one connected to a different MQTT broker. The publishers and subscribers are simulated using javascript code running from the fifth EC2 instance. Each publication is time stamped at the publisher, so that the total delay can be calculated which is used to compute descriptive statistics and the ratios of global client to local client. The number of messages sent are 10 per publisher and they are sent without any delay. The messages sent by each of the publishers is a JSON object structured as follows:

{ sensor: ''sensor 1'' temp: 24.8, timestamp: 1669816556136 } The timestamp is used to compute delay which is the difference between the sent and arrival times. We compute the average delay for each publisher using 10 messages. ## 5 Results and Discussion

The results of the first scenario, illustrate the capability of the system to dynamically register brokers based on the interest of their clients. Thus, when a client publishes the first message within a broker, then the broker is automatically registered with the tracking service as a publisher of that topic, which is subsequently propagated to all registered subscribers. Furthermore, the results of the experiment shows that increasing the size of the payload up to 10,000 bytes does not affect the overhead significantly. The average ratio \(GD/LD\) is between 1.5 and 1.6, which translates roughly to around 2.5 ms difference between GD and LD on average, as shown in Figures 7 and 8, respectively. The same Figure shows maximum and minimum values which gives an idea about the best and worst possible delays for local and global clients. The results from running the second scenario illustrate that a given broker does not issue multiple subscription requests to the same broker when multiple clients subscribe to the same topic. Only the first subscription to a topic acts as a trigger for global subscriptions to other brokers managing publishers of that topic. Furthermore, the migration of the 100 bytes message adds around 2.5 ms of delay to the global clients, in the best, worst and average cases, as shown in Figures 9 and 10, respectively. Figure 8: Difference in milliseconds between arrival time for global client and a local client as publication size increases (10 trials each). Figure 7: Ratio of delay for global client to local client as publication size increases (10 trials each).