文摘
在物联网,许多数据传输协议用于各种任务。在本文中,我们考虑的应用层协议的主要信息传递的物联网。主要问题有不可预见性,缺乏稳定的数据传输延迟,和非确定性,这对于实时系统也很重要。本研究的目的是确定最合适的中间件系统高数据传输和数据传输协议的要求,包括实时系统。因此,MQTT rtp、JMS和AMQP协议进行分析,以找出任务应该使用这些协议,他们是否可以用于机器人和自治系统数据传输要求高在哪里。评估协议,分析了标准确定的利弊,以及软件实现的每一个选择。评估数据传输的特点,我们已经开发出自己的测试场景,模拟复杂的情况。软件解决方案的行为分析和比较分析是基于获得的数据。在一起,理论分析的协议和软件解决方案的研究使我们能够得出结论的适用性在实时系统中一个特定的协议。作为这项研究的结果,我们可以得出结论,rtp实时系统的最佳解决方案是不同的流量和MQTT发送短消息时表现良好。 But none of the protocols under consideration guarantees the determinism of data transmission, so it is better to use specialized link-layer protocols to obtain guarantees.
1。介绍
在现代系统中,处理的数据量,生成和传播正在增加。许多复杂的系统包含多个模块或节点,不断地相互通信。这些模块可以位于一个电脑或网络中分布式。越大越自动化系统,数据传输和实时通信的要求。在分布式计算系统中,传输影响系统的性能,在各种机械系统,常数可能需要同步和数据交换率低可能导致错误的操作或破坏机制。在自治系统,如自动驾驶车辆,不可预知的和长时间的延误可能成为威胁人们的生活。在这方面,问题出现关于数据传输协议的选择可靠和快速的数据传输。
1.1。动机
各种网络技术应用在日常生活中无处不在。系统变得越来越聪明,总有一个资源有限的问题。数以百万计的传感器不断创建和传输数据管理现实世界的基础设施,使用复杂的物联网网络(物联网)。人类活动的各个领域,各种技术和协议正在开发的组织网络和基础设施的有效操作。等主要领域的发展网络技术是智能环境,自动运输,和药品。
1.1.1。智能环境
一个聪明的环境包括我们日常生活的各种流程的自动化。它包括智能家居等技术、智能城市、智能制造、等在智能环境中,有限的资源的问题也出现了,因为智能设备和各种传感器也被用来创建这个环境。物联网设备的资源是非常有限的,没有可能在本地执行复杂的计算任务。同时,数据传输通道的带宽也是有限的,不可能使用整个资源的功能系统。要解决这些问题,边缘计算相关的各种基础设施建设方法被创建(1]。同时,基本数据传输技术是物联网协议,他们扮演了一个重要的角色在一个特定环境智能监控系统的操作。
1.1.2。自动传输
自治运输包括一组单位像传感器,GPU, CPU执行器等。机载控制系统的操作是基于子系统之间的信息传输。因此,它是至关重要的实现一个可靠的数据交换。的主要参数是保证数据传递,数据完整性,最大可能的数据传输的延迟,和计算成本。此外,它是至关重要的平衡要求考虑不同类型的数据:巨大的信息从传感器、简短的命令从cpu,等。因此,数据传输协议提供最好的参数分布和复杂的自动控制系统。
1.1.3。医学
现代医疗涉及许多个人可穿戴传感器不断地监视一个人的状态。有不同意见下一代医疗平台的体系结构。研究人员都同意个人传感器的集成到一个统一的医疗信息系统是不可避免的。这意味着异构环境中沟通的有效方法。本文将讨论的沟通方法是有用的那些设计医疗系统。
2。文学概述
本节将介绍该研究领域的工作,以及一个描述每个协议的考虑。在考虑协议的理论部分,主要问题,本研究试图回答提出。
2.1。相关的工作
大量的研究和作品进行选择协议实时系统的问题。各种物联网协议分析的性能、安全性和可靠性。AMQP以来在物联网和MQTT协议是受欢迎的,重要的是要理解每个协议相关的安全漏洞。在[2- - - - - -5),这些协议的脆弱性和网络威胁分析。此外,在6),AMQP工业物联网协议的分析。MQTT的(7),比较与CoAP桥提供了Eclipse项目实现。同时,分析MQTT性能做了(8]。有一个正式的方法来建模、分析和验证使用MQTT的交流工具在9]。延迟和QoS级别的依赖MQTT分析(10]。AMQP的分析和比较,MQTT CoAP,和HTTP协议没有任何实现了在11]。由于AMQP使用队列、消息队列的详细分析方法和RabbitMQ的比较,ActiveMQ,卡夫卡的实现是在(12]。RabbitMQ, AMQP的实现,分析了面向消息的中间件(MOM)和NATS相比,卡夫卡在[13]。分析OPC UA、DDS、工业和MQTT协议4.0中完成(14]。更多细节DDS和以数据为中心的沟通(15]。实时系统的DDS标准设计至关重要的基础设施。因此,安全是必要的,以避免灾难和生命损失。分析了DDS的安全问题(16,17]。触摸在我们之前的研究,我们分析了物联网中的现有数据传输标准(18)和DDS的性能服务(19]。
2.2。协议概述
在本节中,我们将简要地考虑协议的主要概念和突出规范规定的基本特征。每个协议是解决一定范围的任务,所以它是值得了解他们每个人理解的相关性在现代物联网使用的协议。
在物联网中,最相关的MQTT协议,AMQP, JMS, XMPP, CoAP, rtp (DDSI-RTPS)。XMPP不支持任何交付担保,但只允许从客户端请求信息的交付数据20.),因此该协议是不被认为是在这篇文章中,因为这些交付保证实时系统需要使用最新的数据。此外,CoAP协议不是本文中讨论;尽管这个协议的发布-订阅模型是有趣的实时系统,标准的客户机-服务器模型不适合实时数据transmissionbecause这个模型需要发送请求接收新数据。这些协议解决任何格式的数据交换问题,队列处理和数据分布。认为协议提供了不同的担保,所以有必要了解目标系统的一个特定的协议可能合适或数据。
2.2.1。消息队列遥测传输(MQTT)
MQTT(消息队列遥测传输)是一种轻量级版本发布-订阅模型的传输协议。该协议是一个开放的OASIS标准和ISO推荐。
IBM的MQTT是安迪博士发明的他,和阿伦尼珀Arcom(现在的荷兰),1999年。有一个问题与监控设备和远程服务器之间的通信在石油和天然气工业。在许多情况下,很难或不可能使用固定电话,有线连接,或无线电传输连接。在此期间,卫星通信是唯一解决这个问题的。但这是非常昂贵的,它是必要的支付根据传输的数据量。因此,成千上万的传感器所需的交流方式,能以最小的带宽使用提供可靠的数据传输。
两个开发人员指定工具的功能来解决这个问题:(我)简单的实现(2)轻量级和带宽效率(3)的服务质量(iv)数据不可知(v)连续会话意识
IBM使用协议后创建的用于内部目的大约10年了。然后IBM MQTT发布3.1免费版在2010年。从那时起,所有人都能够使用的协议。2014年,MQTT成为官方认可的OASIS标准。
2019年,绿洲批准新的MQTT 5规范。指定的新版本特性,需要在物联网行业,比如更多的可靠性和错误处理。
它的工作原理上的任何命令,无损,双向网络协议,例如TCP或SSL。在MQTT,有两个实体:服务器(代理)和客户。所有消息从发送者被称为出版商通过代理接收器谁被称为用户。所有数据分为主题标签附加到消息。服务器匹配主题订阅和转发消息是否匹配。这是客户的行为:(我)连接到代理(2)订阅一个主题,等待传入消息或将消息发送到主题(s)(3)关闭连接
MQTT主题提供了通配符,订阅和共享的服务质量。
还有一个变化的protocol-MQTT-SN (MQTT传感器网络)。它是专门为传感器网络。MQTT-SN之上可以non-TCP如UDP / IP网络协议。头大小也在减少,utf - 8主题字符串id已经取代了整数的话题。
质量的服务定义了交货保证。有三个级别:(我)QoS 0:至多一次交付。消息只发送一次。接收者发送响应和发送方执行不重试。(2)QoS 1:至少一次交付。消息发送,直到它到达用户至少一次。订阅者发送一个确认出版商在得到消息。出版商进行重试,直到收到一个确认。用户进程的任何副本消息作为一种新的独特的消息。(3)QoS 2:一个交付。订阅者接收只有一个副本的消息通过一个两步确认过程。像在QoS 1中,订阅者发送确认,但出版商发送第二个应答,在得到它之后,订阅者发送回最终承认完成消息传输。承认交换期间,接收方滴任何消息,相同的数据包标识符作为当前的消息。
如前所述,这个话题是一个标签附加到消息。主题名称可以形成一个层次化的主题树用斜杠隔开每个水平。用户使用一个主题过滤让代理知道他们感兴趣的话题。通配符可以用于过滤的主题。数字符号是一个多级通配符匹配任意数量的主题,包括零的话题。加号是单层通配符匹配的主题只有一个水平,包括零的话题。
MQTT定义了两种类型的订阅:共享和非共享。主要的区别是消息的副本的数量。非共享订阅,订阅的所有接收器同一主题得到自己消息的副本。使用共享订阅,只有一个副本的消息发送到一个共享组。这样,可以创建一个负载均衡网络体系结构。共享出版物的订阅也用于并行处理多个客户。
2.2.2。实时发布-订阅协议(rtp)
rtp数据交换协议,也称为DDSI-RTPS,是由对象管理组织(OMG),作为DDS标准的一部分,负责数据传输,确保不同供应商之间的兼容性,以及确保DDS服务的平台独立性。DDS规范的第一个版本在2004年被释放和rtp协议规范版本在2009年。
DDSI-RTPS协议开发可靠和高速传输通过不可靠的数据传输协议,例如通过UDP。
DDSI-RTPS基于DDS标准中描述的概念。模型描述实体如:(我)域(2)主题(3)出版商通过DataWriter发送数据到主题(iv)用户从DataReader谁数据
发布者和订阅者的结束节点发送和接收数据,分别和主题是一个实体描述的通道发送数据,用户可以跟踪。域是一个实体,将话题,出版商和用户进入不同的名字域。因此,主题、出版商和用户属于一个特定的域和不能与节点从另一个域。同时,用户和出版商不了解彼此,但只有通过连接的主题数据传输。
rtp协议是基于四个主要模块:(我)一个结构模块,描述了结构的实体;(2)一个消息模块描述传播消息的结构;(3)一个行为模块,描述了消息传输的顺序和时间限制在每个消息的传播;(iv)发现模块,描述节点找到彼此交互。
为了保证可靠的数据传递,CacheChanges等协议描述了一个实体。每个节点(DataReader或DataWriter)有这样一个实体。每个节点在发送和接收数据时,注意这个缓存中的变化。
协议有三种消息类型:数据,心跳,ACKNACK。数据与数据信息,心跳消息DataWriter CacheChanges的变化,和ACKNACK与DataReader CacheChanges的变化信息。心跳和ACKNACK的帮助下,可以确定哪些数据被但不提供,这将允许重新发送这些数据。但自从DataWriter只知道数据丢失从DataReader接收变化,进而只接收到消息时,发送数据包损失只会被当DataReader收到下一条消息时,通常违反接收消息的顺序。以确保序列是正确的,该协议使信息不可用,直到收到所有必要的数据。
发现模块包含两个协议实现网络中寻找节点。第一个协议是参与者发现协议(PDP),它描述了算法搜索网络中节点属于一个特定的领域,和第二个协议是端点发现协议(EDP),它描述了搜索特定DataReader和DataWriter域。
因此,我们可以区分以下品质的协议:(我)提供自动搜索的节点;(2)为数据传输提供各种QoS DDS标准描述;(3)高数据传输速率由于UDP协议,而不是TCP。
2.2.3。Java消息服务(JMS)
在1995年引入了一种新的编程语言Java。没有一种机制,提供几个程序之间的通信,JMS (Java消息服务)成立于1998年来解决这个问题。最后一个版本(2.0)的JMS标准于2015年更新。
JMS是类似于其他中间件。它有两种类型的通信:点对点、发布和订阅。在这两种沟通方式,有一个JMS提供程序,用于管理连接,队列,和资源。打开第一个连接创建一个提供者外部Java虚拟机。
点到点消息传递意味着有两个进程相互通信。这种沟通使用消息队列。每个进程都有一个消息队列是“邮箱。“接受所有类型的消息队列,为每个消息发送者不是个人,所以没有必要在多个队列两侧。每个队列可以使用几个客户,但是他们不会接收所有消息以防分娩后每条消息成为消费,不能被任何客户端检索。在JMS队列有两种类型:临时和静态。临时队列可以只在一个连接使用,因为它们只存在在连接的生命周期。静态队列是最常用的。他们也可以用于一些连接和他们可能仍然存在客户端程序结束后,当重新启动,客户端可以从这个队列检索消息。
发布和订阅消息传递是一种常见的发布-订阅模型,在一些过程通过一个主题进行通信。可靠性取决于用户的耐用性和出版持久性。非持续的发布结果至多一次可靠性、持续发布结果在一次且仅一次的可靠性。日用订阅者可以错过消息如果他们不活跃,虽然持久订阅者不能错过的消息。持续发布主要是由静态队列实现。没有描述如何返还必须实现。
作为额外的功能,有一个消息选择器。它允许用户通过处理过滤消息头字段。它使用SQL语法。同时,一些供应商允许使用主题层次结构,这有助于立即发送消息给几个主题。
2.2.4。高级消息队列协议(AMQP)
AMQP是2003年由约翰·奥哈拉。的第一个实现这个协议是Apache Qpid。红帽在2005年开始发展它。2007年,兔子技术发布实施AMQP称为RabbitMQ。
AMQP定义了三种类型的节点:生产者,消费者,和队列。生产者和消费者的部分应用程序生成和处理消息。每个节点附加到一个容器,可以客户或代理。客户和代理的区别只是在预期的功能。
AMQP开始通信首先需要创建一个容器之间的联系。然后可以开始会话。每个连接可能包含多个会话。之后,可以在两个节点之间建立一个链接。所有单向链接。链接的每一面,都有一个终点控制通过链接消息流。
可以将消息传播只有通过一个链接。与节点,信息可分为几个类型,即源自,终止,或继电器节点。队列用于存储消息并使其可用于一些消费者。经纪人的主要目的是管理队列接收消息的生产者,商店,并传递给消费者。
每一个消息传递都有结算状态,控制如果消息被交付,和交付状态。设置结算,节点发送帧。当接收者发送帧交货达成和解,发件人删除交付从地图的不安。它可以用来实现不同可靠性策略。如果发送方设置的解决交付消息发送后,那么消息将被传递“最多一次。“如果接收者发送一个解决交付和发送方等待解决,然后它实现了“至少一次”的保证。执行”了一次,“交付发送方必须设置结算后才接收方设置终端交付状态,和接收机必须清算后,发送者。但在这种情况下,发送几帧:至少一个终止,另一个用于结算。没有其他方法来实现可靠传输AMQP没有重复。
此外,AMQP提供安全协议的支持,如TLS和SASL。此外,它有一个事务性消息传递模型。事务性工作包括三个操作:发布、获取和退休。目标执行发布的信息不可用,使目的地,直到将完全放电。源执行退休将交付的结果与transactionSource获得事务消息来执行操作。
2.3。结论的概述
做了大量的工作领域的物联网协议的研究。不同的研究调查不同特点的数据传输和使用不同的方法。每个协议都有很多实现,可以相对更好或更糟,和研究还可以使用各种协议实现进行分析。此外,有必要考虑所有协议在相同条件下为了实现客观的比较结果。根据方法,选定的软件实现,考虑协议的范围,研究结果可能会有所不同。
所有这些因素复杂解决方案的选择和协议为一个特定的任务。本文讨论最好的软件实现基于评估的工作和创建相同的条件中间件。
3所示。材料和方法
分析和比较了协议选择的考虑,有必要制定标准将展示他们的特点,选择使用软件实现数据传输的协议,并开发一个测试方法,将允许从不同的角度学习这些技术。
在本节中,我们将考虑我们的工作为研究开发的软件解决方案的方法发出各种条件的数据传输。这种情况可以发生在不同的系统,所以有必要评估不仅这些软件工具的最大能力,而且他们的行为在关键的情况下,可以由开发人员在开发的系统。我们还将选择特定数据传输的标准库定义为每个协议。
3.1。描述的比较方法和测试方法
创建每个协议都有自己的原因,在于其功能。它既有优点和缺点。很难预测协议基于性能的分析。性能也不仅仅取决于协议的实现。此外,机器有不同的能力,这也会影响性能。有必要知道数据传输特点的客观评价和比较。比较不同的协议可能很困难,因为他们的工作不同,为不同的目的而设计的。因此,最好有一个普遍的价值特征显示实际的协议。这使得它可以比较和选择实现不了解其内部结构。
测试场景开发评估不同的实现。这些测试模拟与不同的环境情况:消息间隔,或交换的用户数量对,频率,消息大小。测试的限制可以看作是硬实时的情况。这一切给一个洞察的局限性和问题的协议和/或实现。这有助于决定是否一定的协议是一个很好的解决方案的问题。
对于每个选定的实现,有相同的逻辑编写相应的程序。项目之间的差异只是在发送和接收数据的功能,直接使用API所选的中间件。的一般逻辑测试有以下三种类型的交互:(我)单向数据传输,当程序执行的角色要么只有发送方或接收方指定的频率和指定的负载大小;(2)双向数据传输,只有当它收到一个节点发送消息的响应,因此测量RTT和抖动;(3)双向数据传输,当一个节点不等待响应,但在一定时间间隔发送消息,虽然有可能人为地限制索引队列接收和发送消息。
获得客观结果选定的数据处理技术,项目被分配到一个单独的核心的专用资源,保证项目工作在相同的条件。
系统测试的特点如表所示1。所有测试都是在单一的计算机执行。研究中使用的测试场景将在下面描述。
3.1.1。评估队列处理性能
测试的目的是为了调查消息队列处理。在测试中,第一个节点将消息发送给其他节点没有任何时间间隔。因此,队列积累。
测试执行消息大小50和60000字节。进程的优先级设置为最高的linux - 99。两个节点绑定到CPU核心。所以,每个过程是独立的,没有中断队列处理期间,这样的条件有助于得到最准确的数据的特性进行了研究。
3.1.2。评估节点的数量对性能的影响
测试的目的是为了调查的总延迟依赖用户的数量。在测试中,一个节点发送消息到其他nodes-subscribers(出版商)。发送的消息大小频率占用1.25 MB每秒的带宽。
测试执行与不同的用户数量从1到20。测试1,所有进程在linux中最高优先级- 99。不绑定到CPU核心节点。一个独立的测试运行为每个订户的数量。
3.1.3。评估对延迟的消息大小的影响
测试的目的是为了调查的总延迟消息大小的依赖。在测试中,第一个节点将消息发送给其他节点在给定的时间间隔。测试期间的消息大小增加。
在不同的频率上执行测试,结合消息大小从2.5 kB每秒2 GB的带宽。在之前的测试中,所有流程在linux - 99具有最高的优先级。节点不绑定到CPU核心。
3.1.4。抖动值估计和最小延误
测试的目的是为了调查总延迟,抖动,RTT(往返时间)的每个消息的最小大小。测试还显示数量的用户空间和内核空间之间的副本。在这个场景中,乒乓球模型:一个节点发送一条消息,然后两个交换消息后才从其他节点接收消息。传播消息的测试时停止设置数量。每个消息的大小10个字节。节点不绑定到CPU核和处理优先级没有设置。
3.1.5。评估的影响相互作用过程的数量在不同条件下延迟
测试的目的是为了调查依赖总延迟的消息大小的不同消息发送的频率和数量的过程。在这个场景中,乒乓球模型,但该节点发送第一个消息,也被称为第一个节点,不等待接收一条消息从其他节点,与前面的场景中,并发送新消息在给定频率。其他节点是在前面的测试。传播消息的测试时停止设置数量。
单项成绩的测试包括两种类型:(1)一对交换消息在给定频率;(2)以固定频率,几双交换消息。消息大小增加子在测试期间。在第一个分测验,消息占用带宽范围内的5 kB-4 GB每秒的节点。在第二个分测验,消息占用带宽范围内的100 kb - 1.5 GB每秒每一对。对第二个分测验的数量是1,2,3。节点不绑定到CPU核和处理优先级没有设置。
3.1.6。调查延迟人工修复消息队列
测试的目的是为了调查的总延迟处理有限队列。这个场景使用有限的队列乒乓球模型从测试5。如果第一个节点有不同的数量发送消息最后接收一个大于50的水印值,没有消息将被发送。这意味着消息队列中不超过水印的价值。由于有限的队列,将常数或延迟不超过某个常数的值。每个消息的大小10个字节。节点不绑定到CPU核和处理优先级没有设置。
3.2。描述框架的选择
框架选择的主要标准是开源和C / c++ / Java编程语言的客户。
JMS是非常抽象的,所以本研究可能是任何Java客户端有或没有任何服务器。但在这篇文章中,有一个与Java实现的想法,所以JMQ被选中。服务器被称为GlassFish,它是由Sun Microsystems开发的,后来通过机翼下的Eclipse基金会。消息属性的auto-acknowledge用于测试。非持久的属性也设置。如果持久化属性设置,消息复制到硬件,以避免失去它。
有很多的实现DDS标准:OpenDDS, OpenSplice FastRTPS,气旋DDS。有评估FastRTPS eProsima网站(21]。我们也有另一个研究比较所有这四个DDS框架。,FastRTPS是赢家。例如,在图1,有一个延迟图增加大小的消息(我们使用“延迟消息大小的影响评估”测试场景)。结果OpenSplice(公众版的这个解决方案)没有添加到图像,这个解决方案显示一个可怕的结果与200条消息延迟秒后,大小是512 kB。如,FastRTPS展示了最好的结果。因此,FastRTPS已经选择了这个研究。为保证交货,以下消息属性设置:为了实现交付担保,参数设置为存储的所有消息尚未接收到用户和QoS-reliable政策被选中时,保证数据交付。
现在没有很多AMQP的实现。三个受欢迎的RabbitMQ服务器,ActiveMQ, Apache Qpid。比较前两个是在(22RabbitMQ],显示更好的结果。在[23),进行了比较RabbitMQ和卡夫卡,前者有不错的效果。Apache Qpid一直在测试前三个测试。在图2,有RabbitMQ和Qpid测试”的结果评估延迟消息大小的影响。“如Qpid更糟。在其他的测试中,Qpid结果接近或低于RabbitMQ。因此,RabbitMQ已经选择了这个研究。
有许多MQTT服务器由于物联网越来越我们生活的一部分。评估、分析和比较(MQTT经纪人已经完成的24,25]。在这些研究中,最好的结果是Mosquitto代理所示。因此,该代理用于这项研究。PahoMQTT已被选为客户端。它是由Eclipse基金会。测试的QoS级别被设置为1至少一次交付。
4所示。结果与讨论
协议的分析应分为两个sections-theoretical和性能,因为规范的分析不会给信息数据传输的性能,但只有有助于理解操作的原则和所提供的担保协议。同时,来自不同供应商的协议实现可能显示不同的特点,所以实际评估的一个特解的性能并没有给出一个准确的评估协议。
在本文后面,我们将尝试分析这些协议提供,考虑由于测试获得的特征。
4.1。协议的操作分析(基于规范分析)
我们研究分析的协议,这些协议的规范,是在公共领域。在这部分的研究中,该算法的优点和缺点被确定使用的协议和技术。
以下4.4.1。MQTT
MQTT数据包是轻量级的。每个包分为三个部分:一个固定头、变量头和负载。固定头由包类型,国旗,剩余的长度。总结前两个给1个字节。变量头由一个2字节的数据包标识符和属性变量的长度。一些数据包有特定要求的属性。有效载荷是一个用户发送的消息。包不占用太多的空间。另外,许多属性是用于打开连接的数据包。发布包中只有一个必需的属性会占用很多领域- - - - -主题名称。 The topic is a UTF-8 string. If needed, the topic can be replaced by, for example, the topic ID, like in MQTT-SN. But that would cause problems with wildcards in topics. Therefore, if they are not used, it is possible to reduce packet size by replacing the topic with something else.
MQTT说之前没有队列。所以,它变成了一个问题,应用程序可能无法处理消息。这不是不寻常的在网络上与数千客户和千消息每秒。创建QoS解决这个问题。但它也有其他问题。QoS 1,用户花时间处理每个消息作为一个新的。QoS 2,有三个承认每个大小约为6字节的消息。所以,每一秒,每一千用户发送一千应答。它减少了带宽至少6 MB。MQTT有利于实时需要实际数据,但数据传输交货保证,MQTT可能比其他解决方案基于消息队列。
此外,MQTT是集中的。所以,它有一个代理的单点故障。在某些情况下,这可能是一个问题。
服务定义了保证交付质量在MQTT描述。是一种无损的网络协议TCP需要吗?TCP需要大量的带宽。如果消息是由服务器下降,例如,由于性能的限制,将会再次发送消息,这将占用很多带宽。最好可以使用UDP或其他UDP协议,因为他们不需要太多的带宽。QoS级别1和2保证交付,所以无损的过度要求的网络协议并不是必要的。优点:(我)轻量级的数据包;(2)QoS级别;(3)筛选信息的能力。缺点:(我)MQTT使用TCP / IP;(2)集中式模型;(3)没有队列。
4.1.2。rtp
比其他协议rtp协议有许多优点。如审查所述,协议是定位作为一个可靠的数据传输协议,使用不可靠的传输层protocols-UDP / UDPM。使用这些协议,提供信道吞吐量和数据传输速率最高。
的帮助下简单的参与者发现协议,DDS标准提供了动态连接到网络的能力,而无需知道发送方的地址/收件人。这提供了一个即插即用连接,节点找到彼此。但是该协议并不能保证来自不同供应商的不同实现之间的兼容性。
协议支持QoS级别最好的努力或可靠的连接。可靠的连接是通过重发数据,如果包尚未交付,但传递的信息接收到的数据包将不会使用特殊的消息,如TCP,但只有当数据的接收下一个数据包。这个算法模块收到数据包,直到所有丢失的数据包。在某些情况下,这可以增加延迟交货非常明显。
额外的数据,帮助确保连接的可靠性(保证数据交付)也可以限制数据存储时间的消息,消息传递的时间限制和其他参数,实时数据传输的可能是必要的。
协议意味着一个模块化的系统,保证没有一个单点故障的情况下,允许扩张而失去兼容性,分开,并使用DDS标准。
因此,协议的以下优点可以区分:(我)交货的QoS和灵活的配置和数据存储为每个消息参数;(2)即插即用连接;(3)使用UDP的快速数据传输;(iv)没有单点故障。
缺点如下:(我)包丢失的情况下延迟增加;(2)可能的供应商之间的不兼容性。
4.1.3。JMS
JMS是一个很好的解决方案可以实现系统可靠性作为静态队列。但使用在实时系统中可以使用静态队列失败的持久存储。优点:(我)它很容易使用。它不使用额外的结构,如确认收到的消息。没有特殊的消息定义一些目的,如防止消息重复;(2)它不需要一个代理来管理消息流。它使用队列不存在特殊的经理,在另一个进程,这使得它容错;(3)客户端失败后可能存储消息。在使用静态队列,消息可以存储只要是必需的。所以,毕竟,每个节点可以接收所有消息发送给他们。缺点:(我)标准太不确定在许多细节。它可以以不同的方式解释。因此,实现可能有非常不同的特性;(2)它不假装迅速传递信息。其他标准可能会说,他们为快速开发的消息。但在Java创建JMS允许通信,它没有说关于交付的速度。
4.1.4。AMQP
AMQP关心消息运输的每一个过渡。这可用于分布式系统节点分组在困难的架构。同时,系统可以使用事务感兴趣这个协议。优点:(我)强大的控制消息流在每一个系统节点。它使用的地图解决信息和额外的框架,允许以确保每条消息被交付给每个转换节点;(2)它有一个事务模型。它允许完整的控制完成操作。在失败的情况下或取消操作,操作无法完成。它是有可能的,因为消息只能加工完成后一个事务。缺点:(我)它没有一个发布-订阅模型,导致使用相同的方式从出版商发送消息到用户,从点对点发送消息;(2)它增加了帧流。它使用框架来解决消息、终止交付等等。所以,它可能导致减少常见的消息的延迟是因为帧传输和处理。
4.2。评估协议实现的性能
4.2.1。准备评估队列处理性能
有两个提升线,即RabbitMQ和PahoMQTT Mosquitto代理(参见图3)。如图表所示,这些框架的延迟生长在整个测试。测试的增长开始乞讨。的峰值延迟测试的最后几秒钟。这不是一个好的结果。消息被发送的速度比可以交付。队列是不断积累和接收每个数据包延迟的时间。有一条水平线。这是FastRTPS。这个框架展示了一个非常稳定的数据传输消息的大小。 It is the best result. The last one left is GlassFish. Its graph is very similar to FastRTPS, but has delayed growth in the middle of the test. But the delay decreases in the second half of the test. It decreases because messages stop being sent and the queue stops being replenished, messages start being processed until they run out. GlassFish also has a higher delay than FastRTPS but less than 1 second. So, this is a good result.
在图4图,有一个延迟的消息大小为60000字节。有三个线上升。其中两个是RabbitMQ和PahoMQTT Mosquitto代理。他们没有改变他们的行为不像FastRTPS。这是第三个提升。情况比其他两个更可悲。FastRTPS延迟最高,增长通过测试。这可能是因为FastRTPS (Fast-DDS)使用UDP数据传输,这强加限制数据包大小和消息必须在一些地区传播如果大于65 kB,大大提高了数据传输延迟的消息。GlassFish不会改变其行为。其生长延迟到测试的中间,然后降低。 The delay is also under 1 second, which is the best result. Thus, according to the results of the two subtests, GlassFish shows the best stable and fastest queue processing performance.
4.2.2。评估节点的数量对性能的影响
在数据5- - - - - -8,最小和最大延迟和其均值和四分位范围可以看到不同数量的用户。也意味着和最大延误了为每个第五表的用户数量2。
GlassFish没有延迟依赖用户的数量。最大延迟变化和超过100毫秒,但不依赖。均值和mid-spread不到25毫秒。但差(四分位范围)很大,和它的大小大约是几毫秒。
FastRTPS也没有延迟依赖用户的数量。最小和最大测试期间的都是相同的。延迟范围从1秒到10 - 12毫秒。均值和mid-spread没有依赖,范围从1到4毫秒。差小于1毫秒。
PahoMQTT异常跳60和100毫秒15日和18订阅者。均值和mid-spread少于5毫秒。没有延迟依赖用户的数量。RabbitMQ也有类似的结果。有一个跳起来50毫秒订阅者和18日跳20毫秒数数量的用户。也没有延迟的依赖。
结果显示,没有框架依赖于用户的数量。这意味着软件处理队列的实现需要很短的时间内,不影响数据传输延迟在这些条件下。这是一个很好的结果,因为数据传输时间不会改变用户的数量。此外,GlassFish显示了最糟糕的结果,平均值约为10毫秒,而最大延迟达到几百毫秒。其他三个也有类似的手段和mid-spreads,但FastRTPS结果更好。然而,的最大延迟FastRTPS比RabbitMQ PahoMQTT,但最后两个未知异常延迟跳跃。
4.2.3。评估对延迟的消息大小的影响
在该测试中,消息大小变化每100条消息。图9显示了所有框架延迟的频率每秒100条消息。延误了几个消息的手段和最大值大小表中给出的框架3。
没有区别GlassFish图上的消息。好像与一个静态的消息被发送大小而增加的。延迟和最大的增加和减少在测试期间。最大延迟到达100毫秒。平均增长而消息大小小于1 MB。后就意味着是相似的,它们大约18毫秒。因此,GlassFish延迟不依赖于消息大小。
FastRTPS图显示延迟跳跃的频率随消息大小。这些跳跃重复重复测试时,这表明它们是测试造成的逻辑。但对于其他实现,没有这样的跳跃,可视为不稳定运行FastRTPS在这些条件。而且,平均和最大延迟增加消息大小。平均达到14.5毫秒和最大达到65.5毫秒最大消息大小。消息大小为1.5 MB,有一个不正常的上涨。最大延迟是160毫秒。因此,FastRTPS延迟取决于消息大小。它增加大小,但它是一个线性依赖。
PahoMQTT和RabbitMQ图看起来像楼梯。每个步骤都代表的消息大小的增加。所以,这两个框架的延迟取决于消息大小。的步骤是清楚而下的大小是1 MB。此后,延迟变得更加混乱。有一个有趣的特点:PahoMQTT显示一个更好的结果,直到消息大小达到1 MB。如果消息大小大于1 MB,意味着RabbitMQ的延迟小于PahoMQTT延迟。图中可以看到9RabbitMQ图是根据PahoMQTT图。但这些框架的最大值是相当接近。不同的是几毫秒。
结果显示,所有框架有一个显著的延迟消息大小的依赖,GlassFish除外。但最后一个有非常高的延迟。最大值是一样的,例如RabbitMQ。如前所述,如果消息大小小于1 MB, PahoMQTT比RabbitMQ,否则亦然。FastRTPS延迟类似于PahoMQTT延迟,但更分散。最大值的前几次大于后者。因此,RabbitMQ展示了最好的结果。GlassFish size-independent结果显示消息,但高的延迟。
4.2.4。抖动值估计和最小延误
在数据10和11图的最小的延迟消息大小。延迟对应于最小的一个,因为没有或最小的用户数据。在表4、延迟、抖动和RTT框架所示。从图和表中可以看出,GlassFish最高大约2.5毫秒的延迟和跳过20毫秒。抖动也很高,在半毫秒。这看起来像图上的粗线。这是一个糟糕的结果,因为没有其他消息或任何大的数据传输。所以,只有一个消息包含协议信息处理,这需要几毫秒。它也很不稳定,因为延迟分散约1毫秒。RTT还高,超过5毫秒的意思。这意味着接收机必须等待大约5毫秒从另一个客户回复。因此,这也是一个糟糕的结果。 FastRTPS has the lowest delay of 300 microseconds and jitter of 30 microseconds, which is the best result. But there are jumps over 2 milliseconds. This is not good and can be critical in some cases. RTT is about 2.5 milliseconds on a mean. But the maximum of RTT is below the GlassFish RTT mean, so this again indicates that the GlassFish results are poor. PahoMQTT + Mosquitto graph is similar to the FastRTPS graph. Both of them are thin lines in the graph. But PahoMQTT has twice the delay on the mean. The jitter maximum of PahoMQTT is also higher. The RTT mean of PahoMQTT is lower than the mean of FastRTPS, but the maximum of the former is higher than the latter. The RabbitMQ graph shows frequent jumps over 2 milliseconds while the mean is about 1 millisecond. This is bad because the real mean ranges up to 2 milliseconds which is similar to GlassFish. There are also abnormal jumps of up to 16 milliseconds. RabbitMQ RTT is about 3 milliseconds which is neither good nor bad. But the maximum of RTT is up to 20 milliseconds, which is also a problem.
结果显示,FastRTPS显示最好的最小延迟小于0.5毫秒。它也有最好的抖动值几十微秒。PahoMQTT Mosquitto经纪人也显示良好的最小延迟和抖动FastRTPS值非常接近。GlassFish还差最小的延迟和抖动值。RabbitMQ有比以前更好的结果,但是它有一个大的散射,可以看到在图上。
4.2.5。评估的影响相互作用过程的数量在不同条件下延迟
在该测试中,首先,我们将考虑频率的影响延迟发送消息。图12显示了结果FastRTPS, RabbitMQ, GlassFish。RabbitMQ FastRTPS以来结果有很大的不同,处理这样的数据流,不积累在任何消息队列大小。在GlassFish的情况下,队列出现在最小的消息大小和变化在整个测试范围从0到14的消息。队列似乎已经以每秒400条消息。GlassFish时已经出现问题,传输大约1.2 MB每秒。
对于Mosquitto PahoMQTT,结果很模糊,因为,在频率超过每秒400条消息,秒延迟增加,可以在图所取代13。这是由于长期执行消息的接收功能consume_message(见图14)。图15显示了一个图的执行时间读PahoMQTT库提供的API函数。
由于执行消息的接收函数,接收时间设置后,由于我们的系统检查时消息传播从用户的发送指向接收由另一个用户,而不是接收到消息时由操作系统或代理,或当出现在队列的消息的目的地。测试的开始时间大约是1毫秒,在一个大的背景下对接收到的消息的密度大大增加队列,减少了数据传输速率。测试系统不影响这些延迟以任何方式,但只有创建这种实现的条件显示了一个可怕的结果。
我们可以计算的数据量传输的频率每秒1000条消息在最后300条消息,有效载荷的大小达到最大值(见方程(1))。
FastRTPS RabbitMQ应付这个负载,虽然延迟各不相同,在FastRTPS的情况下,不要超过8个女士,和RabbitMQ的情况下,不超过30 ms。其余的实现不能承受这个负载和没有时间来处理队列,尽管所有的实现在一个循环中运行的间隔1毫秒。即检查新数据的时间间隔1 ms,而在最坏的情况下将一个额外的1毫秒的延迟。这可能发生,如果消息位于接收方完全结束后检查消息的存在。这个区间选择减少CPU上的负载。
GlassFish根本没有时间传输和处理这样的数据流,在MQTT的情况下,漫长的等待接收数据的原因还没有被调查,但可能与代理上的负载或长处理的数据在客户端。值得注意的是,这些结果可能不适用于任何情况消息传输与给定频率和给定的消息大小,而是这个特殊的测试场景中复杂的条件重新创建。
接下来,依赖的RTT的数量被认为是对交互流程。所有对是一样的,没有任何优先级数据传输的相互比较。从测试中,我们需要考虑不同的行为对流程和延迟对数量的影响。发送消息的频率是每秒400条消息,这给了一个相当大的数据流,但这并不创造条件积累巨大的队列的实现。
图16显示了FastRTPS RTT图三双的互动过程。图表上的跳跃尤其明显的每300消息,因为它是这个频率,消息大小增加。跳跃与重新分配的内存缓冲区,这创造了额外的延迟。任何消息大小的RTT时间不超过6 ms,最大的延迟实现中间的测试消息大小为0.7 MB。年底前发送数据的大小,减少延误。这种现象可以解释为,当消息大小变化时,一个小队列的消息出现时,添加一个RTT的重要组成部分,和300年年底发送下一个消息,队列消失和延迟下降到他们的真实值。最后的测试,延迟小于中间,由于没有队列和新消息停止发送,这样可以减少RTT。
当学习的影响的数量对,没有明显的依赖,但与大量的交互过程,在某些情况下最大RTT值增加。这些最大值不是从测试测试和随机重复,随机消息大小。如图所示的三双,RTT图形互相重叠,显示了进程间图书馆资源的均匀分布。这是一个很好的指标,因为它是一个信号,延迟的可预测性,这对于实时系统是非常重要的。之间均匀分配资源是非常重要的平等优先级数据传输通道,因为没有需要考虑的事实,网络中的任何节点将数据传输资源的一部分。没有需要减少传输的数据量一个通道的另一个地方。唯一例外的思考是有限的带宽。
分析GlassFish的结果,直接对和RTT的数量之间的关系,由于延迟两双流程工作时同时增加到原来的两倍,而当添加另一个对RTT增加秒(见图17)。在这种情况下,对非常相似的行为,尽管每一对的RTT值不是在FastRTPS一样亲密。这个软件解决方案不能处理负载的一对相互作用的过程,进程数量的增加,很多次负载的增加,队列迅速积累。
结果PahoMQTT Mosquitto是相似的,双的数量的增加,这个解决方案不应对,和内河货运已经与两对相互作用的过程,达到秒的顺序。图18显示了三双的图,有一个很大的消息大小,RTT达到几百秒。
这两个实现的行为并不满足实时系统的要求。
RabbitMQ,反过来,显示类似FastRTPS结果与随机过程对异常值和相同的行为,但明显的延迟增加到三一个案例中,也可以看到在图19。
4.2.6。调查延迟人工修复消息队列
考虑的情况下发送消息的10个字节没有间隔的最大可能的频率,但我们限制50消息队列。首先,在测试期间队列的状态被认为是。因此,FastRTPS保持队列状态的50条信息几乎在整个测试中,但也有罕见的单跳队列是空的,突然积累。GlassFish队列的状态是很不稳定的,不断波动从几个消息到50,RabbitMQ相似,但在范围从0到30的消息。这种情况解释的事实队列计算基于发送的消息数量之间的差异和接收到的消息的数量,并且也需要花费时间去发送一条响应消息。此外,检查新的消息,发生在间隔1 ms,这也让时间来处理队列中。
对于PahoMQTT Mosquitto,队列没有上升超过6消息和没有时间积累,因为一个节点没有时间和足够的频率发送数据。这也是因为这个实现等待消息传递信息收到之前发送一个新的。因此,这个解决方案不合理与别人比较,因为它在不同的条件。但是当测试没有等待这个信息的情况下,队列中跳跃的范围从0到35消息和延迟不超过2毫秒,和延迟的平均值是0.5毫秒。这个结果是最好的在所有的研究中实现。
图20.显示每个实现的延迟,因为FastRTPS显示最好的结果的结果延迟约6 ms, GlassFish显示一个巨大的传播价值,如果我们考虑高峰延迟和50个消息的队列的状态,结果花了120 ms提供50小消息,这是一个可怕的指示器。RabbitMQ变成了更糟糕的是,不像FastRTPS稳定;平均而言,这个实现还不到10毫秒的延迟队列小于30的状态消息。较小的队列,延迟大于FastRTPS。
4.3。结果比较
大量的论文指出,DDS是实时数据传输的最佳解决方案。的作者(26比较受欢迎的协议基于理论信息。他们得出的结论是,实时传输数据的问题很多很多DDS是最好的解决方案。
的作者(14)表明,DDS是交付性能的领导人之一。结果为DDS载荷大小2 B的同时,我们的结果在第四场景(部分4.2。4)。是有区别的2毫秒,因为在我们的实验设置每个节点执行传入消息检查一次1毫秒。因此,额外的延迟对RTT 2毫秒。
协议使用Anglova场景的比较是在[进行27]。结果表明,DDS实现OpenDDS RabbitMQ相比具有更低的延迟和抖动,ZeroMQ。
比较FastRTPS和ROS-MQTT (28]。结果表明,空消息的平均FastRTPS延迟620微秒。这是接近我们的结果在第三场景(部分4.2。3),FastRTPS平均延迟为128 B消息大小为570微秒。但是其他的结果不匹配,因为作者正在试验一种更为复杂的结构与网络数据传输,而我们的场景是一个单独的机器上运行。这也适用于MQTT的结果。但总的来说,结果表明,MQTT FastRTPS有优势与我们的研究结果相一致。
的作者(29日比较受欢迎的协议在性能方面的电子健康解决方案。他们认为协议从不同的角度,但与我们的结果一致:DDS是最好的解决方案。采样率的图是1000的同时,获得的结果在第五场景(部分4.2。5)。有许多不同的特定的值,因为实验设置是非常不同的。但总的来说,结果是相同的:DDS显示最好的延迟,其次是AMQP, JMS,最后MQTT,显示一个非常贫穷的延迟。作者总结他们的研究结果比较表中每个协议的优缺点。但在这个表、JMS等有很强的分“低延迟”和“适合实时应用程序。“这看起来很奇怪,因为DDS没有“低延迟”的优势,但更低的延迟的结果,和AMQP不适合实时应用程序”的弱点,但结果表明,AMQP相同或比JMS。
MQTT的分析,CoAP, XMPP是表现在30.]。在这项研究中,真实的数据,如温度、湿度和光线,为每个协议的100倍。结果表明,MQTT的平均延迟约589微秒。这是比的平均延迟CoAP(821毫秒)和XMPP(41毫秒)。由于温度、湿度、光和数据是轻量级和传输是在一个方向,MQTT的结果是一样的结果在第三场景(部分4.2。3):640微秒的MQTT消息大小为128 B。
MQTT导致第三个场景也是一样的结果从[31日),MQTT 1到1.5毫秒的延迟。两倍的差异可能是由于包通过网络传输时间,与我们的实验装置,所有组件(出版商、代理和用户)被放置在同一台机器上。
有很多比较AMQP和MQTT之间。在[32),作者AMQP的RTT和MQTT相比。结果表明,MQTT是略优于AMQP: AMQP的RTT约700微秒的RTT MQTT约500微秒。这正值RTT从第四场景(部分结果4.2。4)。几毫秒的差异解释的事实在我们的实验设置所有接收节点工作在1毫秒的等待周期,导致额外的延迟2毫秒的场景。其他小时间的差异可能是由于操作系统或不同版本的框架。
在[33),作者也比较RTT AMQP和MQTT表明AMQP更好的在大多数情况下。大多数AMQP测量值和MQTT范围从2毫秒6毫秒。这些结果与我们的结果对于第四场景(部分4.2。4)。但在我们的研究结果,MQTT是略优于AMQP,相反的结论(33]。这个原因可能是作者使用Python编程语言,或鼠兔图书馆的树莓派AMQP代理。
在[34),作者表明,AMQP和MQTT有相同的延迟(MQTT是略好)。由于作者没有提供详细的测试场景的描述,很难与我们的结果,但它的结果类似于第三个场景(部分4.2。3),AMQP和MQTT消息大小也有类似的延迟1 MB。
在[35AMQP和MQTT延误),比较不同的场景:从天气传感器发送的数据和发送数据从相机。结果表明,对于传感器的场景,MQTT延迟较低比AMQP(小于1毫秒)。由于传感器数据是轻量级的,这是重合的,第三个场景(节中获得的结果4.2。3128 B),消息大小,MQTT平均延迟为640微秒。但对于场景和相机,结果是逆转,AMQP有较低的延迟(少于13毫秒)。这也是一致的结果在第三场景(部分4.2。3):随着消息大小的增加,MQTT AMQP相比显示了更高的延迟。
的作者(36还得出结论,MQTT是更适合小消息大小。他们的研究结果表明,MQTT具有更低的延迟(从400微秒到500微秒)比AMQP(从800微秒到1100微秒)消息大小4096 B。这是与我们的结果在第三场景匹配(部分4.2。3)消息大小为128 B。延迟我们的结果是更高的,因为网络速度小于1 GB / s和代理有较低的系统特征。作者还尝试5000消息发送速率和消息大小为64 B。这是非常接近第一个场景中,消息被发送,没有间隔。结果匹配:延迟增加整个场景。
5。结论
描述协议是不同的初始目的。JMS是一个简单的消息标准在Java程序中,不指定消息传递机制。MQTT和AMQP协议消息使用不同的队列在一些细节。rtp有目的进行实时消息提供给用户通过更严格的规定。对实时系统,最好的MQTT和rtp协议。MQTT擅长传送小消息,虽然rtp是一个更加丰富和灵活的协议与更多的选择对于改变QoS。
本文提出了一种方法,允许调查软件解决方案在各种条件下的延迟,但这项研究的条件限制:(我)检查新消息的间隔是1 ms,而在最坏的情况下可以给1 ms的错误;(2)测试是在单个机器上使用网络数据传输协议,但最小化网络延迟的影响。因此,它假定网络是稳定的,虽然网络的不稳定可以极大地影响结果(37];(3)部分的测试3.1。2使用一个相当小的同时运行的用户数量;(iv)所有测试旨在调查延迟引入的中间件;(v)发达的方法,非标准行为的节点是刺激,例如增加传输数据的大小在一个测试中,这不是典型的。
考虑到结果,GlassFish是没有间隔消息发送的最佳解决方案。它可以用于系统的消息,在其他解决方案将是太慢了。但在所有其他情况下,最坏的结果,不能与其他解决方案。
泛美卫生组织非常善于传递消息的最小大小。它可能是一个好的解决方案系统非常小的消息,如命令,可以提出几个字节。
RabbitMQ是最快的解决方案之一。它显示了良好的在所有情况下,除了没有一个时间间隔发送消息。RabbitMQ在发送消息是最好的大尺寸和多个订阅者。
FastRTPS几乎是最好的解决方案。只有一个problem-message处理之间没有间隔发送消息。FastRTPS最稳定的延迟使得它可以预测的。在实时系统是非常重要的。
在物联网系统中几乎所有的调查情况。RabbitMQ和FastRTPS是好在大多数情况下,应该首先考虑。RabbitMQ应该与大系统使用消息和很多消费者相同的数据。FastRTPS应该使用在实时系统,延迟抖动较低,由一个恒定值有界。GlassFish和泛美卫生组织更有限的使用。他们应该使用只有在特殊情况下,如过于频繁的消息发送和low-size数据传输。
在构建一个系统的各种数据,包括小命令消息和大量的数据从传感器、摄像头、等,也体现了rtp协议的最好方法。但没有软件解决方案被认为是由美国提供的交货保证在同步模式下,在所有情况下,在某些情况下,有不可预知的跳跃和伴随增长的消息队列。提供真正的保证,有必要使用链路层协议,提供适当的功能和保证,因为应用程序层高度依赖外部因素。
数据可用性
没有数据被用来支持本研究。
的利益冲突
作者宣称没有利益冲突。
确认
这项研究由“ETU发展项目”LETI”框架内战略学术领导力”的项目优先级——2021年9月29日2030没有075-15-2021-1318。