关于消息传递协议——EEJournal - 亚博首页官网手机登录,亚博yabovip2019进入

它始于一个审查几周前几个流浪新(对我)我看到协议。我做了一个粗略的回顾每一个,称它为好。

它引发了长讨论LinkedIn关于各种协议的能力。讨论建议我另一层的细节是必要的。那时,我不知道我在,不然我可能会发现更容易处理的,平方,哦,一个圆或证明黎曼假设。

但是不,我幸福地进入了空白。你可能期望一个空白是空的,但是这个空白是过度;只是缺乏结构和清晰。虽然常说,物联网(物联网)需要的标准,我们游览面积遭受太多的标准。每一个解决一个稍微不同的问题,所以我们需要他们所有,但男人…它可以压倒性的涉水。坦白说本文的目的:提供一些清晰不同的协议。

好消息是,我学会了很多东西,其中一些我希望通过在这里和一些在未来我们可能会讨论的话题。完全有可能,我错过了或者误解一些细节;我指望读者更多的专家在一个特定的区域提供修正在下面的评论中。

我发现在特定的一个挑战是,每个人都从不同的地方来到这个讨论。server-oriented家伙,受限资源标准不是有用,因为他们缺少太多的功能。微型嵌入式设备的人,大,功能齐全的标准只是不切实际。面向rest人安静地工作;其他人慌张地工作。所以我的目标是与世界观的一部分,如果可能的话。我将具体判断。

过滤协议

为了保持一个合理的范围,我们将专注于消息传递协议。我们会看到,“消息”仍然是一个重载的术语,但至少我们不会关注低级PHY或中层运输问题。有一些新的低层协议——特别是当谈到所谓的低功耗/广域(LPWA)协议。我们看到一个,简而言之,SIGFOX;罗拉是另一个,我们可以深入。但问题这一水平是非常不同的从消息级别协议所面临的问题,所以我不想把它们混合起来。我们会做他们另一个时间。

还有一类…嗯,“协议”不太合适的词——也许“平台”?——扔我一个循环。它往往涉及与“MQ”事情的结局,虽然不是全部。代表“MQ消息队列”,与协议支持发布-订阅,你发布一个队列。队列驻留在一个经纪人,经纪人可以确保你的信息到所有的用户。

这种代理的上下文中可能存在一个单独的协议。例如,MQTT经纪人;CoAp不会。可以实现DDS有或没有经纪人。

但我然后我遇到所谓的RabbitMQ时抛出,我通过ZeroMQ和Nanomsg。而后者两个确实出现的消息传递格式,语言描述RabbitMQ(以及另一个我会在一个时刻)似乎没有意义。它听起来像实现了AMQP和MQTT消息传递协议。但AMQP和MQTT,正如我们将看到,有非常不同的特性。一个高的层次会做什么呢?提取它们,…,使它们看上去都很像?

快速交流与他们接触我的混乱的起源。RabbitMQ经纪人在一个不同的意义。当然保持消息队列时,一个大的一部分工作是汇集的部分系统使用不同的协议。所以消息进来MQTT运往代理服务器实现AMQP被翻译。

这样的经纪人不是这么多“之上”的其他协议“之间”。因此,我没有包括他们的比较。他们在服务器中实现,而不是设备或端点。他们也倾向于增加功能和商业的支持级别。

经纪人我确认:

RabbitMQ(主要AMQP的实现,但其他协议桥接)
ActiveMQ(都有自己的网络协议称为OpenWire)

也有一些标准实施运输,而不是或除了TCP或UDP。我纠结是否真的在同一水平上的其他消息传递协议。我决定他们似乎更低,所以我在这里列出来,继续:

线程
ZeroMQ
Nanomsg

JMS还分为集团,我不会,因为它似乎是一个纯java服务器到服务器协议。

其余的消息传递协议,这是我们将如何进行。目的是总结表,但首先,我将描述我要的特性包括表中(一个稀疏的子集的所有可能的功能,相信你我!)。然后我会做一个快速的总结每一个协议,我们会完成表。我们开始吧…

我们比较的特性

表从协议名称以及它的赞助商和标准化的实体(并不总是一回事)。所包含的特性我可能不明显,但目的是关注一些特点,似乎在你可以选择产生影响。我敢肯定还有其他的功能,你想,也许你认为有些是不必要的。我们很高兴接受所有这些想法的评论。

消息“模式”

最常见的一个是发布/订阅(或“发布/订阅”,缩写为“P / S”表中)。这种模式使端点距离,代理跟踪谁的出版,谁希望看到的数据。根据标准,出版商可能会或可能不会知道是谁订阅其数据。“主题”是一个重要的概念,因为它订阅的基础,但它也能概念是否可以直接“地址”另一个设备,我们将讨论在一分钟。

其他常见的模式请求/响应(通常缩写为“请求/代表”;表中显示为“R / R”)。这来自于HTTP模型:一方发出请求;对方回应。它非常不同于pub / sub在很多方面,最重要的是,pub / sub往往是数据推动;要求/代表往往是数据。可能有另一个单独的文章关于这些方法的差异;现在我们将保持这个短暂的。

还有其他模式,一般不支持:

点对点(p2p),缩写为“p p”表中
活跃的并发事务(可用性)——似乎独特XMPP
管道(聚合和负载平衡为例)
调查(单个请求的多个应用程序)

事实上,唯一一个我看到最后两个明确提及Nanomsg,低水平。说,一些协议,比如XMPP,允许扩展,所以你有时可以建立一个新的模式已经存在(XMPP如何支持发布/订阅)。

的服务质量或QoS

也称为消息的可靠性。这是一个广泛的地区广泛的特性。消息处理你是否只是扔在墙上(在这种情况下,它可能会或可能不会得到交付)或你是否得到确认,与可能的排队,以防用户恰好是离线,也许与生存时间设置,这样你就不会永远等待,订户回来(和未交付的消息应该发生什么)。

甚至还有一些分歧(惊喜!)——一个讨论说MQTT的最高水平的可靠性无法工作。我们将推迟到另一个时间详细讨论。

注意,许多协议层通过TCP和TCP本身具有某种程度的交货保证。所以你可能想知道为什么一个协议需要做更多的工作。显然在保证存在差距,可能有延迟TCP实现网络有问题,肯定有比TCP更精细的计划。表中,你可能会看到“TCP”QoS;这仅仅意味着协议不指定自己的QoS超出TCP。

安全

比如,协议定义自己的安全?如果没有,安全是如何实施的?许多依靠TLS / SSL协议;其他人把它应用程序;一些使用迪泰。我们不会进入不同的方式这样做的细微差别(另一个大的话题);我们将简单地总结。

“解决”

这是我根据更新的专有协议称为为企业与一家名为实时逻辑——和它的主要动力在于它让一个端点直接解决另一个。如果你想打开一个特定设备或得到一个特定的测量,然后一般pub / sub主题(尤其是在一个没有发现的协议)并不是有用的——除非你想要有一个独立的主题为每个设备。即使这样,没有发现,你可能不知道的IDs端点

在这种情况下,如果你想在资源受限的设备上,实现代码CoAp和MQTT是显而易见的选择。如果你不想让其余的模型(我们会讲到,在sec),然后让MQTT,直接寻址和MQTT是困难的。所以这些为企业创建的。

我试图捕捉的“解决”这种性质列是为每个协议解决。

RESTful或不安*

我在如何表示,因为它涵盖了两个相关,但不同的问题。

一个是编程的风格。总的来说,我认为RESTful api是熟悉和舒适的网络和服务器程序员用于处理HTTP请求和不得不解决负载平衡和不可靠的连接。

我把其他的风格更熟悉嵌入式系统程序员。这些都是“真正的”编程语言如C / c++和Java。不同的是,休息,几乎都是通过四个命令:把,GET、POST和删除。没有休息,你有特定的api,将取决于协议或实现。

但语言熟悉是一个表面上的区别。更根本的是如何处理应用程序状态的差异。不安分的方法,假设进行连接或至少一个可预测的目的地发送消息。

状态是隐含在焦躁不安的消息:如果你发送一个消息说,“关闭风扇”,然后另一个说,“断电”,然后你假设谈话随着时间的推移,在第一个风扇是关闭然后设备断电。你的假设是,风扇确实成功地关闭(仅仅因为消息到达成功并不意味着操作成功完成)。

REST架构使得没有这样的假设。没有这样的概念作为一个长期的连接或谈话。你请求什么,你得到一个答案,你就完成了。叫它海鲂因素:虽然你可能会执行一个“关闭风扇”指令,系统没有的记忆,在传递消息。每个消息一样新鲜和新第一人。“哦,看,一个消息!太酷了!哦,看,一个消息!酷!”不:“哦,看,另一个消息”,没有“另一个”如果你不记得前一个。事实上,一个负载平衡器可能将两条消息发送到两个不同的服务器,这就是为什么你不想依靠其中一个记住刚刚发生了什么事。

在这种情况下你必须程序不同。在焦躁不安的情况下,你可能有某种应用层确认。在休息的设置中,相比之下,你可能需要,例如,首先测试风扇,确保你不意外断电没有先关闭风扇。另一个典型的例子是改变设置——比如说,一个温度。如果你说,“降低温度1度,那么它可能会或可能不会发生在一个不可靠的设置。如果你说,“设置温度为65度,”然后端点可以检查自己的当前设置和减量或没有(甚至增加)。

这是另一个很大的话题,双方的支持者和批评者。我们会留下更多的深度。我只想说,你可能会不高兴如果你选择错误的方法为您的应用程序和程序员。

限制资源

一些协议是专门为设备的资源,有些不是,有些可能允许限制实现足够如果您省略可选特性。什么是“约束”将随视角。有些人想到几千字节的代码;根据RTI, DDS方法500 k字节的限制版本。

的协议(表中给出的顺序)

MQTT适用于受限资源设备。它来自IBM;反对者会说,这是没有得到任何实质性的进展。这是通过TCP和Websocket实现。它需要一个有序,无损,双向连接。

它有基本的QoS服务:

——提供最多一次(可能不会获得)

提供至少一次(可能会重复)

——准确地提供一次——这是争论不可能实现。我们将再次讨论另一个时间。

客户端发起连接;服务器充当经纪人。主题为订阅服务。据我所知,没有发现过程——这就是为什么解决特定的设备是很困难的。有五个包类型:连接、发布订阅,退订,平。有一些异常事件的规定以及一些基本的信息生命周期管理。安全在很大程度上是通过最佳实践。

CoAp是另一个要按着小型设备的协议,它使用REST模型。这在很大程度上是HTTP,一些修改—特别是,四个其他命令的具体含义从HTTP略有不同的含义。

它运行在UDP,没有交付担保。这是其余的性质可以是有用的。信息可以被标记为“可证实的“如果你想要一个承认收据(超时和指数关闭后重新发送模型)。消息可以uni -或散播。

XMPP实际上开始随着你使用即时消息。这是一个xml驱动的协议从根本上点对点(通过一个服务器),但是有一个扩展来实现发布/订阅。你可以确认一个特定的端点的存在或可用性,和端点必须支持发现。

数据被组织成“节”通过永久XML流在长寿的TCP连接。地址是全球和指定为jid(代表“Jabber ID”由于历史原因)。一个特定的扩展可用来改进TCP。

AMQP是一个重大的协议。时期。似乎更适合服务器到服务器的消息。它包括以下功能:

以信用为基础的流控制(减缓交通瓶颈是否备份)

队列(如果订户下降)

——持久性和可用性特性

——交易(自动执行一系列命令)

多路复用(容易消息通过防火墙)

——信任实体通过Kerberos身份验证

它有自己的链接和传输层以上TCP / IP。消息首先分层。有复杂的可靠性特性——远远超过我们可以在这里讨论。

DDS或分布式数据服务,是我们更详细地讨论之前。它可以有或没有代理实现,其核心定义特点是data-centricity,而不是message-centricity。我们讨论的区别分别。也是为了非常可伸缩;这是一个强有力的系统。

在DDS基础设施安全一直是一个洞。它被解决和安全方案,目前处于测试阶段等待终结。

为企业是专有实时逻辑协议,对感知到的弱点MQTT和CoAp小型设备。其主要特点是使用一个“短暂的ID”指定的代理和包含在消息,这样回答可以定向到特定的端点。的目的是更容易控制或与特定的节点通信。

通过HTTP连接开始“升级”到Websocket连接(基本上,TCP的概念更高级的数据包;我们将更详细地讨论另一个时间)。

实现是用Lua编写的脚本语言,并可以实时逻辑套件的一部分的嵌入式设备栈件。也就是说,他们表示,如果有兴趣,他们可能愿意打开它。

HTTP / 2是下一个牧师的HTTP。显然很多人使用“点”或“v”或“牧师”命名,所以,任何好的潮人的生气,他们的秘密已经主流,现在我们正在做“削减”指示修订。

这不是一个消息传递协议本身,但建议在许多博客存在一些性能上的限制过去可能解决这个修改,使它适合物联网与云计算和通信。它支持流和“服务器推”——当一个服务器仍然不能启动一个连接(只有客户可以做到——重要的安全性),它可以启动流在一个开放的连接。

与HTTP标头的一大问题;有一个哈夫曼编码方案压缩为小型设备有限的资源;HPACK是功能的实现。

AllJoyn实现了一个“接近网络”——一个我们讨论了概念去年。它只在一个本地网络运营,未来可能提供网关无线个域网,z - wave,云。这是告诉你对你的立体声扬声器等点到点近战的交互。主要是基于远程过程调用(RPC)模型,虽然他们的数据驱动的API允许pub / sub,与含有数据或事实而不是命令的信息,以及数据结构嵌入到消息中。

每个端点实现了一个路由器,除了小型嵌入式设备,通过使用一个瘦客户端,可以利用路由器在其他设备。发现的巨大自省:实现方法,属性,信号,对象,对象路径,事件和动作都可以查询自己的本质。自我审视的互联网。

有一个基地核心库,他们实现了一个更高级别的服务框架库。后者不是必需的,但它是唯一的方法来确保互操作性。

最后,跺脚我讨论这是否属于这里或经纪人(除非它是一个协议)或传输协议(尽管它似乎高于,说,ZeroMQ)。事实上,它更像一个企业级服务器到服务器的协议JMS -与其说物联网。但它是语言无关,所以我决定把它在这里。

STOMP代表“流(或简单的)种面向文本的消息协议。”其重点是简单性和互操作性。称为轻量级的,虽然我的感觉是,这意味着它很容易实现,开始——它并不一定节约资源的嵌入式设备需要。

设计理念类似于HTTP,但它不是RESTful。有一组相对稀疏的命令:连接、发送、订阅,退订,开始提交,Ack Nack,断开连接。

对于所有这些协议,高层特征总结在下表中。