DOCSLIB.ORG

Evaluating DDS, MQTT, and Zeromq Under Different Iot Traffic Conditions

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Evaluating DDS, MQTT, and Zeromq Under Different Iot Traffic Conditions Evaluating DDS, MQTT, and ZeroMQ Under Different IoT Traffic Conditions Zhuangwei Kang Robert Canady Abhishek Dubey Vanderbilt University Vanderbilt University Vanderbilt University Nashville, Tennessee Nashville, Tennessee Nashville, Tennessee [email protected] [email protected] [email protected] Aniruddha Gokhale Shashank Shekhar Matous Sedlacek Vanderbilt University Siemens Technology Siemens Technology Nashville, Tennessee Princeton, New Jersey Munich, Germany [email protected] [email protected] [email protected] Abstract Keywords: Publish/Subscribe Middleware, Benchmark- ing, MQTT, DDS, ZeroMQ, Performance Evaluation Publish/Subscribe (pub/sub) semantics are critical for IoT applications due to their loosely coupled nature. Although OMG DDS, MQTT, and ZeroMQ are mature pub/sub solutions used for IoT, prior studies show that their performance varies significantly under different 1 Introduction load conditions and QoS configurations, which makes Distributed deployment of real-time applications and middleware selection and configuration decisions hard. high-speed dissemination of massive data have been hall- Moreover, the load conditions and role of QoS settings in marks of the Internet of Things (IoT) platforms. IoT prior comparison studies are not comprehensive and well- applications typically adopt publish/subscribe (pub/- documented. To address these limitations, we (1) propose sub) middleware for asynchronous and cross-platform a set of performance-related properties for pub/sub mid- communication. OMG Data Distribution Service (DDS), dleware and investigate their support in DDS, MQTT, ZeroMQ, and MQTT are three representative pub/sub and ZeroMQ; (2) perform systematic experiments under technologies that have entirely different architectures (de- three representative, lab-based real-world IoT use cases; centralized data-centric, decentralized message-centric, and (3) improve DDS performance by applying three and centralized message-centric, respectively). All of of our proposed QoS properties. Empirical results show them implement the pub/sub messaging pattern and that DDS has the most thorough QoS support, and more provide a set of configurable parameters for customizing reliable performance in most scenarios. In addition, its middleware behaviors and resource allocation. Accord- Multicast, TurboMode, and AutoThrottle QoS policies ingly, an essential question that needs to be answered can effectively improve DDS performance in terms of is how to choose an appropriate middleware given a throughput and latency. workload condition, and which parameters should be CCS Concepts: • Software and its engineering → Mes- regarded for making the optimal configuration decisions. sage oriented middleware; Publish-subscribe / event- To that end, we propose a set of QoS properties that based architectures; • General and reference → Evalu- are tied to the performance of IoT pub/sub applications ation. and investigate which of those properties are supported by DDS, MQTT, and ZeroMQ. We then conduct a sys- tematic set of experiments to assess their performance Permission to make digital or hard copies of all or part of this in three pub/sub use cases (high-frequency, periodic, work for personal or classroom use is granted without fee provided and sporadic), which provides us with baselines for do- that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation ing further performance optimization. Empirical results on the first page. Copyrights for components of this work owned show that DDS has the most stable performance in the by others than ACM must be honored. Abstracting with credit is above scenarios and provides the most in-line support permitted. To copy otherwise, or republish, to post on servers or to the QoS proprieties we propose. To understand the to redistribute to lists, requires prior specific permission and/or a performance under high frequency data flows, we further fee. Request permissions from [email protected]. M4IoT ’20, Dec 7-11, 2020, Delft, The Netherlands experimentally explore the impact of three competitive © 2020 Association for Computing Machinery. QoS policies (Multicast, TurboMode, and AutoThrottle) ACM ISBN 9781450370288. $15.00 on improving DDS application performance under such conditions. M4IoT ’20, Dec 7-11, 2020, Delft, The Netherlands Kang, et al. 2 QoS Properties Essentials for IoT Systems lack of strict reliability guarantee in ZeroMQ’s pub/sub The primary purpose of this section is to introduce sev- pattern, messages sent in a large batch risk being lost eral performance-related QoS policies available in DDS, when the network is crowded. At the subscriber side, if MQTT, and ZeroMQ that are necessary for performance- subscriber can keep up with publisher and there is no sensitive IoT applications. As a branch of networking application-level queue backlog, ZeroMQ would turn off applications, the performance (throughput and latency) its batching function for the sake of lower end-to-end of pub/sub middleware mainly depends on the network delay. Otherwise, the batching would be enabled to help congestion status and internal resource configuration. the worker thread promote the speed of flushing back- In this paper, we look at the network aspect, and the logged messages. MQTT does not support intelligent principle we followed to choose these features is whether batching. it can effectively change the amount of data entering 2.4 Rate Limit and leaving the network pipeline per unit time or the processing logic of messages in the network. Rate Limit is a flow control mechanism that protects network resources from being encroached by malicious ac- 2.1 Reliability tors in an IoT cluster by specifying the maximum rate at Reliability policy determines whether messages can be re- which a publisher may send samples to the network. DDS liably transmitted, which fatally affect the data-processing allows users to define the Custom Flow Controller that and decision-making processes of IoT applications. DDS maintains a separate FIFO queue for each connection provides two types of transmission guarantees: Best Ef- in which data instances generated by asynchronous pub- fort (i.e., no guarantees) and Reliable (i.e., retry until lishers can be placed. ZeroMQ supports rate limit only success). MQTT provides three service levels: QoS 0, when the multicast protocol (PGM/EPGM) is enabled, QoS 1, QoS 2, representing "at-most-once", "at-least- and is implemented by setting the multicast window size. once", and "exactly-once", respectively. MQTT’s QoS 0 MQTT server shapes the egress traffic of each TCP/SSL is equivalent to DDS’ BestEffort and QoS 2 to DDS’ Re- connection based on the Leaky Bucket (LB) algorithm. liable delivery. ZMQ pub/sub pattern may lose messages when the network is congested. 2.5 Message LifeSpan 2.2 Multicast Message expiration mechanism restrains the longest time that a message is regarded as a legal one in the sys- Multicast allows IoT applications to scale better when tem, which improves overall memory utilization rate multiple subscribers exist. Both DDS and ZeroMQ allow and avoids delivering stale data. In the reliable trans- users to set the number of hops that multicasting mes- port mode of DDS, if the LifeSpan QoS policy is not sages can traverse, which intends to avoid flooding large configured, unconfirmed data instances will reside in networks with multicast traffic. Although MQTT runs the publisher’s writing buffer for a long time and be over unicast protocol, it emulates the application-layer re-transmitted endlessly, which not only wastes mem- "multicast" by wrapping up point-to-point TCP connec- ory and bandwidth, but also destroys the timeliness tions, which is also known as multicast-over-unicast. The of messages. Adhering to similar intent, MQTT imple- protocol utilized in ZeroMQ for multicast include Prag- mentations(etc. EMQ X, HiveMQ, and VerneMQ) that matic General Multicast (PGM) [5] and Encapsulated adopt the latest MQTT specification (MQTT 5.0) al- Pragmatic General Multicast (EPGM). lows publishers to specify a property for each sample 2.3 Intelligent Batching called message-expiry-interval that defines the actual Message batching intends to improve the throughput of lifespan of messages in seconds. There is no analogies IoT applications. It avoids frequent system calls through with LifeSpan QoS in current ZeroMQ implementations. the network stack due to message by message process- 2.6 Topic Priority ing and can be performed at a fixed interval or over number of messages. The TurboMode QoS in DDS au- Topic priority aims to distinguish the importance of tomatically decides the optimal number of bytes in a different messages, which ensures that the overall utility batch on publisher side based on the data sample size, of a multi-topic IoT system is maximized under given writing speed and the real-time system state. Message resource limitation. DDS enables this property via the batching in ZeroMQ is can be enabled at either pub- Tansport_Priority policy that is signified by a 32-bit lisher or subscriber side.Rather than deciding timeout or signed integer. An analogous parameter in ZeroMQ is batch size for a single chunk, ZeroMQ always forwards called ZMQ_TOS that is implemented in the same logic all messages queued in memory at the moment to the as DDS. Unlike the above system-level implementations, network interface card in one go. However,
Load more

Recommended publications
  • This Paper Must Be Cited As
    Document downloaded from: http://hdl.handle.net/10251/64607 This paper must be cited as: Luzuriaga Quichimbo, JE.; Pérez, M.; Boronat, P.; Cano Escribá, JC.; Tavares De Araujo Cesariny Calafate, CM.; Manzoni, P. (2015). A comparative evaluation of AMQP and MQTT protocols over unstable and mobile networks. 12th IEEE Consumer Communications and Networking Conference (CCNC 2015). IEEE. doi:10.1109/CCNC.2015.7158101. The final publication is available at http://dx.doi.org/10.1109/CCNC.2015.7158101 Copyright IEEE Additional Information © 2015 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. A comparative evaluation of AMQP and MQTT protocols over unstable and mobile networks Jorge E. Luzuriaga∗, Miguel Perezy, Pablo Boronaty, Juan Carlos Cano∗, Carlos Calafate∗, Pietro Manzoni∗ ∗Department of Computer Engineering Universitat Politecnica` de Valencia,` Valencia, SPAIN [email protected], jucano,calafate,[email protected] yUniversitat Jaume I, Castello´ de la Plana, SPAIN [email protected], [email protected] Abstract—Message oriented middleware (MOM) refers to business application [6]. It works like instant messaging or the software infrastructure supporting sending and receiving email, and the difference towards these available
    [Show full text]
  • Advanced Architecture for Java Universal Message Passing (AA-JUMP)
    The International Arab Journal of Information Technology, Vol. 15, No. 3, May 2018 429 Advanced Architecture for Java Universal Message Passing (AA-JUMP) Adeel-ur-Rehman1 and Naveed Riaz2 1National Centre for Physics, Pakistan 2School of Electrical Engineering and Computer Science, National University of Science and Technology, Pakistan Abstract: The Architecture for Java Universal Message Passing (A-JUMP) is a Java based message passing framework. A- JUMP offers flexibility for programmers in order to write parallel applications making use of multiple programming languages. There is also a provision to use various network protocols for message communication. The results for standard benchmarks like ping-pong latency, Embarrassingly Parallel (EP) code execution, Java Grande Forum (JGF) Crypt etc. gave us the conclusion that for the cases where the data size is smaller than 256K bytes, the numbers are comparative with some of its predecessor models like Message Passing Interface CHameleon version 2 (MPICH2), Message Passing interface for Java (MPJ) Express etc. But, in case, the packet size exceeds 256K bytes, the performance of the A-JUMP model seems to be severely hampered. Hence, taking that peculiar behaviour into account, this paper talks about a strategy devised to cope up with the performance limitation observed under the base A-JUMP implementation, giving birth to an Advanced A-JUMP (AA- JUMP) methodology while keeping the basic workflow of the original model intact. AA-JUMP addresses to improve performance of A-JUMP by preserving its various traits like portability, simplicity, scalability etc. which are the key features offered by flourishing High Performance Computing (HPC) oriented frameworks of now-a-days.
    [Show full text]
  • Dcamp: Distributed Common Api for Measuring
    DCAMP: DISTRIBUTED COMMON API FOR MEASURING PERFORMANCE A Thesis presented to the Faculty of California Polytechnic State University San Luis Obispo In Partial Fulfillment of the Requirements for the Degree Master of Science in Computer Science by Alexander Paul Sideropoulos December 2014 c 2014 Alexander Paul Sideropoulos ALL RIGHTS RESERVED ii COMMITTEE MEMBERSHIP TITLE: dCAMP: Distributed Common API for Measuring Performance AUTHOR: Alexander Paul Sideropoulos DATE SUBMITTED: December 2014 COMMITTEE CHAIR: Michael Haungs, Ph.D. Associate Professor of Computer Science COMMITTEE MEMBER: Aaron Keen, Ph.D. Assistant Professor of Computer Science COMMITTEE MEMBER: John Bellardo, Ph.D. Associate Professor of Computer Science iii ABSTRACT dCAMP: Distributed Common API for Measuring Performance Alexander Paul Sideropoulos Although the nearing end of Moore's Law has been predicted numerous times in the past [22], it will eventually come to pass. In forethought of this, many modern computing systems have become increasingly complex, distributed, and parallel. As software is developed on and for these complex systems, a common API is necessary for gathering vital performance related metrics while remaining transparent to the user, both in terms of system impact and ease of use. Several distributed performance monitoring and testing systems have been proposed and implemented by both research and commercial institutions. How- ever, most of these systems do not meet several fundamental criterion for a truly useful distributed performance monitoring system: 1) variable data delivery mod- els, 2) security, 3) scalability, 4) transparency, 5) completeness, 6) validity, and 7) portability [30]. This work presents dCAMP: Distributed Common API for Measuring Per- formance, a distributed performance framework built on top of Mark Gabel and Michael Haungs' work with CAMP.
    [Show full text]
  • VSI's Open Source Strategy
    VSI's Open Source Strategy Plans and schemes for Open Source so9ware on OpenVMS Bre% Cameron / Camiel Vanderhoeven April 2016 AGENDA • Programming languages • Cloud • Integraon technologies • UNIX compability • Databases • Analy;cs • Web • Add-ons • Libraries/u;li;es • Other consideraons • SoDware development • Summary/conclusions tools • Quesons Programming languages • Scrip;ng languages – Lua – Perl (probably in reasonable shape) – Tcl – Python – Ruby – PHP – JavaScript (Node.js and friends) – Also need to consider tools and packages commonly used with these languages • Interpreted languages – Scala (JVM) – Clojure (JVM) – Erlang (poten;ally a good fit with OpenVMS; can get good support from ESL) – All the above are seeing increased adop;on 3 Programming languages • Compiled languages – Go (seeing rapid adop;on) – Rust (relavely new) – Apple Swi • Prerequisites (not all are required in all cases) – LLVM backend – Tweaks to OpenVMS C and C++ compilers – Support for latest language standards (C++) – Support for some GNU C/C++ extensions – Updates to OpenVMS C RTL and threads library 4 Programming languages 1. JavaScript 2. Java 3. PHP 4. Python 5. C# 6. C++ 7. Ruby 8. CSS 9. C 10. Objective-C 11. Perl 12. Shell 13. R 14. Scala 15. Go 16. Haskell 17. Matlab 18. Swift 19. Clojure 20. Groovy 21. Visual Basic 5 See h%p://redmonk.com/sogrady/2015/07/01/language-rankings-6-15/ Programming languages Growing programming languages, June 2015 Steve O’Grady published another edi;on of his great popularity study on programming languages: RedMonk Programming Language Rankings: June 2015. As usual, it is a very valuable piece. There are many take-away from this research.
    [Show full text]
  • Zeromq
    ZeroMQ Martin Sústrik <> ØMQ is a messaging system, or "message-oriented middleware", if you will. It's used in environments as diverse as financial services, game development, embedded systems, academic research and aerospace. Messaging systems work basically as instant messaging for applications. An application decides to communicate an event to another application (or multiple applications), it assembles the data to be sent, hits the "send" button and there we go—the messaging system takes care of the rest. Unlike instant messaging, though, messaging systems have no GUI and assume no human beings at the endpoints capable of intelligent intervention when something goes wrong. Messaging systems thus have to be both fault-tolerant and much faster than common instant messaging. ØMQ was originally conceived as an ultra-fast messaging system for stock trading and so the focus was on extreme optimization. The first year of the project was spent devising benchmarking methodology and trying to define an architecture that was as efficient as possible. Later on, approximately in the second year of development, the focus shifted to providing a generic system for building distributed applications and supporting arbitrary messaging patterns, various transport mechanisms, arbitrary language bindings, etc. During the third year the focus was mainly on improving usability and flattening the learning curve. We've adopted the BSD Sockets API, tried to clean up the semantics of individual messaging patterns, and so on. Hopefully, this chapter will give an insight into how the three goals above translated into the internal architecture of ØMQ, and provide some tips for those who are struggling with the same problems.
    [Show full text]
  • Programming Models to Support Data Science Workflows
    UNIVERSITAT POLITÈCNICA DE CATALUNYA (UPC) BARCELONATECH COMPUTER ARCHITECTURE DEPARTMENT (DAC) Programming models to support Data Science workflows PH.D. THESIS 2020 | SPRING SEMESTER Author: Advisors: Cristián RAMÓN-CORTÉS Dra. Rosa M. BADIA SALA VILARRODONA [email protected] [email protected] Dr. Jorge EJARQUE ARTIGAS [email protected] iii ”Apenas él le amalaba el noema, a ella se le agolpaba el clémiso y caían en hidromurias, en salvajes ambonios, en sustalos exas- perantes. Cada vez que él procuraba relamar las incopelusas, se enredaba en un grimado quejumbroso y tenía que envul- sionarse de cara al nóvalo, sintiendo cómo poco a poco las arnillas se espejunaban, se iban apeltronando, reduplimiendo, hasta quedar tendido como el trimalciato de ergomanina al que se le han dejado caer unas fílulas de cariaconcia. Y sin em- bargo era apenas el principio, porque en un momento dado ella se tordulaba los hurgalios, consintiendo en que él aprox- imara suavemente sus orfelunios. Apenas se entreplumaban, algo como un ulucordio los encrestoriaba, los extrayuxtaba y paramovía, de pronto era el clinón, la esterfurosa convulcante de las mátricas, la jadehollante embocapluvia del orgumio, los esproemios del merpasmo en una sobrehumítica agopausa. ¡Evohé! ¡Evohé! Volposados en la cresta del murelio, se sen- tían balpamar, perlinos y márulos. Temblaba el troc, se vencían las marioplumas, y todo se resolviraba en un profundo pínice, en niolamas de argutendidas gasas, en carinias casi crueles que los ordopenaban hasta el límite de las gunfias.” Julio Cortázar, Rayuela v Dedication This work would not have been possible without the effort and patience of the people around me.
    [Show full text]
  • Studying Systems of Open Source Messaging
    Journal of Theoretical and Applied Information Technology 15th October 2019. Vol.97. No 19 © 2005 – ongoing JATIT & LLS ISSN: 1992-8645 www.jatit.org E-ISSN: 1817-3195 STUDYING SYSTEMS OF OPEN SOURCE MESSAGING ALEKSANDER BONDARENKO, KONSTANTIN ZAYTSEV National Research Nuclear University MEPhI (Moscow Engineering Physics Institute), Kashirskoe Avenue 31, Moscow, 115409, Russia ABSTRACT Modern large industrial and financial structures apply numerous various information systems (IS) which exchange data while communicating with each other. In order to implement such communication nowadays, specialized messaging systems are used or transport components comprised of one or several software products. This article compares four open source software products used in messaging systems: Apache Kafka, gRPC, ZeroMQ, and RabbitMQ, which satisfy criteria of Secure Sockets Layer/Transport Layer Security (SSL/TLS) encryption and possibility to operate directly with Java platform applications, that is, to provide Java API. In order to perform these studies, comparison environment was generated with four coordinates: supported communication type, productivity, reliability, and community support. Keywords: Open Source Systems, Apache Kafka, Grpc, Zeromq, Rabbitmq, Messaging, Publish&Subscribe, RPC, Streaming. INTRODUCTION Some crediting and financial institutions start development of intermodular communication With the increase in applied IS, the scope of for platform architecture. Intermodular message exchange also increases, hence, aiming at communication is based on any messaging system, unification and standardization of exchange, it is whether it is message broker or transport library. In required to develop specialized interconnecting large software products, it is also required to systems. In modern world, where Internet of Things implement several communication types focusing (IoT) exerts significant influence on global on messaging rate or high reliability of delivery.
    [Show full text]
  • Distributed Systems – Lectures
    University of Tartu, Institute of Computer Science Distributed Systems MTAT.08.009 ***** [email protected] Course homepage( http://courses.cs.ut.ee/2017/ds/fall) Fall 2017 2 Practical information Teachers: Tutors: Annika Laumets <[email protected]> Eero Vainikko Andre Tättar <[email protected]> Amnir Hadachi Andres Namm <[email protected]> Artjom Lind 3 Practical information Lectures: WED 14:15, Liivi 2 - 405 Practical sessions: 1. group FRI 10:15 Paabel (Ülikooli 17) room 218 (Amnir Hadachi, tutor: Annika Laumets) 2. group WED 8:15 J.Liivi 2 - 403 (Artjom Lind, tutor: Andre Tättar) 3. group FRI 10:15 J.Liivi 2 - 205 (Eero Vainikko, tutor: Andres Namm) Lectures: 32h; Practical sessions: 32h; Independent work: 92h Final grade: 1. Seminar tasks (20%) 3. Active participation at lectures (10%) 2. Homework (40%=20+20) 4. Final exam (30%) 4 Practical information Active participation Active participation at lectures – • Create your own theme sheet portfolio for each lecture theme – DEADLINE: 1 week after each lecture (or 1/2 points later!) • Can use whatever way to privately share the link to the portfolio • Submission of the link through the course page – Be inventive! For example – use ∗ Google Sites (incl. Google Docs, Slides, videos, quizes with the help of Google Forms etc...) ∗ University of Tartu ownCloud http://owncloud.ut.ee – uploading word/text-file, pictures or scans of your notes taken at the lecture 5 Practical information Portfolio consist of theme sheets Each theme sheet is a collection of: • Your coarse notes • definitions • schemes / drawings • your thoughts / ideas / questions • external material – videos – articles – web-sites 6 Practical information – best portfolios awarded with BONUS points! BONUS points: Devize and insert questions into the online course study-questionary! 7 Practical information What we expect from you? 1.
    [Show full text]
  • The Light Node Communication Framework: a New Way to Communicate Inside Smart Homes
    sensors Article The Light Node Communication Framework: A New Way to Communicate Inside Smart Homes Valère Plantevin *, Abdenour Bouzouane and Sebastien Gaboury Département d’Informatique et de Mathématiques, Université du Québec à Chicoutimi, Saguenay, QC G7H 2B1, Canada; [email protected] (A.B.); [email protected] (S.G.) * Correspondence: [email protected] Received: 5 September 2017; Accepted: 17 October 2017; Published: 20 October 2017 Abstract: The Internet of things has profoundly changed the way we imagine information science and architecture, and smart homes are an important part of this domain. Created a decade ago, the few existing prototypes use technologies of the day, forcing designers to create centralized and costly architectures that raise some issues concerning reliability, scalability, and ease of access which cannot be tolerated in the context of assistance. In this paper, we briefly introduce a new kind of architecture where the focus is placed on distribution. More specifically, we respond to the first issue we encountered by proposing a lightweight and portable messaging protocol. After running several tests, we observed a maximized bandwidth, whereby no packets were lost and good encryption was obtained. These results tend to prove that our innovation may be employed in a real context of distribution with small entities. Keywords: messaging protocol; IoT; smarthome; distributed computing 1. Introduction The evolution of our society towards the all-digital Internet of things (IoT) has profoundly remodeled our relationship with the science of information. In accordance, the smart home has become the subject of numerous studies [1–3] and joins a recent current of thought stemming from ambient intelligence (Amb.
    [Show full text]
  • A Survey of Distributed Message Broker Queues
    A Survey of Distributed Message Broker Queues Vineet John Xia Liu University of Waterloo University of Waterloo [email protected] [email protected] ABSTRACT This paper surveys the message brokers that are in vogue today for distributed communication. Their primary goal is to facilitate the construction of decentralized topolo- gies without single points of failure, enabling fault tol- erance and high availability. These characteristics make them optimal for usage within distributed architectures. However, there are multiple protocols built to achieve this, and it would be beneficial to have a empirical comparison between their features and performance to determine their real-world applicability. Figure 1: Kafka Architecture This paper focuses on two popular protocols (Kafka and AMQP) and explores the divergence in their fea- RQ0 What are the message broker implementations tures as well as their performance under varied testing commonly in use today? workloads. RQ1 What are the common requirements for the im- plementation of message queues? KEYWORDS RQ2 What are the divergent functionalities in the distributed message broker, message queue, kafka, amqp, current message queue offerings? rabbitmq RQ3 How do each of the implementations offer relia- bility, partitioning and fault tolerance? 1 INTRODUCTION 3 KAFKA Kafka was developed at LinkedIn and primarily used Distributed Message Brokers are typically used to decou- for log processing. This worked well for Kafka’s user en- ple separate stages of a software architecture. They per- gagement metrics collection use-case. The fundamental mit communication between these stages asynchronously, features behind Kafka are performance over reliability by using the publish-subscribe paradigm.[1]. These mes- and it offers high throughput, low latency message queu- sage brokers are also finding new applications in the ing.
    [Show full text]
  • Message-Oriented Middleware As a Queue Management Solution to Improve Job Handling Within an E- Commerce System
    DEGREE PROJECT IN INFORMATION AND COMMUNICATION TECHNOLOGY, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2018 Message-Oriented Middleware as a Queue Management Solution to Improve Job Handling within an E- Commerce System TOBIAS JOHANSSON KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE CONTENTS 1 Abstract Today’s applications are required to continuously adapt and adjust, to be able to meet a constant change in demand. As result of an in- creasing amount of data, choosing the right communication method becomes a vital step. A solution that have been functional for a long time, may at any point in time be unable to reach the level it requires and instead turns into bottlenecks and inefficient solutions. Using a database as a communication method between system enti- ties, does not have to be a bad solution. A database has it perks with being a simple solution and efficient query operations. However, us- ing it as a queue management system, requires entities to continuously poll new table entries. This solution may not be the most suitable nor best available option. There exists communication system developed for the specific purpose of efficiently distributing messages to avail- able parties. Implementing a message-oriented middleware enables for asynchronous communication which promotes applications to be more loosely cou- pled. As a result, available resources could be better utilised and im- prove the system performance. This degree project investigates the development and integration of two message-oriented middlewares, RabbitMQ and AcviteMQ, within an e-commerce system. The pur- pose is to explore the potentials of changing queue management sys- tem from a database to a message broker.
    [Show full text]
  • A Data-Oriented M2M Messaging Mechanism for Industrial Iot Applications
    The University of Manchester Research A Data-Oriented M2M Messaging Mechanism for Industrial IoT Applications DOI: 10.1109/JIOT.2016.2646375 Document Version Accepted author manuscript Link to publication record in Manchester Research Explorer Citation for published version (APA): Meng, Z., Wu, Z., Muvianto, C., & Gray, J. (2017). A Data-Oriented M2M Messaging Mechanism for Industrial IoT Applications. IEEE Internet of Things Journal , 4(1), 236 - 246. https://doi.org/10.1109/JIOT.2016.2646375 Published in: IEEE Internet of Things Journal Citing this paper Please note that where the full-text provided on Manchester Research Explorer is the Author Accepted Manuscript or Proof version this may differ from the final Published version. If citing, it is advised that you check and use the publisher's definitive version. General rights Copyright and moral rights for the publications made accessible in the Research Explorer are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. Takedown policy If you believe that this document breaches copyright please refer to the University of Manchester’s Takedown Procedures [http://man.ac.uk/04Y6Bo] or contact [email protected] providing relevant details, so we can investigate your claim. Download date:07. Oct. 2021 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2016.2646375, IEEE Internet of Things Journal A Data-Oriented M2M Messaging Mechanism for Industrial IoT Applications Zhaozong Meng, Member, IEEE, Zhipeng Wu, Senior Member, IEEE, Cahyo Muvianto, and John Gray Abstract—Machine-to-Machine (M2M) communication is a key exchange information with each other in an autonomous way enabling technology for the future Industrial Internet of Things [4].
    [Show full text]