# Real-Time UAV Trash Monitoring System
## 3 Message Queuing System  
The streaming data are produced by the data sources such as the sensors in the factory, personal e-commerce purchases, social website activities, or other log files. For the monitoring system, it is important to build a suitable application integration for streaming data processing, storing, and analyzing. The integration of one or more data sources to construct a large application is proposed. According to [23], the four main application integration styles are file transfer, shared database, remote procedure invocation, and messaging. The file transfer integration style means that the processor listens to the file in the folder. If the source creates the file, then the processor catches the file from the folder, as shown in Figure 8. Although the idea of file transfer integration is intuitive, it is not suitable for the data streaming system due to the high latency. The shared database integration style facilitates the storage of data by multiple applications with a shared database, as shown in Figure 9. Frequent reading and modification of the same data in the database causes a bottleneck to the performance and is not suitable for streaming data processing. Figure 8: The file transfer integration style. Figure 6: The calculation of the area of the detected trash. Figure 7: The performance of our proposed quadrotor. In remote procedure invocation, the client sends a request and the server replies, as shown in Figure 10. The drawback of remote procedure invocation is that all the applications are tightly coupled, and it is hard to maintain integration. The messaging integration style is asynchronous messaging and can decouple all the applications so the sender does not need to wait for the receiver, and we can develop the application efficiently in the real-time monitoring system, as shown in Figure 11.  
In an earlier study [24], the authors compared five typical message queuing systems, including Kafka [25], RabbitMQ [26], RocketMQ [27], ActiveMQ [28], and Pulsar [29]. They also tested the latency and the throughput in the three scenarios, including the message size, number of producers/consumers, and number of partitions. The latency means how long the message transmitted between the applications is affected by packet metadata processing, packet replication, memory access latency, the message guarantee mechanism, and dequeuing latency. Here, RocketMQ showed the lowest latency across the three scenarios. The throughput measures the message bytes transmitted through the message queuing system per time unit. In the throughput test of five message queuing systems, Kafka received the highest throughput in message sizes of 4K bytes, one producer and one consumer, and 16 partitions. Considering the scalability of our real-time UAV trash monitoring system in the future, the high throughput of Kafka is needed. Although the latency of Kafka is about 70 ms and is higher than RocketMQ, Kafka is still acceptable in our system. Kafka, a publish/subscribe messaging system designed by LinkedIn, is used as a distributed event streaming platform in most scenarios such as financial transactions, automotive industry tracking, and customer interactions in business. Kafka is good at handling multiple producers and multiple consumers and can scale up the brokers to handle any amount of data. Because of the disk-based retention of Kafka, if the data processing is in traffic, there is no danger of losing data. The data are retained in Kafka with custom retention rules. To validate the high performance of Kafka, we compared the throughput with one producer and one consumer in the topic (one partition) via three Python APIs. We sent 1M messages at 100 (bytes) per message. Tables 1 and 2 show the high-performance test of the Kafka producer and consumer in our experiment with  
Figure 11: Messaging integration style. Figure 9: Shared database integration style. WD10 EZEX-22 MFCA0 hard disk drive and Intel i7-6700 CPU.