Network Working Group J. Ott
Request for Comments: 3259 TZI, Universitaet Bremen
Category: Informational C. Perkins
USC Information Sciences Institute
D. Kutscher
TZI, Universitaet Bremen
April 2002
Network Working Group J. Ott
Request for Comments: 3259 TZI, Universitaet Bremen
Category: Informational C. Perkins
USC Information Sciences Institute
D. Kutscher
TZI, Universitaet Bremen
April 2002
A Message Bus for Local Coordination
用于本地协调的消息总线
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
The local Message Bus (Mbus) is a light-weight message-oriented coordination protocol for group communication between application components. The Mbus provides automatic location of communication peers, subject based addressing, reliable message transfer and different types of communication schemes. The protocol is layered on top of IP multicast and is specified for IPv4 and IPv6. The IP multicast scope is limited to link-local multicast. This document specifies the Mbus protocol, i.e., message syntax, addressing and transport mechanisms.
本地消息总线（Mbus）是一种面向消息的轻量级协调协议，用于应用程序组件之间的组通信。Mbus提供通信对等点的自动定位、基于主题的寻址、可靠的消息传输和不同类型的通信方案。该协议在IP多播之上分层，并为IPv4和IPv6指定。IP多播范围仅限于链路本地多播。本文件规定了Mbus协议，即消息语法、寻址和传输机制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Mbus Overview . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Purpose of this Document . . . . . . . . . . . . . . . . . . 5
1.3 Areas of Application . . . . . . . . . . . . . . . . . . . . 5
1.4 Terminology for requirement specifications . . . . . . . . . 6
2. Common Formal Syntax Rules . . . . . . . . . . . . . . . . . 6
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 7
4. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Mandatory Address Elements . . . . . . . . . . . . . . . . . 10
5. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . 11
5.1 Message Encoding . . . . . . . . . . . . . . . . . . . . . . 11
5.2 Message Header . . . . . . . . . . . . . . . . . . . . . . . 11
5.3 Command Syntax . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Mbus Overview . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Purpose of this Document . . . . . . . . . . . . . . . . . . 5
1.3 Areas of Application . . . . . . . . . . . . . . . . . . . . 5
1.4 Terminology for requirement specifications . . . . . . . . . 6
2. Common Formal Syntax Rules . . . . . . . . . . . . . . . . . 6
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 7
4. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Mandatory Address Elements . . . . . . . . . . . . . . . . . 10
5. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . 11
5.1 Message Encoding . . . . . . . . . . . . . . . . . . . . . . 11
5.2 Message Header . . . . . . . . . . . . . . . . . . . . . . . 11
5.3 Command Syntax . . . . . . . . . . . . . . . . . . . . . . . 12
6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1 Local Multicast/Broadcast . . . . . . . . . . . . . . . . . 14
6.1.1 Mbus multicast groups for IPv4 . . . . . . . . . . . . . . . 15
6.1.2 Mbus multicast groups for IPv6 . . . . . . . . . . . . . . . 15
6.1.3 Use of Broadcast . . . . . . . . . . . . . . . . . . . . . . 16
6.1.4 Mbus UDP Port Number . . . . . . . . . . . . . . . . . . . . 16
6.2 Directed Unicast . . . . . . . . . . . . . . . . . . . . . . 16
7. Reliability . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Awareness of other Entities . . . . . . . . . . . . . . . . 20
8.1 Hello Message Transmission Interval . . . . . . . . . . . . 21
8.1.1 Calculating the Interval for Hello Messages . . . . . . . . 22
8.1.2 Initialization of Values . . . . . . . . . . . . . . . . . . 23
8.1.3 Adjusting the Hello Message Interval when the Number of
Entities increases . . . . . . . . . . . . . . . . . . . . . 23
8.1.4 Adjusting the Hello Message Interval when the Number of
Entities decreases . . . . . . . . . . . . . . . . . . . . . 23
8.1.5 Expiration of hello timers . . . . . . . . . . . . . . . . . 23
8.2 Calculating the Timeout for Mbus Entities . . . . . . . . . 24
9. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1 mbus.hello . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.2 mbus.bye . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.3 mbus.ping . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.4 mbus.quit . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.5 mbus.waiting . . . . . . . . . . . . . . . . . . . . . . . . 26
9.6 mbus.go . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 27
11. Mbus Security . . . . . . . . . . . . . . . . . . . . . . . 28
11.1 Security Model . . . . . . . . . . . . . . . . . . . . . . . 28
11.2 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.3 Message Authentication . . . . . . . . . . . . . . . . . . . 29
11.4 Procedures for Senders and Receivers . . . . . . . . . . . . 30
12. Mbus Configuration . . . . . . . . . . . . . . . . . . . . . 31
12.1 File based parameter storage . . . . . . . . . . . . . . . . 33
12.2 Registry based parameter storage . . . . . . . . . . . . . . 34
13. Security Considerations . . . . . . . . . . . . . . . . . . 34
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
A. About References . . . . . . . . . . . . . . . . . . . . . . 37
B. Limitations and Future Work . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 39
6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1 Local Multicast/Broadcast . . . . . . . . . . . . . . . . . 14
6.1.1 Mbus multicast groups for IPv4 . . . . . . . . . . . . . . . 15
6.1.2 Mbus multicast groups for IPv6 . . . . . . . . . . . . . . . 15
6.1.3 Use of Broadcast . . . . . . . . . . . . . . . . . . . . . . 16
6.1.4 Mbus UDP Port Number . . . . . . . . . . . . . . . . . . . . 16
6.2 Directed Unicast . . . . . . . . . . . . . . . . . . . . . . 16
7. Reliability . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Awareness of other Entities . . . . . . . . . . . . . . . . 20
8.1 Hello Message Transmission Interval . . . . . . . . . . . . 21
8.1.1 Calculating the Interval for Hello Messages . . . . . . . . 22
8.1.2 Initialization of Values . . . . . . . . . . . . . . . . . . 23
8.1.3 Adjusting the Hello Message Interval when the Number of
Entities increases . . . . . . . . . . . . . . . . . . . . . 23
8.1.4 Adjusting the Hello Message Interval when the Number of
Entities decreases . . . . . . . . . . . . . . . . . . . . . 23
8.1.5 Expiration of hello timers . . . . . . . . . . . . . . . . . 23
8.2 Calculating the Timeout for Mbus Entities . . . . . . . . . 24
9. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1 mbus.hello . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.2 mbus.bye . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.3 mbus.ping . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.4 mbus.quit . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.5 mbus.waiting . . . . . . . . . . . . . . . . . . . . . . . . 26
9.6 mbus.go . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 27
11. Mbus Security . . . . . . . . . . . . . . . . . . . . . . . 28
11.1 Security Model . . . . . . . . . . . . . . . . . . . . . . . 28
11.2 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.3 Message Authentication . . . . . . . . . . . . . . . . . . . 29
11.4 Procedures for Senders and Receivers . . . . . . . . . . . . 30
12. Mbus Configuration . . . . . . . . . . . . . . . . . . . . . 31
12.1 File based parameter storage . . . . . . . . . . . . . . . . 33
12.2 Registry based parameter storage . . . . . . . . . . . . . . 34
13. Security Considerations . . . . . . . . . . . . . . . . . . 34
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
A. About References . . . . . . . . . . . . . . . . . . . . . . 37
B. Limitations and Future Work . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 39
The implementation of multiparty multimedia conferencing systems is one example where a simple coordination infrastructure can be useful: In a variety of conferencing scenarios, a local communication channel can provide conference-related information exchange between co-located but otherwise independent application entities, for example those taking part in application sessions that belong to the same conference. In loosely coupled conferences such a mechanism allows for coordination of application entities, e.g., to implement synchronization between media streams or to configure entities without user interaction. It can also be used to implement tightly coupled conferences enabling a conference controller to enforce conference wide control within an end system.
多方多媒体会议系统的实现是一个简单的协调基础设施可能有用的示例：在各种会议场景中，本地通信信道可以在位于同一位置但在其他方面独立的应用实体之间提供与会议相关的信息交换，例如，参加属于同一会议的应用程序会话的人。在松散耦合的会议中，这种机制允许应用实体的协调，例如，实现媒体流之间的同步或在没有用户交互的情况下配置实体。它还可用于实现紧密耦合的会议，使会议控制器能够在终端系统内实施会议范围的控制。
Conferencing systems such as IP telephones can also be viewed as components of a distributed system and can thus be integrated into a group of application modules: For example, an IP telephony call that is conducted with a stand-alone IP telephone can be dynamically extended to include media engines for other media types using the coordination function of an appropriate coordination mechanism. Different individual conferencing components can thus be combined to build a coherent multimedia conferencing system for a user.
IP电话等会议系统也可以视为分布式系统的组件，因此可以集成到一组应用模块中：例如，使用独立IP电话进行的IP电话呼叫可以使用适当协调机制的协调功能动态扩展，以包括用于其他媒体类型的媒体引擎。因此，可以组合不同的单独会议组件来为用户构建连贯的多媒体会议系统。
Other possible scenarios include the coordination of application components that are distributed on different hosts in a network, for example, so-called Internet appliances.
其他可能的场景包括协调分布在网络中不同主机上的应用程序组件，例如所谓的Internet设备。
Local coordination of application components requires a number of different interaction models: some messages (such as membership information, floor control notifications, dissemination of conference state changes, etc.) may need to be sent to all local application entities. Messages may also be targeted at a certain application class (e.g., all whiteboards or all audio tools) or agent type (e.g., all user interfaces rather than all media engines). Or there may be any (application- or message-specific) subgrouping defining the intended recipients, e.g., messages related to media synchronization. Finally, there may be messages that are directed at a single entity: for example, specific configuration settings that a conference controller sends to a particular application entity, or query-response exchanges between any local server and its clients.
应用程序组件的本地协调需要许多不同的交互模型：可能需要向所有本地应用程序实体发送一些消息（如成员信息、楼层控制通知、会议状态更改的传播等）。消息也可以针对特定的应用程序类（例如，所有白板或所有音频工具）或代理类型（例如，所有用户界面而不是所有媒体引擎）。或者可能存在任何（特定于应用程序或消息的）子组来定义预期的收件人，例如，与媒体同步相关的消息。最后，可能存在指向单个实体的消息：例如，会议控制器发送给特定应用程序实体的特定配置设置，或任何本地服务器及其客户端之间的查询响应交换。
The Mbus protocol as defined here satisfies these different communication needs by defining different message transport mechanisms (defined in Section 6) and by providing a flexible addressing scheme (defined in Section 4).
此处定义的Mbus协议通过定义不同的消息传输机制（定义见第6节）和提供灵活的寻址方案（定义见第4节）来满足这些不同的通信需求。
Furthermore, Mbus messages exchanged between application entities may have different reliability requirements (which are typically derived from their semantics). Some messages will have a rather transient character conveying ephemeral state information (which is refreshed/updated periodically), such as the volume meter level of an audio receiver entity to be displayed by its user interface agent. Certain Mbus messages (such as queries for parameters or queries to local servers) may require a response from the peer(s), thereby providing an explicit acknowledgment at the semantic level on top of the Mbus. Other messages will modify the application or conference state and hence it is crucial that they do not get lost. The latter type of message has to be delivered reliably to the recipient, whereas messages of the first type do not require reliability mechanisms at the Mbus transport layer. For messages confirmed at the application layer it is up to the discretion of the application whether or not to use a reliable transport underneath.
此外，应用程序实体之间交换的Mbus消息可能具有不同的可靠性要求（通常从其语义派生）。一些消息将具有相当短暂的字符，传达短暂的状态信息（定期刷新/更新），例如将由其用户界面代理显示的音频接收器实体的音量表级别。某些Mbus消息（例如参数查询或对本地服务器的查询）可能需要对等方的响应，从而在Mbus顶部的语义级别上提供明确的确认。其他消息将修改应用程序或会议状态，因此它们不会丢失至关重要。后一种类型的消息必须可靠地传递给接收者，而第一种类型的消息不需要在Mbus传输层使用可靠性机制。对于在应用层确认的消息，是否使用可靠的传输由应用程序自行决定。
In some cases, application entities will want to tailor the degree of reliability to their needs, others will want to rely on the underlying transport to ensure delivery of the messages -- and this may be different for each Mbus message. The Mbus message passing mechanism specified in this document provides a maximum of flexibility by providing reliable transmission achieved through transport-layer acknowledgments (in case of point-to-point communications only) as well as unreliable message passing (for unicast, local multicast, and local broadcast). We address this topic in Section 4.
在某些情况下，应用程序实体将希望根据其需求调整可靠性程度，而其他实体则希望依靠底层传输来确保消息的传递——对于每个Mbus消息，这可能是不同的。本文件中规定的Mbus消息传递机制通过提供通过传输层确认（仅在点对点通信的情况下）实现的可靠传输以及不可靠的消息传递（单播、本地多播和本地广播）提供了最大的灵活性。我们在第4节讨论这个主题。
Finally, accidental or malicious disturbance of Mbus communications through messages originated by applications from other users needs to be prevented. Accidental reception of Mbus messages from other users may occur if either two users share the same host for using Mbus applications or if they are using Mbus applications that are spread across the same network link: in either case, the used Mbus multicast address and the port number may be identical leading to reception of the other party's Mbus messages in addition to the user's own ones. Malicious disturbance may happen because of applications multicasting (e.g., at a global scope) or unicasting Mbus messages. To eliminate the possibility of processing unwanted Mbus messages, the Mbus protocol contains message digests for authentication. Furthermore, the Mbus allows for encryption to ensure privacy and thus enable using the Mbus for local key distribution and other functions potentially sensitive to eavesdropping. This document defines the framework for configuring Mbus applications with regard to security parameters in Section 12.
最后，需要防止通过来自其他用户的应用程序发出的消息对Mbus通信造成意外或恶意干扰。如果两个用户共享同一主机以使用Mbus应用程序，或者如果他们正在使用分布在同一网络链路上的Mbus应用程序，则可能会意外接收到来自其他用户的Mbus消息：，所使用的Mbus多播地址和端口号可能相同，从而导致除了用户自己的Mbus消息之外，还接收到另一方的Mbus消息。由于应用程序多播（例如，在全局范围内）或单播Mbus消息，可能会发生恶意干扰。为了消除处理不需要的Mbus消息的可能性，Mbus协议包含用于身份验证的消息摘要。此外，Mbus允许加密以确保隐私，从而允许使用Mbus进行本地密钥分发和其他可能对窃听敏感的功能。本文件定义了第12节中有关安全参数的Mbus应用程序配置框架。
Three components constitute the message bus: the low level message passing mechanisms, a command syntax and naming hierarchy, and the addressing scheme.
消息总线由三部分组成：底层消息传递机制、命令语法和命名层次结构以及寻址方案。
The purpose of this document is to define the protocol mechanisms of the lower level Mbus message passing mechanism which is common to all Mbus implementations. This includes the specification of
本文件的目的是定义低级Mbus消息传递机制的协议机制，该机制是所有Mbus实现所共有的。这包括
o the generic Mbus message format;
o 通用Mbus消息格式；
o the addressing concept for application entities (note that concrete addressing schemes are to be defined by application-specific profiles);
o 应用实体的寻址概念（注意，具体的寻址方案将由特定于应用程序的概要文件定义）；
o the transport mechanisms to be employed for conveying messages between (co-located) application entities;
o 用于在（位于同一位置的）应用实体之间传送消息的传输机制；
o the security concept to prevent misuse of the Message Bus (such as taking control of another user's conferencing environment);
o 防止误用消息总线（如控制另一用户的会议环境）的安全概念；
o the details of the Mbus message syntax; and
o Mbus消息语法的详细信息；和
o a set of mandatory application independent commands that are used for bootstrapping Mbus sessions.
o 一组强制性的独立于应用程序的命令，用于引导Mbus会话。
The Mbus protocol can be deployed in many different application areas, including but not limited to:
Mbus协议可以部署在许多不同的应用领域，包括但不限于：
Local conference control: In the Mbone community a model has arisen whereby a set of loosely coupled tools are used to participate in a conference. A typical scenario is that audio, video, and shared workspace functionality is provided by three separate tools (although some combined tools exist). This maps well onto the underlying RTP [8] (as well as other) media streams, which are also transmitted separately. Given such an architecture, it is useful to be able to perform some coordination of the separate media tools. For example, it may be desirable to communicate playout-point information between audio and video tools, in order to implement lip-synchronization, to arbitrate the use of shared resources (such as input devices), etc.
本地会议控制：在Mbone社区中，出现了一种模型，使用一组松散耦合的工具参与会议。一个典型的场景是音频、视频和共享工作区功能由三个单独的工具提供（尽管存在一些组合工具）。这很好地映射到底层RTP[8]（以及其他）媒体流，这些媒体流也单独传输。考虑到这样的体系结构，能够对单独的媒体工具进行一些协调是很有用的。例如，可能希望在音频和视频工具之间通信播放点信息，以便实现lip同步，以仲裁共享资源（例如输入设备）的使用等。
A refinement of this architecture relies on the presence of a number of media engines which perform protocol functions as well as capturing and playout of media. In addition, one (or more)
此体系结构的改进依赖于多个媒体引擎的存在，这些引擎执行协议功能以及媒体的捕获和播放。此外，一个（或多个）
(separate) user interface agents exist that interact with and control their media engine(s). Such an approach allows flexibility in the user-interface design and implementation, but obviously requires some means by which the various involved agents may communicate with one another. This is particularly desirable to enable a coherent response to a user's conference-related actions (such as joining or leaving a conference).
（单独）存在与媒体引擎交互并控制其媒体引擎的用户界面代理。这种方法允许用户界面设计和实现的灵活性，但显然需要各种相关代理相互通信的方法。这对于实现对用户的会议相关动作（例如加入或离开会议）的一致响应是特别可取的。
Although current practice in the Mbone community is to work with a loosely coupled conference control model, situations arise where this is not appropriate and a more tightly coupled wide-area conference control protocol must be employed. In such cases, it is highly desirable to be able to re-use the existing tools (media engines) available for loosely coupled conferences and integrate them with a system component implementing the tight conference control model. One appropriate means to achieve this integration is a communication channel that allows a dedicated conference control entity to "remotely" control the media engines in addition to or instead of their respective user interfaces.
尽管Mbone社区的当前实践是使用松散耦合的会议控制模型，但出现这种情况时并不合适，必须使用更紧密耦合的广域会议控制协议。在这种情况下，非常希望能够重用可用于松散耦合会议的现有工具（媒体引擎），并将其与实现紧密会议控制模型的系统组件集成。实现这种集成的一种适当方式是通信信道，该通信信道允许专用会议控制实体除了或代替各自的用户界面之外“远程”控制媒体引擎。
Control of device groups in a network: A group of devices that are connected to a local network, e.g., home appliances in a home network, require a local coordination mechanism. Minimizing manual configuration and the the possibility to deploy group communication will be useful in this application area as well.
网络中设备组的控制：连接到本地网络的一组设备，例如家庭网络中的家用电器，需要本地协调机制。将手动配置和部署组通信的可能性降至最低也将有助于此应用领域。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant Mbus implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”将按照RFC 2119[1]中的描述进行解释，并表示符合要求的小微企业单位实施的要求级别。
This section contains definitions of common ABNF [13] syntax elements that are later referenced by other definitions in this document:
本节包含通用ABNF[13]语法元素的定义，本文档中的其他定义稍后将引用这些元素：
base64 = base64_terminal / ( 1*(4base64_CHAR) [base64_terminal] )
base64=base64\u终端/（1*（4base64\u字符）[base64\u终端]）
base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/"
;; Case-sensitive
base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/"
;; Case-sensitive
base64_terminal = (2base64_char "==") / (3base64_char "=")
base64_terminal = (2base64_char "==") / (3base64_char "=")
UPALPHA = %x41-5A ;; Uppercase: A-Z
UPALPHA = %x41-5A ;; Uppercase: A-Z
LOALPHA = %x61-7A ;; Lowercase: a-z
LOALPHA = %x61-7A ;; Lowercase: a-z
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
CHAR = %x01-7E
; any 7-bit US-ASCII character,
excluding NUL and delete
CHAR = %x01-7E
; any 7-bit US-ASCII character,
excluding NUL and delete
OCTET = %x00-FF
; 8 bits of data
OCTET = %x00-FF
; 8 bits of data
CR = %x0D
; carriage return
CR = %x0D
; carriage return
CRLF = CR LF ; Internet standard newline
CRLF=CRLF；互联网标准新线
DIGIT = %x30-39
; 0-9
DIGIT = %x30-39
; 0-9
DQUOTE = %x22
; " (Double Quote)
DQUOTE = %x22
; " (Double Quote)
HTAB = %x09
; horizontal tab
HTAB = %x09
; horizontal tab
LF = %x0A
; linefeed
LF = %x0A
; linefeed
LWSP = *(WSP / CRLF WSP)
; linear white space (past newline)
LWSP = *(WSP / CRLF WSP)
; linear white space (past newline)
SP = %x20
; space
SP = %x20
; space
WSP = SP / HTAB ; white space
WSP=SP/HTAB；空白
Taken from RFC 2234 [13] and RFC 2554 [14].
取自RFC 2234[13]和RFC 2554[14]。
An Mbus message comprises a header and a body. The header is used to indicate how and where a message should be delivered and the body provides information and commands to the destination entity. The following pieces of information are included in the header:
Mbus消息包括头和正文。标头用于指示应如何以及在何处传递消息，正文向目标实体提供信息和命令。标题中包含以下信息：
A fixed ProtocolID field identifies the version of the message bus protocol used. The protocol defined in this document is "mbus/1.0" (case-sensitive).
固定的ProtocolID字段标识所用消息总线协议的版本。本文件中定义的协议为“mbus/1.0”（区分大小写）。
A sequence number (SeqNum) is contained in each message. The first message sent by a source SHOULD set SeqNum to zero, and it MUST increment by one for each message sent by that source. A single sequence number is used for all messages from a source, irrespective of the intended recipients and the reliability mode selected. The value range of a sequence number is (0,4294967295). An implementation MUST re-set its sequence number to 0 after reaching 4294967295. Implementations MUST take into account that the SeqNum of other entities may wrap-around.
每条消息中都包含一个序列号（SeqNum）。源发送的第一条消息应将SeqNum设置为零，并且该源发送的每条消息的SeqNum必须递增1。一个序列号用于来自一个源的所有消息，而不考虑预期的收件人和所选的可靠性模式。序列号的值范围为（04294967295）。在达到4294967295后，实现必须将其序列号重新设置为0。实现时必须考虑到其他实体的SeqNum可能会环绕。
SeqNums are decimal numbers in ASCII representation.
SeqNum是ASCII表示形式的十进制数。
The TimeStamp field is also contained in each message and SHOULD contain a decimal number representing the time of the message construction in milliseconds since 00:00:00, UTC, January 1, 1970.
时间戳字段也包含在每条消息中，并且应该包含一个十进制数字，表示自UTC 1970年1月1日00:00:00以来消息构造的时间（以毫秒为单位）。
A MessageType field indicates the kind of message being sent. The value "R" indicates that the message is to be transmitted reliably and MUST be acknowledged by the recipient, "U" indicates an unreliable message which MUST NOT be acknowledged.
MessageType字段指示正在发送的消息的类型。值“R”表示消息要可靠地传输并且必须由接收者确认，“U”表示不可靠的消息，该消息不得被确认。
The SrcAddr field identifies the sender of a message. This MUST be a complete address, with all address elements specified. The addressing scheme is described in Section 4.
srcadr字段标识消息的发件人。这必须是一个完整的地址，并指定了所有地址元素。第4节描述了寻址方案。
The DestAddr field identifies the intended recipient(s) of the message. This field MAY be wildcarded by omitting address elements and hence address any number (including zero) of application entities. The addressing scheme is described in Section 4.
DestAddr字段标识邮件的预期收件人。该字段可以通过省略地址元素进行通配符，从而寻址任意数量（包括零）的应用程序实体。第4节描述了寻址方案。
The AckList field comprises a list of SeqNums for which this message is an acknowledgment. See Section 7 for details.
确认列表字段包括一个SeqNum列表，该消息是对该列表的确认。详见第7节。
The header is followed by the message body which contains zero or more commands to be delivered to the destination entity. The syntax for a complete message is given in Section 5.
消息头后面是消息体，其中包含零个或多个要传递到目标实体的命令。第5节给出了完整消息的语法。
If multiple commands are contained within the same Mbus message payload, they MUST to be delivered to the Mbus application in the same sequence in which they appear in the message payload.
如果多个命令包含在同一个Mbus消息有效载荷中，则必须按照它们在消息有效载荷中出现的相同顺序将它们发送到Mbus应用程序。
Each entity in the message has a unique Mbus address that is used to identify the entity. Mbus addresses are sequences of address elements that are tag/value pairs. The tag and the value are separated by a colon and tag/value pairs are separated by whitespace, like this:
消息中的每个实体都有一个唯一的Mbus地址，用于标识该实体。Mbus地址是作为标记/值对的地址元素序列。标记和值用冒号分隔，标记/值对用空格分隔，如下所示：
(tag:value tag:value ...)
（标记：值标记：值…）
The formal ABNF syntax definition for Mbus addresses and their elements is as follows:
Mbus地址及其元素的正式ABNF语法定义如下：
mbus_address = "(" *WSP *1address_list *WSP ")"
address_list = address_element
/ address_element 1*WSP address_list
mbus_address = "(" *WSP *1address_list *WSP ")"
address_list = address_element
/ address_element 1*WSP address_list
address_element = address_tag ":" address_value
地址元素=地址标签“：“地址值”
address_tag = 1*32(ALPHA)
address_tag = 1*32(ALPHA)
address_value = 1*64(%x21-27 / %x2A-7E)
; any 7-bit US-ASCII character
; excluding white space, delete,
; control characters, "(" and ")"
address_value = 1*64(%x21-27 / %x2A-7E)
; any 7-bit US-ASCII character
; excluding white space, delete,
; control characters, "(" and ")"
Note that this and other ABNF definitions in this document use the non-terminal symbols defined in Section 2.
请注意，本文件中的本定义和其他ABNF定义使用了第2节中定义的非终端符号。
An address_tag MUST be unique within an Mbus address, i.e., it MUST only occur once.
地址标签在Mbus地址中必须是唯一的，即只能出现一次。
Each entity has a fixed sequence of address elements constituting its address and MUST only process messages sent to addresses that either match all elements or consist of a subset of its own address elements. The order of address elements in an address sequence is not relevant. Two address elements match if both their tags and their values are equivalent. Equivalence for address element and address value strings means that each octet in the one string has the same value as the corresponding octet in the second string. For example, an entity with an address of:
每个实体都有一个固定的地址元素序列构成其地址，并且必须只处理发送到匹配所有元素或由其自身地址元素子集组成的地址的消息。地址序列中地址元素的顺序不相关。如果两个地址元素的标记和值相等，则两个地址元素匹配。地址元素和地址值字符串的等价性意味着一个字符串中的每个八位字节与第二个字符串中对应的八位字节具有相同的值。例如，地址为的实体：
(conf:test media:audio module:engine app:rat id:4711-1@192.168.1.1)
(conf:test media:audio module:engine app:rat id:4711-1@192.168.1.1)
will process messages sent to
将处理发送到的消息
(media:audio module:engine)
（媒体：音频模块：发动机）
and
和
(module:engine)
（模块：发动机）
but must ignore messages sent to
但必须忽略发送到的消息
(conf:test media:audio module:engine app:rat id:123-4@192.168.1.1
foo:bar)
(conf:test media:audio module:engine app:rat id:123-4@192.168.1.1
foo:bar)
and
和
(foo:bar)
（foo:bar）
A message that should be processed by all entities requires an empty set of address elements.
应该由所有实体处理的消息需要一组空的地址元素。
Each Mbus entity MUST provide one mandatory address element that allows it to identify the entity. The element tag is "id" and the value MUST be be composed of the following components:
每个小微企业单位实体必须提供一个强制性地址元素，以便识别该实体。元素标记为“id”，值必须由以下组件组成：
o The IP address of the interface that is used for sending messages to the Mbus. For IPv4 this is the address in dotted decimal notation. For IPv6 the interface-ID-part of the node's link-local address in textual representation as specified in RFC 2373 [3] MUST be used.
o 用于向MBU发送消息的接口的IP地址。对于IPv4，这是以点十进制表示法表示的地址。对于IPv6，必须使用RFC 2373[3]中指定的文本表示形式的节点链路本地地址的接口ID部分。
In this specification, this part is called the "host-ID".
在本规范中，此部分称为“主机ID”。
o An identifier ("entity-ID") that is unique within the scope of a single host-ID. The entity comprises two parts. For systems where the concept of a process ID is applicable it is RECOMMENDED that this identifier be composed using a process-ID and a per-process disambiguator for different Mbus entities of a process. If a process ID is not available, this part of the entity-ID may be randomly chosen (it is recommended that at least a 32 bit random number is chosen). Both numbers are represented in decimal textual form and MUST be separated by a '-' (ASCII x2d) character.
o 在单个主机ID范围内唯一的标识符（“实体ID”）。该实体由两部分组成。对于流程ID概念适用的系统，建议使用流程ID和流程不同MBU实体的每个流程消歧器来组成该标识符。如果进程ID不可用，则可以随机选择实体ID的这一部分（建议至少选择32位随机数）。这两个数字都以十进制文本形式表示，并且必须用“-”（ASCII x2d）字符分隔。
Note that the entity-ID cannot be the port number of the endpoint used for sending messages to the Mbus because implementations MAY use the common Mbus port number for sending to and receiving from the multicast group (as specified in Section 6).
请注意，实体ID不能是用于向Mbus发送消息的端点的端口号，因为实现可能会使用公共Mbus端口号向多播组发送消息和从多播组接收消息（如第6节所述）。
The complete syntax definition for the entity identifier is as follows:
实体标识符的完整语法定义如下：
id-element = "id:" id-value
id element=“id:”id值
id-value = entity-id "@" host-id
id值=实体id“@”主机id
entity-id = 1*10DIGIT "-" 1*5DIGIT
entity-id = 1*10DIGIT "-" 1*5DIGIT
host-id = (IPv4address / IPv6address)
host-id = (IPv4address / IPv6address)
Please refer to [3] for the productions of IPv4address and IPv6address.
IPv4address和IPv6address的生成请参见[3]。
An example for an id element:
id元素的一个示例：
id:4711-99@192.168.1.1
身份证号码：4711-99@192.168.1.1
All messages MUST use the UTF-8 character encoding. Note that US ASCII is a subset of UTF-8 and requires no additional encoding, and that a message encoded with UTF-8 will not contain zero bytes.
所有消息必须使用UTF-8字符编码。请注意，US ASCII是UTF-8的一个子集，不需要额外编码，并且使用UTF-8编码的消息不会包含零字节。
Each Message MAY be encrypted using a secret key algorithm as defined in Section 11.
可以使用第11节中定义的密钥算法对每条消息进行加密。
The fields in the header are separated by white space characters, and followed by CRLF. The format of the header is as follows:
标题中的字段由空格字符分隔，后跟CRLF。标题的格式如下：
msg_header = "mbus/1.0" 1*WSP SeqNum 1*WSP TimeStamp 1*WSP
MessageType 1*WSP SrcAddr 1*WSP DestAddr 1*WSP AckList
msg_header = "mbus/1.0" 1*WSP SeqNum 1*WSP TimeStamp 1*WSP
MessageType 1*WSP SrcAddr 1*WSP DestAddr 1*WSP AckList
The header fields are explained in Message Format (Section 3). Here are the ABNF syntax definitions for the header fields:
标题字段以消息格式解释（第3节）。以下是标题字段的ABNF语法定义：
SeqNum = 1*10DIGIT ; numeric range 0 - 2^32-1
SeqNum = 1*10DIGIT ; numeric range 0 - 2^32-1
TimeStamp = 1*13DIGIT
TimeStamp = 1*13DIGIT
MessageType = "R" / "U"
MessageType = "R" / "U"
ScrAddr = mbus_address
ScrAddr = mbus_address
DestAddr = mbus_address
DestAddr = mbus_address
AckList = "(" *WSP *1(1*DIGIT *(1*WSP 1*10DIGIT)) *WSP ")"
AckList = "(" *WSP *1(1*DIGIT *(1*WSP 1*10DIGIT)) *WSP ")"
See Section 4 for a definition of "mbus_address".
有关“mbus_地址”的定义，请参见第4节。
The syntax definition of a complete message is as follows:
完整消息的语法定义如下：
mbus_message = msg_header *1(CRLF msg_payload)
mbus_message = msg_header *1(CRLF msg_payload)
msg_payload = mbus_command *(CRLF mbus_command)
msg_有效载荷=mbus_命令*（CRLF mbus_命令）
The definition of production rules for an Mbus command is given in Section 5.3.
第5.3节给出了Mbus命令生成规则的定义。
The header is followed by zero, one, or more, commands to be delivered to the Mbus entities indicated by the DestAddr field. Each command consists of a command name that is followed by a list of zero, or more parameters and is terminated by a newline.
标头后接零个、一个或多个命令，这些命令将传递给DestAddr字段指示的Mbus实体。每个命令都由一个命令名组成，该命令名后跟一个零个或多个参数的列表，并以换行符终止。
command ( parameter parameter ... )
命令（参数…）
Syntactically, the command name MUST be a `symbol' as defined in the following table. The parameters MAY be any data type drawn from the following table:
从语法上讲，命令名必须是下表中定义的“符号”。参数可以是从下表中提取的任何数据类型：
val = Integer / Float / String / List /
Symbol / Data
val = Integer / Float / String / List /
Symbol / Data
Integer = *1"-" 1*DIGIT
Integer = *1"-" 1*DIGIT
Float = *1"-" 1*DIGIT "." 1*DIGIT
Float = *1"-" 1*DIGIT "." 1*DIGIT
String = DQUOTE *CHAR DQUOTE ; see below for escape characters
字符串=DQUOTE*字符DQUOTE；有关转义字符，请参见下文
List = "(" *WSP *1(val *(1*WSP val)) *WSP ")"
List = "(" *WSP *1(val *(1*WSP val)) *WSP ")"
Symbol = ALPHA *(ALPHA / DIGIT / "_" / "-" /
".")
Symbol = ALPHA *(ALPHA / DIGIT / "_" / "-" /
".")
Data = "<" *base64 ">"
Data = "<" *base64 ">"
Boolean values are encoded as an integer, with the value of zero representing false, and non-zero representing true.
布尔值被编码为整数，零表示false，非零表示true。
String parameters in the payload MUST be enclosed in the double quote (") character. Within strings, the escape character is the backslash (\), and the following escape sequences are defined:
有效负载中的字符串参数必须包含在双引号（“）字符中。在字符串中，转义字符是反斜杠（\），并定义了以下转义序列：
+----------------+-----------+
|Escape Sequence | Meaning |
+----------------+-----------+
| \\ | \ |
| \" | " |
| \n | newline |
+----------------+-----------+
+----------------+-----------+
|Escape Sequence | Meaning |
+----------------+-----------+
| \\ | \ |
| \" | " |
| \n | newline |
+----------------+-----------+
List parameters do not have to be homogeneous lists, i.e., they can contain parameters of different types.
列表参数不必是同构列表，也就是说，它们可以包含不同类型的参数。
Opaque data is represented as Base64-encoded (see RFC 1521 [7]) character strings surrounded by "< " and "> "
不透明数据表示为Base64编码的字符串（参见RFC 1521[7]），由“<”和“>”包围
The ABNF syntax definition for Mbus commands is as follows:
Mbus命令的ABNF语法定义如下：
mbus_command = command_name arglist
mbus_command = command_name arglist
command_name = Symbol
command_name = Symbol
arglist = List
arglist = List
Command names SHOULD be constructed hierarchically to group conceptually related commands under a common hierarchy. The delimiter between names in the hierarchy MUST be "." (dot). Application profiles MUST NOT define commands starting with "mbus.".
命令名应按层次结构构造，以便将概念上相关的命令分组到公共层次结构下。层次结构中名称之间的分隔符必须为“.”（点）。应用程序配置文件不得定义以“mbus”开头的命令。
The Mbus addressing scheme defined in Section 4 allows specifying incomplete addresses by omitting certain elements of an address element list, enabling entities to send commands to a group of Mbus entities. Therefore, all command names SHOULD be unambiguous in a way that it is possible to interpret or ignore them without considering the message's address.
第4节中定义的Mbus寻址方案允许通过省略地址元素列表中的某些元素来指定不完整的地址，从而使实体能够向一组Mbus实体发送命令。因此，所有命令名都应该是明确的，这样就可以在不考虑消息地址的情况下解释或忽略它们。
A set of commands within a certain hierarchy that MUST be understood by every entity is defined in Section 9.
第9节定义了每个实体必须理解的特定层次结构中的一组命令。
All messages are transmitted as UDP messages, with two possible alternatives:
所有消息都作为UDP消息传输，有两种可能的替代方案：
1. Local multicast/broadcast: This transport class MUST be used for all messages that are not sent to a fully qualified target address. It MAY also be used for messages that are sent to a fully qualified target address. It MUST be provided by conforming implementations. See Section 6.1 for details.
1. 本地多播/广播：此传输类必须用于所有未发送到完全限定目标地址的消息。它还可用于发送到完全限定目标地址的消息。它必须由一致性实现提供。详见第6.1节。
2. Directed unicast: This transport class MAY be used for messages that are sent to a fully qualified destination address. It is OPTIONAL and does not have to be provided by conforming implementations.
2. 定向单播：此传输类可用于发送到完全限定的目标地址的消息。它是可选的，不必由一致性实现提供。
A fully qualified target address is an Mbus address of an existing Mbus entity in an Mbus session. An implementation can identify an Mbus address as fully qualified by maintaining a list of known entities within an Mbus session. Each known entity has its own unique, fully qualified Mbus address.
完全限定目标地址是Mbus会话中现有Mbus实体的Mbus地址。通过维护Mbus会话中已知实体的列表，实现可以将Mbus地址标识为完全限定。每个已知实体都有自己独特的、完全合格的Mbus地址。
Messages are transmitted in UDP datagrams, a maximum message size of 64 KBytes MUST NOT be exceeded. It is RECOMMENDED that applications using a non host-local scope do not exceed a message size of the link MTU.
消息以UDP数据报传输，不得超过最大消息大小64 KB。建议使用非主机本地作用域的应用程序不要超过链接MTU的消息大小。
Note that "unicast", "multicast" and "broadcast" mean IP Unicast, IP Multicast and IP Broadcast respectively. It is possible to send an Mbus message that is addressed to a single entity using IP Multicast.
请注意，“单播”、“多播”和“广播”分别表示IP单播、IP多播和IP广播。可以使用IP多播向单个实体发送一条Mbus消息。
This specification deals with both Mbus over UDP/IPv4 and Mbus over UDP/IPv6.
本规范涉及UDP/IPv4上的MBU和UDP/IPv6上的MBU。
In general, the Mbus uses multicast with a limited scope for message transport. Two different Mbus multicast scopes are defined, either of which can be configured to be used with an Mbus session:
通常，Mbus使用多播，但消息传输范围有限。定义了两个不同的Mbus多播作用域，其中任何一个都可以配置为与Mbus会话一起使用：
1. host-local
1. 本地主机
2. link-local
2. 链接本地
Participants of an Mbus session have to know the multicast address in advance -- it cannot be negotiated during the session since it is already needed for initial communication between the Mbus entities during the bootstrapping phase. It also cannot be allocated prior to an Mbus session because there would be no mechanism to announce the allocated address to all potential Mbus entities. Therefore, the multicast address has to be assigned statically. This document defines the use of statically assigned addresses and also provides a
Mbus会话的参与者必须提前知道多播地址——在会话期间无法协商多播地址，因为在引导阶段，Mbus实体之间的初始通信已经需要多播地址。它也不能在小微企业单位会议之前分配，因为没有向所有潜在小微企业单位实体宣布分配地址的机制。因此，必须静态地分配多播地址。本文档定义了静态分配地址的使用，并提供了
specification of how an Mbus session can be configured to use non-standard, unassigned addresses (see Section 12).
Mbus会话如何配置为使用非标准、未分配地址的规范（见第12节）。
The following sections specify the use of multicast addresses for IPv4 and IPv6.
以下各节指定IPv4和IPv6的多播地址的使用。
For IPv4, a statically assigned, scope-relative multicast address as defined by RFC 2365 [11] is used. The offset for the scope relative address for Mbus is 8 (MBUS, see http://www.iana.org/assignments/multicast-addresses [19]).
对于IPv4，使用RFC 2365[11]定义的静态分配的作用域相对多播地址。Mbus的作用域相对地址偏移量为8（Mbus，请参阅http://www.iana.org/assignments/multicast-addresses [19]).
Different scopes are defined by RFC 2365 [11]. The IPv4 Local Scope (239.255.0.0/16) is the minimal enclosing scope for administratively scoped multicast (as defined by RFC 2365 [11]) and not further divisible -- its exact extent is site dependent.
RFC 2365[11]定义了不同的范围。IPv4本地作用域（239.255.0.0/16）是管理作用域多播（由RFC 2365[11]定义）的最小封闭作用域，不可进一步划分——其确切范围取决于站点。
For the IPv4 Local Scope, applying the rules of RFC 2365 [11] and using the assigned offset of 8, the Mbus multicast address is therefore 239.255.255.247.
对于IPv4本地作用域，应用RFC 2365[11]的规则并使用分配的偏移量8，因此Mbus多播地址为239.255.255.247。
For IPv4, the different defined Mbus scopes (host-local and link-local) are to be realized as follows:
对于IPv4，不同定义的Mbus作用域（主机本地和链路本地）将实现如下：
host-local multicast: Unless configured otherwise, the assigned scope-relative Mbus address in the Local Scope (239.255.255.247 as of RFC 2365 [11]) MUST be used. Mbus UDP datagrams SHOULD be sent with a TTL of 0.
主机本地多播：除非另有配置，否则必须使用本地作用域（自RFC 2365[11]起为239.255.255.247）中分配的作用域相对Mbus地址。Mbus UDP数据报应以0的TTL发送。
link-local multicast: Unless configured otherwise, the assigned scope-relative Mbus address in the Local Scope (239.255.255.247 as of RFC 2365 [11]) MUST be used. Mbus UDP datagrams SHOULD be sent with a TTL of 1.
链路本地多播：除非另有配置，否则必须使用本地作用域（自RFC 2365[11]起为239.255.255.247）中分配的作用域相对Mbus地址。Mbus UDP数据报应以1的TTL发送。
IPv6 has different address ranges for different multicast scopes and distinguishes node local and link local scopes, that are implemented as a set of address prefixes for the different address ranges (RFC 2373 [3]). The link-local prefix is FF02, the node-local prefix is FF01. A permanently assigned multicast address will be used for Mbus multicast communication, i.e., an address that is independent of the scope value and that can be used for all scopes. Implementations for IPv6 MUST use the scope-independent address and the appropriate prefix for the selected scope. For host-local Mbus communication the IPv6 node-local scope prefix MUST be used, for link-local Mbus communication the IPv6 link-local scope prefix MUST be used.
IPv6对不同的多播作用域具有不同的地址范围，并区分节点本地作用域和链路本地作用域，它们作为不同地址范围的一组地址前缀实现（RFC 2373[3]）。链路本地前缀为FF02，节点本地前缀为FF01。永久分配的多播地址将用于Mbus多播通信，即独立于作用域值且可用于所有作用域的地址。IPv6的实现必须使用与作用域无关的地址和所选作用域的适当前缀。对于主机本地Mbus通信，必须使用IPv6节点本地作用域前缀；对于链路本地Mbus通信，必须使用IPv6链路本地作用域前缀。
The permanent IPv6 multicast address for Mbus/Ipv6 is FF0X:0:0:0:0:0:0:300.
Mbus/IPv6的永久IPv6多播地址为FF0X:0:0:0:0:0:0:300。
FF0X:0:0:0:0:0:0:300 SHOULD be used for Mbus/IPv6 where the X in FF0X indicates that the scope is not fixed because this is an all scope address. This means, for node-local scope, FF01:0:0:0:0:0:0:300 SHOULD be used and for link-local scope FF02:0:0:0:0:0:0:300 SHOULD be used. See RFC 2375 [4] for IPv6 multicast address assignments.
FF0X:0:0:0:0:0:0:300应用于Mbus/IPv6，其中FF0X中的X表示作用域不固定，因为这是一个全作用域地址。这意味着，对于节点本地作用域，应使用FF01:0:0:0:0:300，对于链接本地作用域，应使用FF02:0:0:0:0:0:0:300。有关IPv6多播地址分配，请参阅RFC 2375[4]。
If a single application system is distributed across several co-located hosts, link local scope SHOULD be used for multicasting Mbus messages that potentially have recipients on the other hosts. The Mbus protocol is not intended (and hence deliberately not designed) for communication between hosts not on the same link. See Section 12 for specifications of Mbus configuration mechanisms.
如果单个应用程序系统分布在多个共址主机上，则链路本地作用域应用于多播可能在其他主机上有收件人的Mbus消息。Mbus协议不打算（因此故意不设计）用于不在同一链路上的主机之间的通信。有关Mbus配置机制的规范，请参见第12节。
In situations where multicast is not available, broadcast MAY be used instead. In these cases an IP broadcast address for the connected network SHOULD be used for sending. The node-local broadcast address for IPv6 is FF01:0:0:0:0:0:0:1, the link-local broadcast address for IPv6 is FF02:0:0:0:0:0:0:1. For IPv4, the generic broadcast address (for link-local broadcast) is 255.255.255.255. It is RECOMMENDED that IPv4-implementations use the generic broadcast address and a TTL of zero for host-local broadcast.
在多播不可用的情况下，可以使用广播代替。在这些情况下，应使用连接网络的IP广播地址进行发送。IPv6的节点本地广播地址为FF01:0:0:0:0:0:1，IPv6的链路本地广播地址为FF02:0:0:0:0:0:1。对于IPv4，通用广播地址（用于链路本地广播）为255.255.255.255。建议IPv4实现对主机本地广播使用通用广播地址和零TTL。
Broadcast MUST NOT be used in situations where multicast is available and supported by all systems participating in an Mbus session.
在多播可用且所有参与Mbus会话的系统都支持的情况下，不得使用广播。
See Section 12 for configuring the use of broadcast.
有关配置广播的使用，请参见第12节。
The registered Mbus UDP port number is 47000.
注册的Mbus UDP端口号为47000。
Directed unicast (via UDP) to the port of a specific application is an alternative transport class to multicast. Directed unicast is an OPTIONAL optimization and MAY be used by Mbus implementations for delivering messages addressed to a single application entity only -- the address of which the Mbus implementation has learned from other message exchanges before. Note that the DestAddr field of such messages MUST be filled in properly nevertheless. Every Mbus entity SHOULD use a single unique endpoint address for sending messages to the Mbus multicast group or to individual receiving entities. A
定向单播（通过UDP）到特定应用程序的端口是多播的替代传输类。定向单播是一种可选优化，可由Mbus实现用于仅向单个应用程序实体发送消息——Mbus实现以前从其他消息交换中了解到的地址。请注意，此类消息的DestAddr字段必须正确填写。每个Mbus实体应使用一个唯一的端点地址向Mbus多播组或单个接收实体发送消息。A.
unique endpoint address is a tuple consisting of the entity's IP address and a UDP source port number, where the port number is different from the standard Mbus port number.
唯一端点地址是一个元组，由实体的IP地址和UDP源端口号组成，其中端口号不同于标准的Mbus端口号。
Messages MUST only be sent via unicast if the Mbus target address is unique and if the sending entity can verify that the receiving entity uses a unique endpoint address. The latter can be verified by considering the last message received from that entity.
如果Mbus目标地址是唯一的，并且发送实体可以验证接收实体使用唯一的端点地址，则只能通过单播发送消息。后者可以通过考虑从该实体接收的最后一条消息来验证。
Note that several Mbus entities, say within the same process, may share a common transport address; in this case, the contents of the destination address field is used to further dispatch the message. Given the definition of "unique endpoint address" above, the use of a shared endpoint address and a dispatcher still allows other Mbus entities to send unicast messages to one of the entities that share the endpoint address. So this can be considered an implementation detail.
请注意，多个小微企业单位实体（如在同一流程内）可能共享一个公共运输地址；在这种情况下，目的地地址字段的内容用于进一步发送消息。鉴于上述“唯一端点地址”的定义，使用共享端点地址和调度器仍然允许其他Mbus实体向共享端点地址的实体之一发送单播消息。因此，这可以被视为一个实现细节。
Messages with an empty target address list MUST always be sent to all Mbus entities (via multicast if available).
具有空目标地址列表的消息必须始终发送到所有MBU实体（如果可用，则通过多播）。
The following algorithm can be used by sending entities to determine whether an Mbus address is unique considering the current set of Mbus entities:
发送实体可使用以下算法，根据当前的一组Mbus实体确定Mbus地址是否唯一：
let ta=the target address;
iterate through the set of all
currently known Mbus addresses {
let ti=the address in each iteration;
count the addresses for which
the predicate isSubsetOf(ta,ti) yields true;
}
let ta=the target address;
iterate through the set of all
currently known Mbus addresses {
let ti=the address in each iteration;
count the addresses for which
the predicate isSubsetOf(ta,ti) yields true;
}
If the count of matching addresses is exactly 1 the address is unique. The following algorithm can be used for the predicate isSubsetOf, that checks whether the second message matches the first according to the rules specified in Section 4. (A match means that a receiving entity that uses the second Mbus address must also process received messages with the first address as a target address.)
如果匹配地址的计数正好为1，则该地址是唯一的。以下算法可用于谓词isSubsetOf，该算法根据第4节中指定的规则检查第二条消息是否与第一条消息匹配。（匹配意味着使用第二个Mbus地址的接收实体也必须处理以第一个地址作为目标地址的接收消息。）
isSubsetOf(addr a1,a2) yields true, iff every address element of a1 is contained in a2's address element list.
如果a1的每个地址元素都包含在a2的地址元素列表中，isSubsetOf（addr a1，a2）将生成true。
An address element a1 is contained in an address element list if the list contains an element that is equal to a1. An address element is considered equal to another address element if it has the same values for both of the two address element fields (tag and value).
如果地址元素列表包含等于a1的元素，则地址元素a1包含在地址元素列表中。如果一个地址元素的两个地址元素字段（标记和值）的值相同，则认为该地址元素等于另一个地址元素。
While most messages are expected to be sent using unreliable transport, it may be necessary to deliver some messages reliably. Reliability can be selected on a per message basis by means of the MessageType field. Reliable delivery is supported for messages with a single recipient only; i.e., to a fully qualified Mbus address. An entity can thus only send reliable messages to known addresses, i.e., it can only send reliable messages to entities that have announced their existence on the Mbus (e.g., by means of mbus.hello() messages as defined in Section 9.1). A sending entity MUST NOT send a message reliably if the target address is not unique. (See Section 6 for the specification of an algorithm to determine whether an address is unique.) A receiving entity MUST only process and acknowledge a reliable message if the destination address exactly matches its own source address (the destination address MUST NOT be a subset of the source address).
虽然大多数消息预期使用不可靠的传输发送，但可能需要可靠地传递某些消息。可通过MessageType字段按每条消息选择可靠性。仅支持单个收件人的邮件的可靠传递；i、 e.发送至完全合格的Mbus地址。因此，实体只能向已知地址发送可靠消息，即，它只能向已在MBU上宣布其存在的实体发送可靠消息（例如，通过第9.1节中定义的Mbus.hello（）消息）。如果目标地址不唯一，则发送实体不能可靠地发送消息。（有关确定地址是否唯一的算法规范，请参见第6节。）接收实体必须仅在目标地址与其源地址完全匹配（目标地址不得是源地址的子集）的情况下处理和确认可靠消息。
Disallowing reliable message delivery for messages sent to multiple destinations is motivated by simplicity of the implementation as well as the protocol. The desired effect can be achieved at the application layer by sending individual reliable messages to each fully qualified destination address, if the membership information for the Mbus session is available.
不允许对发送到多个目的地的消息进行可靠的消息传递是由于实现和协议的简单性。如果Mbus会话的成员信息可用，则通过向每个完全合格的目的地地址发送单独的可靠消息，可以在应用层实现所需的效果。
Each message is tagged with a message sequence number. If the MessageType is "R", the sender expects an acknowledgment from the recipient within a short period of time. If the acknowledgment is not received within this interval, the sender MUST retransmit the message (with the same message sequence number), increase the timeout, and restart the timer. Messages MUST be retransmitted a small number of times (see below) before the transmission or the recipient are considered to have failed. If the message is not delivered successfully, the sending application is notified. In this case, it is up to the application to determine the specific actions (if any) to be taken.
每条消息都标有消息序列号。如果消息类型为“R”，则发送方希望在短时间内收到接收方的确认。如果在此间隔内未收到确认，则发送方必须重新传输消息（使用相同的消息序列号），增加超时时间，然后重新启动计时器。在传输或收件人被视为失败之前，消息必须重新传输一小段时间（见下文）。如果消息未成功传递，将通知发送应用程序。在这种情况下，由应用程序决定要采取的具体操作（如果有）。
Reliable messages MUST be acknowledged by adding their SeqNum to the AckList field of a message sent to the originator of the reliable message. This message MUST be sent to a fully qualified Mbus target address. Multiple acknowledgments MAY be sent in a single message. Implementations MAY either piggy-back the AckList onto another message sent to the same destination, or MAY send a dedicated acknowledgment message, with no commands in the message payload part.
必须通过将可靠消息的SeqNum添加到发送给可靠消息发起人的消息的AckList字段来确认可靠消息。此消息必须发送到完全合格的Mbus目标地址。可以在一条消息中发送多个确认。实现可以将确认列表背驮到发送到同一目的地的另一条消息上，也可以发送一条专用的确认消息，消息有效负载部分中没有任何命令。
The precise procedures are as follows:
具体程序如下：
Sender: A sender A of a reliable message M to receiver B MUST transmit the message either via IP-multicast or via IP-unicast, keep a copy of M, initialize a retransmission counter N to '1', and start a retransmission timer T (initialized to T_r). If an acknowledgment is received from B, timer T MUST be cancelled and the copy of M is discarded. If T expires, the message M MUST be retransmitted, the counter N MUST be incremented by one, and the timer MUST be restarted (set to N*T_r). If N exceeds the retransmission threshold N_r, the transmission is assumed to have failed, further retransmission attempts MUST NOT be undertaken, the copy of M MUST be discarded, and the sending application SHOULD be notified.
发送方：可靠消息M的发送方A必须通过IP多播或IP单播传输消息，保留M的副本，将重传计数器N初始化为“1”，并启动重传计时器T（初始化为T_r）。如果从B接收到确认，则必须取消计时器T并丢弃M的副本。如果T过期，则必须重新传输消息M，计数器N必须增加1，并且必须重新启动计时器（设置为N*T\r）。如果N超过重传阈值N_r，则假定传输失败，不得进行进一步的重传尝试，必须丢弃M的副本，并通知发送应用程序。
Receiver: A receiver B of a reliable message from a sender A MUST acknowledge reception of the message within a time period T_c < T_r. This MAY be done by means of a dedicated acknowledgment message or by piggy-backing the acknowledgment on another message addressed only to A.
接收方：来自发送方A的可靠消息的接收方B必须在T_c<T_r的时间段内确认收到该消息。这可以通过一条专用的确认消息或通过在另一条只发送给a的消息上支持确认来实现。
Receiver optimization: In a simple implementation, B may choose to immediately send a dedicated acknowledgment message. However, for efficiency, it could add the SeqNum of the received message to a sender-specific list of acknowledgments; if the added SeqNum is the first acknowledgment in the list, B SHOULD start an acknowledgment timer TA (initialized to T_c). When the timer expires, B SHOULD create a dedicated acknowledgment message and send it to A. If B is to transmit another Mbus message addressed only to A, it should piggy-back the acknowledgments onto this message and cancel TA. In either case, B should store a copy of the acknowledgment list as a single entry in the per-sender copy list, keep this entry for a period T_k, and empty the acknowledgment list. In case any of the messages kept in an entry of the copy list is received again from A, the entire acknowledgment list stored in this entry is scheduled for (re-) transmission following the above rules.
接收器优化：在一个简单的实现中，B可以选择立即发送一个专用的确认消息。然而，为了提高效率，它可以将收到的消息的SeqNum添加到特定于发送方的确认列表中；如果添加的SeqNum是列表中的第一个确认，B应该启动确认计时器TA（初始化为T_c）。当计时器过期时，B应创建一条专用确认消息并将其发送给a。如果B要发送另一条只发送给a的Mbus消息，则应将确认信息带回该消息并取消TA。在任何一种情况下，B都应该将确认列表的副本作为单个条目存储在每个发件人的副本列表中，将该条目保留一段时间，然后清空确认列表。如果复制列表条目中保存的任何消息再次从接收到，则存储在该条目中的整个确认列表将按照上述规则计划（重新）传输。
Constants and Algorithms: The following constants and algorithms SHOULD be used by implementations:
常量和算法：实现应使用以下常量和算法：
T_r=100ms
T_r=100ms
N_r=3
N_r=3
T_c=70ms
T_c=70ms
T_k=((N_r)*(N_r+1)/2)*T_r
T_k=((N_r)*(N_r+1)/2)*T_r
Before Mbus entities can communicate with one another, they need to mutually find out about their existence. After this bootstrap procedure that each Mbus entity goes through all other entities listening to the same Mbus know about the newcomer and the newcomer has learned about all the other entities. Furthermore, entities need to be able to to notice the failure (or leaving) of other entities.
在小微企业单位实体能够相互沟通之前，它们需要相互了解它们的存在。在该引导过程之后，每个MBU实体通过所有其他实体（听相同的MBU）了解新来者，新来者了解所有其他实体。此外，实体需要能够注意到其他实体的失败（或离开）。
Any Mbus entity MUST announce its presence (on the Mbus) after starting up. This is to be done repeatedly throughout its lifetime to address the issues of startup sequence: Entities should always become aware of other entities independent of the order of starting.
任何Mbus实体必须在启动后宣布其存在（在Mbus上）。在其整个生命周期中，要反复这样做，以解决启动顺序的问题：实体应始终了解其他实体，而不受启动顺序的影响。
Each Mbus entity MUST maintain the number of Mbus session members and continuously update this number according to any observed changes. The mechanisms of how the existence and the leaving of other entities can be detected are dedicated Mbus messages for entity awareness: mbus.hello (Section 9.1) and mbus.bye (Section 9.2). Each Mbus protocol implementation MUST periodically send mbus.hello messages that are used by other entities to monitor the existence of that entity. If an entity has not received mbus.hello messages for a certain time (see Section 8.2) from an entity, the respective entity is considered to have left the Mbus and MUST be excluded from the set of currently known entities. Upon the reception of a mbus.bye message the respective entity is considered to have left the Mbus as well and MUST be excluded from the set of currently known entities immediately.
每个小微企业单位必须保持小微企业单位会议成员的数量，并根据观察到的任何变化不断更新该数量。如何检测其他实体的存在和离开的机制是用于实体感知的专用Mbus消息：Mbus.hello（第9.1节）和Mbus.bye（第9.2节）。每个Mbus协议实施必须定期发送Mbus.hello消息，其他实体使用这些消息来监视该实体的存在。如果一个实体在一定时间内（见第8.2节）没有收到来自该实体的mbus.hello消息，则该实体被视为已离开该mbus，并且必须从当前已知的实体集合中排除。收到mbus.bye消息后，各实体也被视为已离开MBU，必须立即从当前已知实体集中排除。
Each Mbus entity MUST send hello messages to the Mbus after startup. After transmission of the hello message, it MUST start a timer after the expiration of which the next hello message is to be transmitted. Transmission of hello messages MUST NOT be stopped unless the entity detaches from the Mbus. The interval for sending hello messages is dependent on the current number of entities in an Mbus group and can thus change dynamically in order to avoid congestion due to many entities sending hello messages at a constant high rate.
启动后，每个Mbus实体必须向Mbus发送hello消息。在发送hello消息后，它必须在下一条hello消息发送到期后启动计时器。除非实体与MBU分离，否则不得停止hello消息的传输。发送hello消息的间隔取决于Mbus组中的当前实体数，因此可以动态更改，以避免由于许多实体以恒定的高速率发送hello消息而造成的拥塞。
Section 8.1 specifies the calculation of hello message intervals that MUST be used by protocol implementations. Using the values that are calculated for obtaining the current hello message timer, the timeout for received hello messages is calculated in Section 8.2. Section 9 specifies the command synopsis for the corresponding Mbus messages.
第8.1节规定了协议实现必须使用的hello消息间隔的计算。使用为获取当前hello消息计时器而计算的值，在第8.2节中计算接收hello消息的超时。第9节规定了相应Mbus消息的命令概要。
Since the number of entities in an Mbus session may vary, care must be taken to allow the Mbus protocol to automatically scale over a wide range of group sizes. The average rate at which hello messages are received would increase linearly to the number of entities in a session if the sending interval was set to a fixed value. Given an interval of 1 second this would mean that an entity taking part in an Mbus session with n entities would receive n hello messages per second. Assuming all entities resided on one host, this would lead to n*n messages that have to be processed per second -- which is obviously not a viable solution for larger groups. It is therefore necessary to deploy dynamically adapted hello message intervals, taking varying numbers of entities into account. In the following, we specify an algorithm that MUST be used by implementors to calculate the interval for hello messages considering the observed number of Mbus entities.
由于Mbus会话中的实体数量可能会有所不同，因此必须注意允许Mbus协议自动扩展到大范围的组大小。如果发送间隔设置为固定值，则接收hello消息的平均速率将线性增加到会话中的实体数。给定1秒的间隔，这意味着一个实体与n个实体参与Mbus会话，每秒将收到n条hello消息。假设所有实体都驻留在一台主机上，这将导致每秒必须处理n*n条消息——对于较大的组来说，这显然不是一个可行的解决方案。因此，有必要部署动态调整的hello消息间隔，同时考虑不同数量的实体。在下文中，我们指定了一个算法，实现者必须使用该算法来计算hello消息的间隔，并考虑观察到的Mbus实体数。
The algorithm features the following characteristics:
该算法具有以下特点：
o The number of hello messages that are received by a single entity in a certain time unit remains approximately constant as the number of entities changes.
o 随着实体数量的变化，单个实体在特定时间单位内接收的hello消息数量大致保持不变。
o The effective interval that is used by a specific Mbus entity is randomized in order to avoid unintentional synchronization of hello messages within an Mbus session. The first hello message of an entity is also delayed by a certain random amount of time.
o 特定Mbus实体使用的有效间隔是随机的，以避免Mbus会话中hello消息的无意同步。实体的第一条hello消息也会延迟一定的随机时间。
o A timer reconsideration mechanism is deployed in order to adapt the interval more appropriately in situations where a rapid change of the number of entities is observed. This is useful when an entity joins an Mbus session and is still learning of the existence of other entities or when a larger number of entities leaves the Mbus at once.
o 部署计时器重新考虑机制，以便在观察到实体数量快速变化的情况下更适当地调整间隔。当一个实体加入一个小微企业单位会议，并且仍在了解其他实体的存在，或者当更多实体同时离开小微企业单位时，这一点非常有用。
The following variable names are used in the calculation specified below (all time values in milliseconds):
以下变量名称用于以下指定的计算（所有时间值以毫秒为单位）：
hello_p: The last time a hello message has been sent by a Mbus entity.
hello_p：上次由Mbus实体发送hello消息的时间。
hello_now: The current time
喂，现在是现在时间
hello_d: The deterministic calculated interval between hello messages.
hello\u d：hello消息之间的确定计算间隔。
hello_e: The effective (randomized) interval between hello messages.
hello_e：hello消息之间的有效（随机）间隔。
hello_n: The time for the next scheduled transmission of a hello message.
hello\n：hello消息的下一次预定传输时间。
entities_p: The numbers of entities at the time hello_n has been last recomputed.
entities\u p：上次重新计算hello\n时的实体数。
entities: The number of currently known entities.
实体：当前已知实体的数量。
The interval between hello messages MUST be calculated as follows:
hello消息之间的间隔必须按以下方式计算：
The number of currently known entities is multiplied by c_hello_factor, yielding the interval between hello messages in milliseconds. This is the deterministic calculated interval, denoted hello_d. The minimum value for hello_d is c_hello_min which yields
当前已知实体的数量乘以c_hello_因子，得到hello消息之间的间隔（以毫秒为单位）。这是确定的计算间隔，表示为hello\u d。hello_d的最小值是c_hello_min，它产生
hello_d = max(c_hello_min,c_hello_factor * entities * 1ms).
hello_d=最大值（c_hello_最小值，c_hello_系数*实体*1ms）。
Section 8 provides a specification of how to obtain the number of currently known entities. Section 10 provides values for the constants c_hello_factor and c_hello_min.
第8节提供了如何获取当前已知实体数量的规范。第10节提供了常数c_hello_factor和c_hello_min的值。
The effective interval hello_e that is to be used by individual entities is calculated by multiplying hello_d with a randomly chosen number between c_hello_dither_min and c_hello_dither_max as follows:
将由单个实体使用的有效间隔hello_e通过将hello_d乘以随机选择的c_hello_dither_min和c_hello_dither_max之间的数字来计算，如下所示：
hello_e = c_hello_dither_min +
RND * (c_hello_dither_max - c_hello_dither_min)
hello_e = c_hello_dither_min +
RND * (c_hello_dither_max - c_hello_dither_min)
with RND being a random function that yields an even distribution between 0 and 1. See also Section 10.
RND是一个随机函数，它产生0到1之间的均匀分布。另见第10节。
hello_n, the time for the next hello message in milliseconds is set to hello_e + hello_now.
hello\u n，下一条hello消息的时间（以毫秒为单位）设置为hello\u e+hello\u now。
Upon joining an Mbus session a protocol implementation sets hello_p=0, hello_now=0 and entities=1, entities_p=1 (the Mbus entity itself) and then calculates the time for the next hello message as specified in Section 8.1.1. The next hello message is scheduled for transmission at hello_n.
在加入Mbus会话时，协议实现会设置hello_p=0、hello_now=0和entities=1、entities_p=1（Mbus实体本身），然后根据第8.1.1节的规定计算下一条hello消息的时间。下一条hello消息计划在hello\n传输。
8.1.3 Adjusting the Hello Message Interval when the Number of Entities increases
8.1.3 当实体数增加时调整Hello消息间隔
When the existence of a new entity is observed by a protocol implementation the number of currently known entities is updated. No further action concerning the calculation of the hello message interval is required. The reconsideration of the timer interval takes place when the current timer for the next hello message expires (see Section 8.1.5).
当协议实现观察到新实体的存在时，更新当前已知实体的数量。无需对hello消息间隔的计算采取进一步措施。当下一条hello消息的当前计时器过期时，重新考虑计时器间隔（见第8.1.5节）。
8.1.4 Adjusting the Hello Message Interval when the Number of Entities decreases
8.1.4 当实体数减少时调整Hello消息间隔
Upon realizing that an entity has left the Mbus the number of currently known entities is updated and the following algorithm should be used to reconsider the timer interval for hello messages:
在意识到某个实体已离开MBU后，当前已知实体的数量将被更新，应使用以下算法重新考虑hello消息的计时器间隔：
1. The value for hello_n is updated by setting hello_n = hello_now + (entities/entities_p)*(hello_n - hello_now)
1. hello\u n的值通过设置hello\u n=hello\u now+（实体/实体\u p）*（hello\u n-hello\u now）进行更新
2. The value for hello_p is updated by setting hello_p = hello_now - (entities/entities_p)*(hello_now - hello_p)
2. hello\u p的值通过设置hello\u p=hello\u now-（entities/entities\u p）*（hello\u now-hello\u p）进行更新
3. The currently active timer for the next hello messages is cancelled and a new timer is started for hello_n.
3. 下一条hello消息的当前活动计时器将被取消，并为hello\n启动一个新计时器。
4. entities_p is set to entities.
4. 实体\u p设置为实体。
When the hello message timer expires, the protocol implementation MUST perform the following operations:
当hello消息计时器过期时，协议实现必须执行以下操作：
The hello interval hello_e is computed as specified in Section 8.1.1.
按照第8.1.1节的规定计算hello间隔hello_e。
1. IF hello_e + hello_p <= hello_now THEN a hello message is transmitted. hello_p is set to hello_now, hello_e is calculated again as specified in Section 8.1.1 and hello_n is set to hello_e + hello_now.
1. 如果hello_e+hello_p<=hello_now，则发送hello消息。hello_p设置为hello_now，hello_e按照第8.1.1节的规定再次计算，hello_n设置为hello_e+hello_now。
2. ELSE IF hello_e + hello_p > hello_now THEN hello_n is set to hello_e + hello_p. A new timer for the next hello message is started to expire at hello_n. No hello message is transmitted.
2. 否则，如果hello_e+hello_p>hello_now，则hello_n设置为hello_e+hello_p。下一条hello消息的新计时器在hello\n时开始过期。没有发送hello消息。
entities_p is set to entities.
实体\u p设置为实体。
Whenever an Mbus entity has not heard for a time span of c_hello_dead*(hello_d*c_hello_dither_max) milliseconds from another Mbus entity it may consider this entity to have failed (or have quit silently). The number of the currently known entities MUST be updated accordingly. See Section 8.1.4 for details. Note that no need for any further action is necessarily implied from this observation.
每当MBUS实体没有听到来自另一个MBUS实体的CyHeloLogyDead *（HeloLoxd**CyHeloLooDythRax MAX）毫秒的时间跨度时，它可能认为该实体已失败（或已悄然退出）。必须相应地更新当前已知实体的数量。详见第8.1.4节。请注意，此观察结果不一定意味着需要采取任何进一步的行动。
Section 8.1.1 specifies how to obtain hello_d. Section 10 defines values for the constants c_hello_dead and c_hello_dither_max.
第8.1.1节规定了如何获得hello_d。第10节定义了常数c_hello_dead和c_hello_dither_max的值。
This section defines some basic application-independent messages that MUST be understood by all implementations; these messages are required for proper operation of the Mbus. This specification does not contain application-specific messages. These are to be defined outside of the basic Mbus protocol specification in separate Mbus profiles.
本节定义了一些基本的独立于应用程序的消息，所有实现都必须理解这些消息；这些信息是MBU正常运行所必需的。此规范不包含特定于应用程序的消息。这些将在基本Mbus协议规范之外的单独Mbus概要文件中定义。
Syntax: mbus.hello()
语法：mbus.hello（）
Parameters: - none -
Parameters: - none -
mbus.hello messages MUST be sent unreliably to all Mbus entities.
mbus.hello消息必须不可靠地发送到所有mbus实体。
Each Mbus entity learns about other Mbus entities by observing their mbus.hello messages and tracking the sender address of each message and can thus calculate the current number of entities.
每个Mbus实体通过观察其Mbus.hello消息并跟踪每条消息的发件人地址来了解其他Mbus实体，因此可以计算当前实体的数量。
mbus.hello messages MUST be sent periodically in dynamically calculated intervals as specified in Section 8.
mbus.hello消息必须按照第8节规定的动态计算间隔定期发送。
Upon startup the first mbus.hello message MUST be sent after a delay hello_delay, where hello_delay be a randomly chosen number between 0 and c_hello_min (see Section 10).
启动时，必须在延迟hello_延迟后发送第一条mbus.hello消息，其中hello_延迟为0和c_hello_min之间的随机数字（见第10节）。
Syntax: mbus.bye()
语法：mbus.bye（）
Parameters: - none -
Parameters: - none -
An Mbus entity that is about to terminate (or "detach" from the Mbus) SHOULD announce this by transmitting an mbus.bye message. The mbus.bye message MUST be sent unreliably to all entities.
即将终止（或从Mbus“分离”）的Mbus实体应通过发送Mbus.bye消息来宣布这一点。mbus.bye消息必须不可靠地发送给所有实体。
Syntax: mbus.ping()
语法：mbus.ping（）
Parameters: - none -
Parameters: - none -
mbus.ping can be used to solicit other entities to signal their existence by replying with an mbus.hello message. Each protocol implementation MUST understand mbus.ping and reply with an mbus.hello message. The reply hello message MUST be delayed for hello_delay milliseconds, where hello_delay be a randomly chosen number between 0 and c_hello_min (see Section 10). Several mbus.ping messages MAY be answered by a single mbus.hello: if one or more further mbus.ping messages are received while the entity is waiting hello_delay time units before transmitting the mbus.hello message, no extra mbus.hello message need be scheduled for those additional mbus.ping messages.
mbus.ping可用于请求其他实体通过回复mbus.hello消息来表示其存在。每个协议实现必须理解mbus.ping并用mbus.hello消息进行回复。回复hello消息必须延迟hello_延迟毫秒，其中hello_延迟是0到c_hello_min之间随机选择的数字（参见第10节）。多个mbus.ping消息可能由一个mbus.hello响应：如果实体在传输mbus.hello消息之前等待hello_延迟时间单位时接收到一个或多个进一步的mbus.ping消息，则无需为这些额外的mbus.ping消息安排额外的mbus.hello消息。
As specified in Section 9.1 hello messages MUST be sent unreliably to all Mbus entities. This is also the case for replies to ping messages. An entity that replies to mbus.ping with mbus.hello SHOULD stop any outstanding timers for hello messages after sending the hello message and schedule a new timer event for the subsequent hello message. (Note that using the variables and the algorithms of Section 8.1.1 this can be achieved by setting hello_p to hello_now.)
按照第9.1节的规定，hello消息必须不可靠地发送给所有MBU实体。对ping消息的回复也是如此。使用mbus.hello回复mbus.ping的实体应在发送hello消息后停止hello消息的任何未完成计时器，并为后续hello消息安排新的计时器事件。（请注意，使用第8.1.1节中的变量和算法，可以通过将hello\u p设置为hello\u now来实现。）
mbus.ping allows a new entity to quickly check for other entities without having to wait for the regular individual hello messages. By specifying a target address the new entity can restrict the solicitation for hello messages to a subset of entities it is interested in.
mbus.ping允许新实体快速检查其他实体，而无需等待常规的单独hello消息。通过指定目标地址，新实体可以将hello消息的请求限制为其感兴趣的实体子集。
Syntax: mbus.quit()
语法：mbus.quit（）
Parameters: - none -
Parameters: - none -
The mbus.quit message is used to request other entities to terminate themselves (and detach from the Mbus). Whether this request is honoured by receiving entities or not is application specific and not defined in this document.
mbus.quit消息用于请求其他实体终止自身（并从mbus分离）。接收实体是否满足此请求是特定于应用程序的，本文件中未定义。
The mbus.quit message can be multicast or sent reliably via unicast to a single Mbus entity or a group of entities.
mbus.quit消息可以多播或通过单播可靠地发送到单个mbus实体或一组实体。
Syntax: mbus.waiting(condition)
语法：mbus.waiting（条件）
Parameters:
参数：
symbol condition The condition parameter is used to indicate that the entity transmitting this message is waiting for a particular event to occur.
符号条件条件参数用于指示发送此消息的实体正在等待特定事件发生。
An Mbus entity SHOULD be able to indicate that it is waiting for a certain event to happen (similar to a P() operation on a semaphore but without creating external state somewhere else). In conjunction with this, an Mbus entity SHOULD be capable of indicating to another entity that this condition is now satisfied (similar to a semaphore's V() operation).
Mbus实体应该能够指示它正在等待某个事件发生（类似于信号量上的P（）操作，但不在其他地方创建外部状态）。与此相结合，一个Mbus实体应该能够向另一个实体指示该条件现在已经满足（类似于信号量的V（）操作）。
The mbus.waiting message MAY be broadcast to all Mbus entities, MAY be multicast to an arbitrary subgroup, or MAY be unicast to a particular peer. Transmission of the mbus.waiting message MUST be unreliable and hence MUST be repeated at an application-defined interval (until the condition is satisfied).
mbus.waiting消息可以广播到所有mbus实体，可以多播到任意子组，或者可以单播到特定对等方。mbus.waiting消息的传输必须不可靠，因此必须以应用程序定义的间隔重复传输（直到满足条件）。
If an application wants to indicate that it is waiting for several conditions to be met, several mbus.waiting messages are sent (possibly included in the same Mbus payload). Note that mbus.hello and mbus.waiting messages may also be transmitted in a single Mbus payload.
如果应用程序希望指示它正在等待满足几个条件，则会发送几个mbus.waiting消息（可能包含在同一个mbus有效负载中）。注意，mbus.hello和mbus.waiting消息也可以在单个mbus有效载荷中传输。
Syntax: mbus.go(condition)
语法：mbus.go（条件）
Parameters:
参数：
symbol condition This parameter specifies which condition is met.
符号条件此参数指定满足哪个条件。
The mbus.go message is sent by an Mbus entity to "unblock" another Mbus entity -- which has indicated that it is waiting for a certain condition to be met. Only a single condition can be specified per mbus.go message. If several conditions are satisfied simultaneously multiple mbus.go messages MAY be combined in a single Mbus payload.
mbus.go消息由一个mbus实体发送给另一个mbus实体“解除阻止”——这表明它正在等待满足某个条件。每个mbus.go消息只能指定一个条件。如果同时满足多个条件，则多个mbus.go消息可组合在单个mbus有效载荷中。
The mbus.go message MUST be sent reliably via unicast to the Mbus entity to unblock.
mbus.go消息必须通过单播可靠地发送到mbus实体以解除阻止。
The following values for timers and counters mentioned in this document SHOULD be used by implementations:
本文档中提到的计时器和计数器的以下值应由实现使用：
+-------------------+------------------------+--------------+
|Timer / Counter | Value | Unit |
+-------------------+------------------------+--------------+
|c_hello_factor | 200 | - |
|c_hello_min | 1000 | milliseconds |
|c_hello_dither_min | 0.9 | - |
|c_hello_dither_max | 1.1 | - |
|c_hello_dead | 5 | - |
+-------------------+------------------------+--------------+
+-------------------+------------------------+--------------+
|Timer / Counter | Value | Unit |
+-------------------+------------------------+--------------+
|c_hello_factor | 200 | - |
|c_hello_min | 1000 | milliseconds |
|c_hello_dither_min | 0.9 | - |
|c_hello_dither_max | 1.1 | - |
|c_hello_dead | 5 | - |
+-------------------+------------------------+--------------+
T_r=100ms
T_r=100ms
N_r=3
N_r=3
T_c=70ms
T_c=70ms
T_k=((N_r)*(N_r+1)/2)*T_r
T_k=((N_r)*(N_r+1)/2)*T_r
In order to prevent accidental or malicious disturbance of Mbus communications through messages originated by applications from other users, message authentication is deployed (Section 11.3). For each message, a digest MUST be calculated based on the value of a shared secret key value. Receivers of messages MUST check if the sender belongs to the same Mbus security domain by re-calculating the digest and comparing it to the received value. The messages MUST only be processed further if both values are equal. In order to allow different simultaneous Mbus sessions at a given scope and to compensate defective implementations of host local multicast, message authentication MUST be provided by conforming implementations.
为了防止通过应用程序从其他用户发出的消息对Mbus通信造成意外或恶意干扰，部署了消息认证（第11.3节）。对于每条消息，必须根据共享密钥值的值计算摘要。消息接收者必须通过重新计算摘要并将其与接收到的值进行比较来检查发送者是否属于同一个Mbus安全域。只有当两个值相等时，才必须进一步处理消息。为了在给定范围内允许不同的同步Mbus会话，并补偿主机本地多播的缺陷实现，必须通过一致性实现提供消息认证。
Privacy of Mbus message transport can be achieved by optionally using symmetric encryption methods (Section 11.2). Each message MAY be encrypted using an additional shared secret key and a symmetric encryption algorithm. Encryption is OPTIONAL for applications, i.e., it is allowed to configure an Mbus domain not to use encryption. But conforming implementations MUST provide the possibility to use message encryption (see below).
Mbus消息传输的保密性可通过选择性使用对称加密方法实现（第11.2节）。可以使用附加的共享密钥和对称加密算法对每条消息进行加密。加密对于应用程序是可选的，即允许将Mbus域配置为不使用加密。但一致性实现必须提供使用消息加密的可能性（见下文）。
Message authentication and encryption can be parameterized: the algorithms to apply, the keys to use, etc. These and other parameters are defined in an Mbus configuration object that is accessible by all Mbus entities that participate in an Mbus session. In order to achieve interoperability conforming implementations SHOULD use the values provided by such an Mbus configuration. Section 12 defines the mandatory and optional parameters as well as storage procedures for different platforms. Only in cases where none of the options mentioned in Section 12 is applicable alternative methods of configuring Mbus protocol entities MAY be deployed.
消息身份验证和加密可以参数化：要应用的算法、要使用的密钥等。这些参数和其他参数在Mbus配置对象中定义，所有参与Mbus会话的Mbus实体都可以访问该对象。为了实现互操作性，一致性实施应使用此类Mbus配置提供的值。第12节定义了不同平台的强制性和可选参数以及存储程序。只有在第12节中提到的选项均不适用的情况下，才可以部署配置Mbus协议实体的替代方法。
The algorithms and procedures for applying encryption and authentication techniques are specified in the following sections.
应用加密和身份验证技术的算法和过程在以下章节中详细说明。
Encryption of messages is OPTIONAL, that means, an Mbus MAY be configured not to use encryption.
消息加密是可选的，这意味着可以将MBU配置为不使用加密。
Implementations can choose between different encryption algorithms. Every conforming implementation MUST provide the AES [18] algorithm. In addition, the following algorithms SHOULD be supported: DES [16], 3DES (triple DES) [16] and IDEA [20].
实现可以在不同的加密算法之间进行选择。每个一致性实现必须提供AES[18]算法。此外，应支持以下算法：DES[16]、3DES（三重DES）[16]和IDEA[20]。
For algorithms requiring en/decryption data to be padded to certain boundaries octets with a value of 0 SHOULD be used for padding characters.
对于要求en/解密数据填充到特定边界的算法，应使用值为0的八位字节填充字符。
The length of the encryption keys is determined by the currently used encryption algorithm. This means, the configured encryption key MUST NOT be shorter than the native key length for the currently configured algorithm.
加密密钥的长度由当前使用的加密算法确定。这意味着，配置的加密密钥不得短于当前配置算法的本机密钥长度。
DES implementations MUST use the DES Cipher Block Chaining (CBC) mode. DES keys (56 bits) MUST be encoded as 8 octets as described in RFC 1423 [12], resulting in 12 Base64-encoded characters. IDEA uses 128-bit keys (24 Base64-encoded characters). AES can use either 128-bit, 192-bit or 256-bit keys. For Mbus encryption using AES only 128-bit keys (24 Base64-encoded characters) MUST be used.
DES实现必须使用DES密码块链接（CBC）模式。DES密钥（56位）必须按照RFC 1423[12]中的描述编码为8个八位字节，从而产生12个Base64编码字符。IDEA使用128位密钥（24个Base64编码字符）。AES可以使用128位、192位或256位密钥。对于使用AES的Mbus加密，只能使用128位密钥（24个Base64编码字符）。
For authentication of messages, hashed message authentication codes (HMACs) as described in RFC 2104 [5] are deployed. In general, implementations can choose between a number of digest algorithms. For Mbus authentication, the HMAC algorithm MUST be applied in the following way:
对于消息的身份验证，部署了RFC 2104[5]中描述的哈希消息身份验证码（HMAC）。通常，实现可以在许多摘要算法之间进行选择。对于Mbus身份验证，必须以以下方式应用HMAC算法：
The keyed hash value is calculated using the HMAC algorithm specified in RFC 2104 [5]. The specific hash algorithm and the secret hash key MUST be obtained from the Mbus configuration (see Section 12).
使用RFC 2104[5]中指定的HMAC算法计算键控哈希值。必须从Mbus配置中获取特定哈希算法和秘密哈希密钥（见第12节）。
The keyed hash values (see RFC 2104 [5]) MUST be truncated to 96 bits (12 octets).
键控哈希值（见RFC 2104[5]）必须截断为96位（12个八位字节）。
Subsequently, the resulting 12 octets MUST be Base64-encoded, resulting in 16 Base64-encoded characters (see RFC 1521 [7]).
随后，产生的12个八位字节必须进行Base64编码，产生16个Base64编码字符（参见RFC 1521[7]）。
Either MD5 [15] or SHA-1 [17] SHOULD be used for message authentication codes (MACs). An implementation MAY provide MD5, whereas SHA-1 MUST be implemented.
消息身份验证代码（MAC）应使用MD5[15]或SHA-1[17]。实现可以提供MD5，而必须实现SHA-1。
The length of the hash keys is determined by the selected hashing algorithm. This means, the configured hash key MUST NOT be shorter than the native key length for the currently configured algorithm.
哈希键的长度由选定的哈希算法确定。这意味着，对于当前配置的算法，配置的散列密钥不得短于本机密钥长度。
The algorithms that MUST be provided by implementations are AES and SHA-1.
实现必须提供的算法是AES和SHA-1。
See Section 12 for a specification of notations for Base64-strings.
有关Base64字符串的符号规范，请参见第12节。
A sender MUST apply the following operations to a message that is to be sent:
发件人必须对要发送的邮件应用以下操作：
1. If encryption is enabled, the message MUST be encrypted using the configured algorithm and the configured encryption key. Padding (adding extra-characters) for block-ciphers MUST be applied as specified in Section 11.2. If encryption is not enabled, the message is left unchanged.
1. 如果启用了加密，则必须使用配置的算法和配置的加密密钥对消息进行加密。分组密码的填充（添加额外字符）必须按照第11.2节的规定应用。如果未启用加密，则消息保持不变。
2. Subsequently, a message authentication code (MAC) for the (encrypted) message MUST be calculated using the configured HMAC-algorithm and the configured hash key.
2. 随后，必须使用配置的HMAC算法和配置的哈希密钥计算（加密）消息的消息认证码（MAC）。
3. The MAC MUST then be converted to Base64 encoding, resulting in 16 Base64-characters as specified in Section 11.3.
3. 然后必须将MAC转换为Base64编码，从而产生第11.3节中规定的16个Base64字符。
4. At last, the sender MUST construct the final message by placing the (encrypted) message after the base64-encoded MAC and a CRLF. The ABNF definition for the final message is as follows:
4. 最后，发送方必须通过将（加密的）消息放在base64编码的MAC和CRLF之后来构造最终消息。最终消息的ABNF定义如下：
final_msg = MsgDigest CRLF encr_msg
final_msg = MsgDigest CRLF encr_msg
MsgDigest = base64
MsgDigest = base64
encr_msg = *OCTET
encr_msg = *OCTET
A receiver MUST apply the following operations to a message that it has received:
接收方必须对其收到的消息应用以下操作：
1. Separate the base64-encoded MAC from the (encrypted) message and decode the MAC.
1. 将base64编码的MAC与（加密的）消息分开，并对MAC进行解码。
2. Re-calculate the MAC for the message using the configured HMAC-algorithm and the configured hash key.
2. 使用配置的HMAC算法和配置的哈希键重新计算消息的MAC。
3. Compare the original MAC with re-calculated MAC. If they differ, the message MUST be discarded without further processing.
3. 将原始MAC与重新计算的MAC进行比较。如果它们不同，则必须丢弃消息，而无需进一步处理。
4. If encryption is enabled, the message MUST be decrypted using the configured algorithm and the configured encryption key. Trailing octets with a value of 0 MUST be deleted. If the message does not
4. 如果启用了加密，则必须使用配置的算法和配置的加密密钥对消息进行解密。必须删除值为0的尾随八位字节。如果消息没有
start with the string "mbus/" the message MUST be discarded without further processing.
以字符串“mbus/”开头，必须丢弃消息，无需进一步处理。
An implementation MUST be configurable by the following parameters:
实现必须通过以下参数进行配置：
Configuration version
配置版本
The version number of the given configuration entity. Version numbers allow implementations to check if they can process the entries of a given configuration entity. Version number are integer values. The version number for the version specified here is 1.
给定配置实体的版本号。版本号允许实现检查是否可以处理给定配置实体的条目。版本号是整数值。此处指定版本的版本号为1。
Encryption key
加密密钥
The secret key used for message encryption.
用于消息加密的密钥。
Hash key
散列键
The hash key used for message authentication.
用于消息身份验证的哈希密钥。
Scope
范围
The multicast scope to be used for sent messages.
要用于已发送消息的多播作用域。
The above parameters are mandatory and MUST be present in every Mbus configuration entity.
上述参数是强制性的，必须存在于每个Mbus配置实体中。
The following parameters are optional. When they are present they MUST be honored. When they are not present implementations SHOULD fall back to the predefined default values (as defined in Transport (Section 6)):
以下参数是可选的。当他们在场时，他们必须受到尊敬。当它们不存在时，实现应回到预定义的默认值（如传输（第6节）中所定义）：
Address
住址
The non-standard multicast address to use for message transport.
用于消息传输的非标准多播地址。
Use of Broadcast
广播的使用
It can be specified whether broadcast should be used. If broadcast has been configured implementations SHOULD use the network broadcast address (as specified in Section 6.1.3) instead of the standard multicast address.
可以指定是否应使用广播。如果已配置广播，则实施应使用网络广播地址（如第6.1.3节所述）而不是标准多播地址。
Port Number
端口号
The non-standard UDP port number to use for message transport.
用于消息传输的非标准UDP端口号。
Two distinct facilities for parameter storage are considered: For Unix-like systems a per-user configuration file SHOULD be used and for Windows-95/98/NT/2000/XP systems a set of registry entries is defined that SHOULD be used. For other systems it is RECOMMENDED that the file-based configuration mechanism is used.
考虑了两种不同的参数存储功能：对于类Unix系统，应使用每个用户的配置文件；对于Windows-95/98/NT/2000/XP系统，应定义一组应使用的注册表项。对于其他系统，建议使用基于文件的配置机制。
The syntax of the values for the respective parameter entries remains the same for both configuration facilities. The following defines a set of ABNF (see RFC 2234 [13]) productions that are later re-used for the definitions for the configuration file syntax and registry entries:
对于这两个配置工具，相应参数项的值的语法保持不变。以下定义了一组ABNF（请参阅RFC 2234[13]）产品，这些产品稍后将重新用于配置文件语法和注册表项的定义：
algo-id = "NOENCR" / "AES" / "DES" / "3DES" / "IDEA" /
"HMAC-MD5-96" / "HMAC-SHA1-96"
algo-id = "NOENCR" / "AES" / "DES" / "3DES" / "IDEA" /
"HMAC-MD5-96" / "HMAC-SHA1-96"
scope = "HOSTLOCAL" / "LINKLOCAL"
scope = "HOSTLOCAL" / "LINKLOCAL"
key = base64
key = base64
version_number = 1*10DIGIT
version_number = 1*10DIGIT
key_value = "(" algo-id "," key ")"
key_value=“（“算法id”，“键”）”
address = IPv4address / IPv6address / "BROADCAST"
address = IPv4address / IPv6address / "BROADCAST"
port = 1*5DIGIT ; values from 0 through 65535
port = 1*5DIGIT ; values from 0 through 65535
Given the definition above, a key entry MUST be specified using this notation:
根据上述定义，必须使用以下符号指定键条目：
"("algo-id","base64string")"
（“algo id”、“base64string”）
algo-id is one of the character strings specified above. For algo-id=="NOENCR" the other fields are ignored. The delimiting commas MUST always be present though.
algo id是上面指定的字符串之一。对于algo id==“NOENCR”，忽略其他字段。但分隔逗号必须始终存在。
A Base64 string consists of the characters defined in the Base64 char-set (see RFC 1521 [7]) including all possible padding characters, i.e., the length of a Base64-string is always a multiple of 4.
Base64字符串由Base64字符集（参见RFC 1521[7]）中定义的字符组成，包括所有可能的填充字符，即Base64字符串的长度始终是4的倍数。
The scope parameter is used to configure an IP-Multicast scope and may be set to either "HOSTLOCAL" or "LINKLOCAL". Implementations SHOULD choose an appropriate IP-Multicast scope depending on the
scope参数用于配置IP多播作用域，可以设置为“HOSTLOCAL”或“LINKLOCAL”。实施应根据具体情况选择适当的IP多播作用域
value of this parameter and construct an effective IP-Address considering the specifications of Section 6.1.
该参数的值，并根据第6.1节的规范构造有效的IP地址。
The use of broadcast is configured by providing the value "BROADCAST" for the address field. If broadcast has been configured, implementations SHOULD use the network broadcast address for the used IP version instead of the standard multicast address.
通过为地址字段提供值“broadcast”来配置广播的使用。如果已配置广播，则实现应使用所用IP版本的网络广播地址，而不是标准多播地址。
The version_number parameter specifies a version number for the used configuration entity.
version\u number参数指定所用配置实体的版本号。
The file name for an Mbus configuration file is ".mbus" in the user's home-directory. If an environment variable called MBUS is defined implementations SHOULD interpret the value of this variable as a fully qualified file name that is to be used for the configuration file. Implementations MUST ensure that this file has appropriate file permissions that prevent other users to read or write it. The file MUST exist before a conference is initiated. Its contents MUST be UTF-8 encoded and MUST comply to the following syntax definition:
Mbus配置文件的文件名是用户主目录中的“.Mbus”。如果定义了名为MBUS的环境变量，则实现应将此变量的值解释为用于配置文件的完全限定文件名。实现必须确保此文件具有适当的文件权限，以防止其他用户读取或写入它。在启动会议之前，文件必须存在。其内容必须是UTF-8编码的，并且必须符合以下语法定义：
mbus-file = mbus-topic LF *(entry LF)
mbus文件=mbus主题LF*（条目LF）
mbus-topic = "[MBUS]"
mbus主题=“[mbus]”
entry = 1*(version_info / hashkey_info
/ encryptionkey_info / scope_info
/ port_info / address_info)
entry = 1*(version_info / hashkey_info
/ encryptionkey_info / scope_info
/ port_info / address_info)
version_info = "CONFIG_VERSION=" version_number
版本号
hashkey_info = "HASHKEY=" key_value
hashkey\u info=“hashkey=”key\u值
encrkey_info = "ENCRYPTIONKEY=" key_value
encrkey\u info=“ENCRYPTIONKEY=”key\u值
scope_info = "SCOPE=" scope
scope\u info=“scope=”范围
port_info = "PORT=" port
port\u info=“port=”端口
address_info = "ADDRESS=" address
地址\u info=“address=”地址
The following entries are defined: CONFIG_VERSION, HASHKEY, ENCRYPTIONKEY, SCOPE, PORT, ADDRESS.
定义了以下条目：CONFIG_VERSION、HASHKEY、ENCRYPTIONKEY、SCOPE、PORT、ADDRESS。
The entries CONFIG_VERSION, HASHKEY and ENCRYPTIONKEY are mandatory, they MUST be present in every Mbus configuration file. The order of entries is not significant.
CONFIG_VERSION、HASHKEY和ENCRYPTIONKEY项是必需的，它们必须出现在每个Mbus配置文件中。条目的顺序并不重要。
An example for an Mbus configuration file:
Mbus配置文件的示例如下：
[MBUS] CONFIG_VERSION=1 HASHKEY=(HMAC-MD5-96,MTIzMTU2MTg5MTEy) ENCRYPTIONKEY=(DES,MTIzMTU2MQ==) SCOPE=HOSTLOCAL ADDRESS=224.255.222.239 PORT=47000
[MBUS]CONFIG_VERSION=1 HASHKEY=（HMAC-MD5-96，MTIzMTU2MTg5MTEy）ENCRYPTIONKEY=（DES，MTIzMTU2MQ==）SCOPE=HOSTLOCAL ADDRESS=224.255.222.239端口=47000
For systems lacking the concept of a user's home-directory as a place for configuration files the suggested database for configuration settings (e.g., the Windows9x, Windows NT, Windows 2000, Windows XP registry) SHOULD be used. The hierarchy for Mbus related registry entries is as follows:
对于没有将用户主目录作为配置文件存放位置概念的系统，应使用建议的配置设置数据库（如Windows9x、Windows NT、Windows 2000、Windows XP注册表）。Mbus相关注册表项的层次结构如下所示：
HKEY_CURRENT_USER\Software\Mbus
HKEY\ U当前\用户\软件\Mbus
The entries in this hierarchy section are:
此层次结构部分中的条目包括：
+---------------+--------+----------------+
|Name | Type | ABNF production|
+---------------+--------+----------------|
|CONFIG_VERSION | DWORD | version_number |
|HASHKEY | String | key_value |
|ENCRYPTIONKEY | String | key_value |
|SCOPE | String | scope |
|ADDRESS | String | address |
|PORT | DWORD | port |
+---------------+--------+----------------+
+---------------+--------+----------------+
|Name | Type | ABNF production|
+---------------+--------+----------------|
|CONFIG_VERSION | DWORD | version_number |
|HASHKEY | String | key_value |
|ENCRYPTIONKEY | String | key_value |
|SCOPE | String | scope |
|ADDRESS | String | address |
|PORT | DWORD | port |
+---------------+--------+----------------+
The same syntax for key values as for the file based configuration facility MUST be used.
键值必须使用与基于文件的配置工具相同的语法。
The Mbus security mechanisms are specified in Section 11.1.
第11.1节规定了Mbus安全机制。
It should be noted that the Mbus transport specification defines a mandatory baseline set of algorithms that have to be supported by implementations. This baseline set is intended to provide reasonable security by mandating algorithms and key lengths that are considered to be cryptographically strong enough at the time of writing.
应该注意的是，Mbus传输规范定义了一组必须由实现支持的强制性算法基线。此基线集旨在通过强制执行算法和密钥长度来提供合理的安全性，这些算法和密钥长度在编写本文时被认为具有足够的加密强度。
However, in order to allow for efficiency it is allowable to use cryptographically weaker algorithms, for example HMAC-MD5 instead of
然而，为了提高效率，允许使用加密能力较弱的算法，例如HMAC-MD5，而不是
HMAC-SHA1. Furthermore, encryption can be turned off completely if privacy is provided by other means or not considered important for a certain application.
HMAC-SHA1。此外，如果隐私是通过其他方式提供的，或者对某个应用程序不重要，则可以完全关闭加密。
Users of the Mbus should therefore be aware of the selected security configuration and should check if it meets the security demands for a given application. Since every implementation MUST provide the cryptographically strong algorithm it should always be possible to configure an Mbus in a way that secure communication with authentication and privacy is ensured.
因此，MBU用户应了解所选的安全配置，并应检查其是否满足给定应用程序的安全要求。由于每个实现都必须提供加密功能强大的算法，因此应始终能够以确保身份验证和隐私安全通信的方式配置MBU。
In any way, application developers should be aware of incorrect IP implementations that do not conform to RFC 1122 [2] and do send datagrams with TTL values of zero, resulting in Mbus messages sent to the local network link although a user might have selected host local scope in the Mbus configuration. When using administratively scoped multicast, users cannot always assume the presence of correctly configured boundary routers. In these cases the use of encryption SHOULD be considered if privacy is desired.
无论如何，应用程序开发人员应该知道不符合RFC 1122[2]的错误IP实现，并发送TTL值为零的数据报，从而导致发送到本地网络链路的Mbus消息，尽管用户可能在Mbus配置中选择了主机本地作用域。当使用管理范围的多播时，用户不能总是假定存在正确配置的边界路由器。在这些情况下，如果需要隐私，应考虑使用加密。
The IANA has assigned a scope-relative multicast address with an offset of 8 for Mbus/IPv4. The IPv6 permanent multicast address is FF0X:0:0:0:0:0:0:300.
IANA为Mbus/IPv4分配了一个偏移量为8的作用域相对多播地址。IPv6永久多播地址是FF0X:0:0:0:0:0:0:0:300。
The registered Mbus UDP port number is 47000.
注册的Mbus UDP端口号为47000。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[2] Braden，R.，“互联网主机的要求——通信层”，STD 3，RFC 1122，1989年10月。
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[3] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[4] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998.
[4] Hinden，R.和S.Deering，“IPv6多播地址分配”，RFC 23751998年7月。
[5] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[5] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC2104，1997年2月。
[6] Resnick, P., Editor, "Internet Message Format", RFC 2822, April 2001.
[6] Resnick，P.，编辑，“互联网信息格式”，RFC 2822，2001年4月。
[7] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, September 1993.
[7] Borenstein，N.和N.Freed，“MIME（多用途Internet邮件扩展）第一部分：指定和描述Internet邮件正文格式的机制”，RFC 15211993年9月。
[8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[8] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobsen，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[9] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[9] Handley，M.，Schulzrinne，H.，Schooler，E.和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
[10] Handley, M. and V. Jacobsen, "SDP: Session Description Protocol", RFC 2327, April 1998.
[10] Handley，M.和V.Jacobsen，“SDP：会话描述协议”，RFC 2327，1998年4月。
[11] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[11] Meyer，D.，“管理范围的IP多播”，BCP 23，RFC 2365，1998年7月。
[12] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, February 1993.
[12] Balenson，D.，“因特网电子邮件的隐私增强：第三部分：算法、模式和标识符”，RFC 1423，1993年2月。
[13] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[13] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[14] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[14] 迈尔斯，J.，“用于身份验证的SMTP服务扩展”，RFC2554，1999年3月。
[15] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[15] Rivest，R.，“MD5消息摘要算法”，RFC1321，1992年4月。
[16] U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and Technology, "Data Encryption Standard (DES)", FIPS PUB 46-3, Category Computer Security, Subcategory Cryptography, October 1999.
[16] 美国商务部/国家标准与技术研究所，“数据加密标准（DES）”，FIPS PUB 46-3，计算机安全类别，子类别加密，1999年10月。
[17] U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995.
[17] 美国商务部/国家标准与技术研究所，“安全哈希标准”，FIPS PUB 180-11995年4月。
[18] Daemen, J.D. and V.R. Rijmen, "AES Proposal: Rijndael", March 1999.
[18] Daemen，J.D.和V.R.Rijmen，“AES提案：Rijndael”，1999年3月。
[19] IANA, "Internet Multicast Addresses", URL http://www.iana.org/assignments/multicast-addresses, May 2001.
[19] IANA，“互联网多播地址”，URLhttp://www.iana.org/assignments/multicast-addresses，2001年5月。
[20] Schneier, B., "Applied Cryptography", Edition 2, Publisher John Wiley & Sons, Inc., status: non-normative, 1996.
[20] Schneier，B.，“应用密码学”，第2版，出版商John Wiley&Sons，Inc.，状态：非规范性，1996年。
Please note that the list of references contains normative as well as non-normative references. Each Non-normative references is marked as "status: non-normative". All unmarked references are normative.
请注意，参考文献列表包含规范性参考文献和非规范性参考文献。每个非规范性引用文件都标记为“状态：非规范性”。所有未标记的参考文件均为规范性文件。
The Mbus is a light-weight local coordination mechanism and deliberately not designed for larger scope coordination. It is expected to be used on a single node or -- at most -- on a single network link.
小微企业单位是一种轻量级的地方协调机制，故意不设计用于更大范围的协调。它预计将在单个节点上使用，或者最多在单个网络链路上使用。
Therefore the Mbus protocol does not contain features that would be required to qualify it for the use over the global Internet:
因此，Mbus协议不包含使其有资格在全球互联网上使用所需的功能：
There are no mechanisms to provide congestion control. The issue of congestion control is a general problem for multicast protocols. The Mbus allows for un-acknowledged messages that are sent unreliably, for example as event notifications, from one entity to another. Since negative acknowledgements are not defined there is no way the sender could realize that it is flooding another entity or congesting a low bandwidth network segment.
没有提供拥塞控制的机制。拥塞控制问题是组播协议的一个普遍问题。Mbus允许不可靠地从一个实体向另一个实体发送未确认的消息，例如作为事件通知。由于未定义否定应答，发送方无法意识到它正在淹没另一个实体或阻塞低带宽网段。
The reliability mechanism, i.e., the retransmission timers, are designed to provide effective, responsive message transport on local links but are not suited to cope with larger delays that could be introduced from router queues etc.
可靠性机制，即重传计时器，旨在在本地链路上提供有效、响应性好的消息传输，但不适合处理路由器队列等可能引入的较大延迟。
Some experiments are currently underway to test the applicability of bridges between different distributed Mbus domains without changing the basic protocol semantics. Since the use of such bridges should be orthogonal to the basic Mbus protocol definitions and since these experiments are still work in progress there is no mention of this concept in this specification.
目前正在进行一些实验，在不改变基本协议语义的情况下，测试不同分布式Mbus域之间桥接的适用性。由于此类网桥的使用应与基本的Mbus协议定义正交，并且由于这些实验仍在进行中，因此本规范中未提及此概念。
Authors' Addresses
作者地址
Joerg Ott TZI, Universitaet Bremen Bibliothekstr. 1 Bremen 28359 Germany
Joerg Ott TZI，不来梅大学图书馆。1不来梅28359德国
Phone: +49.421.201-7028
Fax: +49.421.218-7000
EMail: jo@tzi.uni-bremen.de
Phone: +49.421.201-7028
Fax: +49.421.218-7000
EMail: jo@tzi.uni-bremen.de
Colin Perkins USC Information Sciences Institute 3811 N. Fairfax Drive #200 Arlington VA 22203 USA
科林·珀金斯南加州信息科学研究所3811 N.费尔法克斯大道200号弗吉尼亚州阿灵顿22203
EMail: csp@isi.edu
EMail: csp@isi.edu
Dirk Kutscher TZI, Universitaet Bremen Bibliothekstr. 1 Bremen 28359 Germany
德克·库彻·茨，不来梅大学图书馆。1不来梅28359德国
Phone: +49.421.218-7595
Fax: +49.421.218-7000
EMail: dku@tzi.uni-bremen.de
Phone: +49.421.218-7595
Fax: +49.421.218-7000
EMail: dku@tzi.uni-bremen.de
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。