锐英源精品开源心得，转载请注明：“锐英源www.wisestudy.cn，孙老师作品，电话13803810136。”需要全文内容也请联系孙老师。

物联网通信模式

Request/Response

Request/Response is perhaps the most commonly known communication pattern. It consists of a client, or caller, that requests a service from a server, or responder (Figure 1). This is the pattern that HTTP uses, and it’s the basis for service­oriented architecture, web services, and Representational State Transfer. It’s a useful pattern, especially if you have a client–server or master–slave architecture. Other protocols that support this pattern include the Constrained Application Protocol (CoAP) and the Extensible Messaging and Presence Protocol (XMPP).

请求/响应可能是最常见的通信模式。它由客户端或调用者组成，它从服务器或响应者请求服务（图1）。这是HTTP使用的模式，它是面向服务的体系结构，也是Web服务和Representational State Transfer的基础。这是一种有用的模式，特别是如果您有客户端服务器或主从架构。支持此模式的其他协议包括约束应用程序协议（CoAP）和可扩展消息传递和在线协议（XMPP）。

Figure 1. The Request/Response communication pattern

One drawback of this pattern, however, is the inequality of participants, which is also apparent in Internet topology. Bidirectional communication, where both parties request information from each other, may be difficult, especially if firewalls are present. You have to decide who the client is and who the server is. If you make a sensor the client and the middleware a server, the sensor can report its data when it chooses to, but the middleware will have difficulty fetching information when it wants to. If the sensor is the server and the middleware the client, the middleware can collect data when it needs to, but the sensor might not be protected by a firewall, leaving anybody able to connect to it. As a consequence, either events and event subscriptions or security is difficult to manage and sometimes require additional services or substantial resources if firewalls are used in the network.

然而，这种模式的一个缺点是参与者的不平等，这在因特网拓扑中也是显而易见的。双向通信，其中双方彼此请求信息，可能是困难的，尤其是在存在防火墙的情况下。您必须决定客户端是谁以及服务器是谁。如果您将客户端和中间件设置为传感器，则传感器可以在选择时报告其数据，但中间件在需要时很难获取信息。作为结果，如果传感器是服务器而中间件是客户端，则中间件可以在需要时收集数据，但传感器可能不受防火墙保护，任何人都无法连接到它。

Event Subscription活动订阅

The Event Subscription pattern allows a client to subscribe to events of a given type from a server. The server then informs the client each time the event is triggered, without having to constantly poll the server (Figure 2). Advanced event subscription mechanisms can include client­specific requirements of when events are desired and under what conditions. The benefits of using this pattern are that half of the messages aren’t needed over time and the latency of updates is kept to a minimum. Protocols that support this pattern include CoAP; XMPP; and the General Event Notification Architecture, which is part of the Universal Plug and Play architecture, an extended version of HTTP.

事件订阅模式允许客户端从服务器订阅给定类型的事件。然后，服务器会在每次触发事件时通知客户端，而不必经常轮询服务器（图2）。高级事件订阅机制可以包括客户端何时需要事件以及在什么条件下的特定要求。使用此模式的好处是，随着时间的推移，一半的消息不需要，并且更新的延迟保持在最低限度。支持这种模式的协议包括CoAP; XMPP; 和通用事件通知架构，它是通用即插即用架构的一部分，是HTTP的扩展版本。

Figure 2. The Event Subscription communication pattern

Asynchronous Messaging异步消息

Asynchronous messaging is the ability to send a message between peers in a network. The pattern assumes that messages can travel in both directions, and there’s no implied hierarchical difference between participants (Figure 3). If a protocol supports the Asynchronous Messaging communication pattern, all other communication patterns can be built on top of it. Protocols that support this pattern include XMPP; Advanced Message Queuing Protocol (AMQP); and, on the IP level, the User Datagram Protocol (UDP), although this latter protocol might have problems with firewalls.

异步消息传递是在网络中的对等体之间发送消息的能力。该模式假设消息可以在两个方向上传播，并且参与者之间没有隐含的等级差异（图3）。如果协议支持异步消息通信模式，则可以在其上构建所有其他通信模式。支持这种模式的协议包括XMPP; 高级消息队列协议（AMQP）; 并且，在IP级别上，用户数据报协议（UDP），尽管后一种协议可能存在防火墙问题。

Figure 3. The Asynchronous Messaging communication pattern

Reliable Messaging可靠的消息传递

For critical applications, it’s important to know that a message has been delivered exactly once to the destination, and the Asynchronous Messaging communication pattern does just that. The message can be lost en route, but using the Request/Response pattern, you can retry sending the message until an acknowledgement (or response) is returned from the destination. Because both the message and its response can be lost, this method makes sure that the message is delivered at least once to its destination, but at most once—or at least once—isn’t good enough for some applications, such as those that require transactions or those that do counting. Reliable messaging is a way to ensure that a message is delivered exactly once to its destination. Protocols that support reliable messaging include Message Queuing Telemetry Transport (MQTT), AMQP, and—through published open extensions—HTTP and XMPP.

对于关键应用程序，重要的是要知道消息已经准确地传送到目的地一次，而异步消息传递模式就是这样做的。消息可能在途中丢失，但使用请求/响应模式，您可以重试发送消息，直到从目标返回确认（或响应）。因为消息及其响应都可能丢失，所以此方法确保消息至少传递到目的地一次，但最多一次 - 或至少一次 - 对某些应用程序来说不够好，例如那些要求交易或进行计数的交易。可靠的消息传递是一种确保消息只传递到目的地一次的方法。支持可靠消息传递的协议包括消息队列遥测传输（MQTT），AMQP，

Multicasting多播

The previous patterns have concerned themselves with communication between two entities. Sometimes, however, a more efficient pattern is required if the same information is to be sent to multiple entities at the same time. The simplest such pattern is the Multicasting communication pattern. Here, the sender sends one message through an intermediary (a broker or router), which then distributes it to multiple recipients that have all requested participation in the communication (Figure 4). This pattern saves bandwidth because the sender doesn’t have to send individual messages to all parties by itself. In fact, the sender doesn’t even have to know who the recipients are. This pattern can be useful in many ways—for instance, when synchronizing multiple entities or when distributing information to many recipients. Protocols that support Multicasting include XMPP, AMQP, and UDP.

以前的模式关注两个实体之间的沟通。但是，有时，如果要将同一信息同时发送到多个实体，则需要更高效的模式。最简单的这种模式是多播通信模式。在这里，发送者通过中介（代理或路由器）发送一条消息，然后中介将其分发给所有请求参与通信的多个接收者（图4）。这种模式可以节省带宽，因为发送方不必自己向所有各方发送单独的消息。实际上，发件人甚至不必知道收件人是谁。此模式在许多方面都很有用 - 例如，在同步多个实体或向多个收件人分发信息时。

Figure 4. The Multicasting communication pattern

One word of caution, however: Although you can use this pattern to save bandwidth, it’s often used as a means of overcoming restrictions in the chosen protocol and its support of the Event Subscription pattern, as well. In addition, multicasting is inherently difficult to secure, and it’s more efficient in terms of bandwidth only if the recipients actually use most of the values transmitted. If you use frequent multicasting to decrease latency in a network where Event Subscription is desired but not possible, the Multicasting pattern might drastically increase rather than decrease the bandwidth required.

但需要注意的是：虽然您可以使用此模式来节省带宽，但它通常用作克服所选协议中的限制及其对事件订阅模式的支持的方法。此外，多播本质上很难保护，只有当接收者实际使用大多数传输的值时，才能在带宽方面更有效。如果您使用频繁多播来减少需要事件订阅但不可能的网络中的延迟，则多播模式可能会大幅增加而不是减少所需的带宽。

Publish/Subscribe发布/订阅

The Publish/Subscribe communication pattern is an extension of the Multicasting pattern, with the principal difference that messages transmitted are also stored on the intermediary node. The messages, or a reference to the messages, are then distributed to the corresponding subscribers, depending on protocol. Only the latest message is stored, a given number of messages are stored, or all messages are stored on the intermediary, depending on protocol chosen and the settings on the intermediary. The difference between distributing the entire message and distributing only a reference to the message is important and affects the performance of the solution in terms of consumed bandwidth. If subscribers consume most of the messages, forwarding the messages themselves is more efficient, as in the case of multicasting. If, however, consumption occurs only on demand, then sending shorter references is more efficient because these messages are smaller and subscribers will use only a minority of them to fetch an actual message. To fetch a message in the latter case, a separate Request/Response action needs to be performed. Protocols that support the Publish/Subscribe pattern include MQTT, AMQP, and XMPP.

发布/订阅通信模式是多播模式的扩展，主要区别在于传输的消息也存储在中间节点上。然后根据协议将消息或对消息的引用分发给相应的订户。根据所选协议和中间设置，仅存储最新消息，存储给定数量的消息，或者将所有消息存储在中间消息上。分发整个消息和仅分发对消息的引用之间的区别很重要，并且会影响解决方案在消耗带宽方面的性能。如果订阅者消耗大部分消息，则转发消息本身更有效，如多播的情况。但是，如果消费仅在需要时发生，然后发送更短的引用更有效，因为这些消息更小，订阅者将只使用其中的少数来获取实际消息。要在后一种情况下获取消息，需要执行单独的请求/响应操作。支持发布/订阅模式的协议包括MQTT，AMQP和XMPP。

Queues队列

Queues—or first in, first out queues—is a communication pattern that allows one or more entities to post messages or work items to a queue, and then lets one or more receivers receive these messages in an ordered fashion (Figure 5). The queues typically reside on an intermediary node or network to which all participants are connected. Queues are an excellent tool for balancing load, where work items collected from multiple sources need to be distributed among existing workers, perhaps having different performance. By using a queue, you avoid any hard links between data providers and workers and can thus easily extend or constrict both the set of data providers and the set of workers, depending on actual work load. Among the protocols discussed in this article, only AMQP supports queues natively.

队列-或先进先出队列 - 是一种通信模式，允许一个或多个实体将消息或工作项发布到队列，然后让一个或多个接收者以有序的方式接收这些消息（图5）。队列通常驻留在所有参与者所连接的中间节点或网络上。队列是平衡负载的绝佳工具，从多个来源收集的工作项需要在现有工作人员之间分配，可能具有不同的性能。通过使用队列，您可以避免数据提供者和工作者之间的任何硬链接，从而可以根据实际工作负载轻松扩展或限制数据提供者集和工作者集。在本文讨论的协议中，只有AMQP本身支持队列。

Figure 5. The Queue communication pattern

Message Brokers消息代理

Essentially standardized middleware components, message brokers provide an elegant solution to the problem that firewalls impose on bidirectional communication between peers in a network. They work by allowing entities to connect to them, and then broker messages between connected clients. Because all connections are made from the devices toward the broker, only the broker needs to be accessible from the Internet. Firewalls don’t need to accept or forward incoming connections to devices, as would be required if you used a strict peer­to­peer protocol.

基本上是标准化的中间件组件，消息代理为防火墙对网络中对等体之间的双向通信提出了一个优雅的解决方案。它们通过允许实体连接到它们，然后在连接的客户端之间代理消息来工作。由于所有连接都是从设备向代理进行的，因此只需要从Internet访问代理。如果您使用严格的peertopeer协议，防火墙不需要接受或转发到设备的传入连接。

Apart from brokering messages, brokers can provide important services to connected entities, such as acting as intermediaries in the Multicasting, Publish/Subscribe, and Queue patterns. Message brokers also typically provide client authentication services, something that can be tricky for connected devices in distributed networks. So, if the broker forwards the identities of already­authenticated parties included in the communication, entities can use this information to make security decisions without the need to implement customized authentication in each device. Although peer­to­peer­communication might be an option to many, such solutions must handle client authentication themselves to avoid becoming insecure. If you use a protocol that includes message brokers, you might not need to develop your own middleware to make your solutions work. Protocols that use brokers in some form or another include XMPP, AMQP, and MQTT.

除了代理消息之外，代理还可以为连接的实体提供重要的服务，例如在多播，发布/订阅和队列模式中充当中介。消息代理通常还提供客户端身份验证服务，这对于分布式网络中的连接设备来说可能很棘手。因此，如果代理转发通信中包含的已经认证方的身份，则实体可以使用该信息做出安全决策，而无需在每个设备中实现自定义认证。虽然peertopeercommunication可能是许多人的选择，但这种解决方案必须自己处理客户端身份验证，以避免变得不安全。如果您使用包含消息代理的协议，则可能不需要开发自己的中间件来使解决方案正常工作。

Federation联合

Federation is an important pattern in which a global network is partitioned into logical parts to allow for global scalability and organic growth (Figure 6). The key here is to allow for growth without limiting the performance of the existing network using a divide­and­conquer approach. In unbrokered communication, such as that done using HTTP or CoAP, federation takes place at the domain level. Each domain points to its own set of IP addresses hosting its own web server. You can add new web servers on new domains without limiting access to existing web servers. This has been a key feature for the success and scalability of the World Wide Web.

联合是一种重要的模式，其中全局网络被划分为逻辑部分，以实现全局可扩展性和有机增长（图6）。这里的关键是允许增长，而不是使用divideandconquer方法限制现有网络的性能。在未经编辑的通信中，例如使用HTTP或CoAP完成的通信，联合发生在域级别。每个域都指向托管自己的Web服务器的自己的IP地址集。您可以在新域上添加新的Web服务器，而不会限制对现有Web服务器的访问。这是万维网成功和可扩展性的关键特征。

Figure 6. Federation

When using a brokered protocol that supports federation, the brokers connect between themselves to route or relay messages. Each broker handles authentication on its own domain and recognizes how to connect to other domains to forward messages to them. The best­known brokered protocol that supports federation is the Simple Mail Transport Protocol. Among the brokered protocols discussed in this article, only XMPP supports federation. Federated brokered networks provide an elegant way to attribute a global identity to each entity.

当使用支持联合的代理协议时，代理会在它们之间进行连接以路由或中继消息。每个代理在其自己的域上处理身份验证，并识别如何连接到其他域以将消息转发给它们。支持联合的最着名的代理协议是简单邮件传输协议。在本文讨论的代理协议中，只有XMPP支持联合。联合代理网络提供了一种将全局身份归因于每个实体的优雅方式。

Discovery发现

Several problems arise in a mass­distribution scenario. First, things don’t know either the network identity nor the identity of the owner at production time: They know only their conceptual identity. After installation and configuration, which preferably you use some zero­configuration technique to achieve, they learn their new network identity but not the identity of the owner. In contract, the owner knows its own network identity and the conceptual identity of the things, perhaps by scanning a sticker on the box. The Discovery communication pattern creates a mechanism whereby the network identity of the things is matched to the network identity of the owner using the common knowledge of the things’ conceptual identity (Figure 7). This occurs using a Thing Registry available on the network to both the things and the owner. The things register their conceptual identity with the registry, and the owner claims the things using only their conceptual identity. If successful, the network identities of each are sent to the other, and both then know how to communicate with each other. An extension to XMPP exists to support this pattern.

在大规模分配方案中出现了几个问题。首先，在生产时，事物既不知道网络身份也不知道所有者的身份：他们只知道他们的概念身份。在安装和配置之后，最好使用一些零配置技术来实现，他们会学习新的网络身份但不知道所有者的身份。在合同中，所有者可以通过扫描盒子上的标签来了解自己的网络身份和事物的概念身份。Discovery通信模式创建了一种机制，利用事物概念身份的常识，将事物的网络身份与所有者的网络身份相匹配（图7）。使用网络上可用的Thing Registry对事物和所有者都会发生这种情况。这些东西在注册表中注册他们的概念身份，并且所有者仅使用他们的概念身份来声明事物。如果成功，则将每个网络身份的网络身份发送给另一个，然后两者都知道如何相互通信。存在XMPP的扩展以支持此模式。

Figure 7. Discovery

Delegation of Trust信任委托

On the Internet, it’s important to be able to make good security decisions. Delegation of Trust is a communication pattern in which a thing forwards a request to a stronger, trusted entity in real time, and then performs the action when a response is returned based on the contents of the response (Figure 8). This trusted entity can then either use machine learning or direct communication with the owner of the thing to learn how to respond to new requests on the network related to the things belonging to him or her. For this pattern to be possible, asynchronous bidirectional messaging in real time is required. An extension to XMPP exists to support this pattern.

在互联网上，能够做出良好的安全决策非常重要。信任委托是一种通信模式，其中事物实时地将请求转发给更强大的可信实体，然后在基于响应的内容返回响应时执行该操作（图8）。然后，该可信实体可以使用机器学习或与事物的所有者直接通信来学习如何响应与属于他或她的事物相关的网络上的新请求。为了使这种模式成为可能，需要实时异步双向消息传递。现有XMPP的扩展能支持此模式。

Figure 8. The Delegation of Trust communication pattern