Network Working Group M. Thomson
Request for Comments: 5573 Andrew
Category: Experimental June 2009
Network Working Group M. Thomson
Request for Comments: 5573 Andrew
Category: Experimental June 2009
Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP)
块可扩展交换协议（BEEP）的异步通道
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
The Blocks Extensible Exchange Protocol (BEEP) provides a protocol framework for the development of application protocols. This document describes a BEEP feature that enables asynchrony for individual channels.
块可扩展交换协议（BEEP）为应用程序协议的开发提供了一个协议框架。本文档介绍了一种BEEP功能，该功能可为各个通道启用异步。
Table of Contents
目录
1. Introduction ....................................................2
2. Asynchronous BEEP Channels ......................................3
2.1. Asynchronous Feature .......................................3
2.2. Starting an Asynchronous Channel ...........................4
2.3. Asynchronous Channel Behavior ..............................5
2.4. Error Handling .............................................6
3. Alternatives ....................................................6
3.1. Increasing Throughput ......................................6
3.2. Asynchrony in the Application Protocol .....................7
4. Security Considerations .........................................7
5. IANA Considerations .............................................8
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................8
1. Introduction ....................................................2
2. Asynchronous BEEP Channels ......................................3
2.1. Asynchronous Feature .......................................3
2.2. Starting an Asynchronous Channel ...........................4
2.3. Asynchronous Channel Behavior ..............................5
2.4. Error Handling .............................................6
3. Alternatives ....................................................6
3.1. Increasing Throughput ......................................6
3.2. Asynchrony in the Application Protocol .....................7
4. Security Considerations .........................................7
5. IANA Considerations .............................................8
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................8
The Blocks Extensible Exchange Protocol (BEEP) provides a protocol framework that manages many of the aspects necessary in developing an application protocol: framing, encoding, privacy, authentication, and asynchrony. However, the asynchrony provided by BEEP is limited to asynchrony between channels; replies to messages sent on any channel are strictly ordered.
Blocks Extensible Exchange Protocol（BEEP）提供了一个协议框架，用于管理开发应用程序协议所需的许多方面：帧、编码、隐私、身份验证和异步。但是，BEEP提供的异步仅限于通道之间的异步；对任何频道发送的邮件的回复都是严格有序的。
Serial processing behavior is desirable for a range of applications. However, serial processing is less suitable for applications that rely more heavily on asynchrony. In particular, if a response takes a significant amount of time to create, the channel is effectively blocked until the request has been processed and the response sent. Pipelining only ensures that network latency does not add to this time; subsequent requests cannot be processed until a response is made to the first request.
串行处理行为适用于一系列应用。但是，串行处理不太适用于更严重依赖异步的应用程序。特别是，如果一个响应需要大量的时间来创建，那么通道将被有效地阻塞，直到请求被处理并发送响应为止。流水线只确保网络延迟不会增加这一时间；在对第一个请求做出响应之前，无法处理后续请求。
Asynchronous applications require a protocol that is able to support a large number of concurrent outstanding requests. The analogy of a channel as a thread does not scale to the large number of threads used in modern systems. Modern applications regularly have large numbers of concurrent processing threads. Thus, a better way of multiplexing large numbers of concurrent requests is required.
异步应用程序需要一个能够支持大量并发未决请求的协议。将通道类比为线程并不适用于现代系统中使用的大量线程。现代应用程序通常有大量并发处理线程。因此，需要一种更好的多路复用大量并发请求的方法。
This document describes a BEEP feature, an extension to BEEP, that enables the creation of an asynchronous channel. An asynchronous channel is a channel where response ordering is not fixed to the order of the requests sent by the client peer. An asynchronous channel is identical to other channels, using unmodified framing; except that requests may be processed in parallel and responses may be sent in any order.
本文档介绍了BEEP功能，它是BEEP的扩展，支持创建异步通道。异步通道是一种响应顺序不固定于客户端对等方发送的请求顺序的通道。异步信道与其他信道相同，使用未修改的帧；但请求可以并行处理，响应可以按任何顺序发送。
An asynchronous channel enables the efficient use of a single channel for multiple concurrent requests. There is no impact on requests arising from the timing of responses to other requests. The requesting peer can process responses to the requests it sends as they come available; similarly, the serving peer can take advantage of parallel processing without artificial constraints on the order of responses.
异步通道可以有效地将单个通道用于多个并发请求。对其他请求的响应时间对请求没有影响。请求方可以在请求可用时处理对其发送的请求的响应；类似地，服务对等方可以利用并行处理，而不需要对响应顺序进行人工约束。
Asynchronous channels allow for greater throughput where the serving peer requires any time to process requests. This is particularly relevant where the serving peer needs to perform lengthy computations or make network-based requests as a part of servicing the request.
异步通道允许在服务对等方需要任何时间处理请求的情况下获得更大的吞吐量。当服务对等方需要执行冗长的计算或发出基于网络的请求作为服务请求的一部分时，这一点尤其重要。
BEEP feature negotiation is used to ensure that both peers are mutually willing to create asynchronous channels. A means for establishing an asynchronous channel is described.
BEEP特性协商用于确保两个对等方都愿意创建异步通道。描述了建立异步信道的方法。
This document is published as an Experimental RFC in order to find out whether the extension is going to be deployed for use in a variety of use cases and applications.
本文档以实验性RFC的形式发布，目的是了解扩展是否将被部署用于各种用例和应用程序。
This document defines a BEEP feature that enables the use of asynchronous channels. An asynchronous channel is a BEEP channel that is not subject to the restrictions of Section 2.6.1 of [RFC3080] regarding ordering of responses; requests can be processed and responded to in any order by the serving peer.
本文档定义了允许使用异步通道的蜂鸣功能。异步通道是一种蜂鸣声通道，不受[RFC3080]第2.6.1节关于响应顺序的限制；服务对等方可以按任何顺序处理和响应请求。
Asynchronous channels use the "msgno" element of the BEEP frame header to correlate request and response. Regular BEEP channels do not use "msgno" for request/response correlation, contrary to what might be inferred by the presence of the parameter. In a regular BEEP channel, the "msgno" only serves as a means of checking for protocol errors.
异步通道使用BEEP帧头的“msgno”元素关联请求和响应。常规蜂鸣音通道不使用“msgno”进行请求/响应关联，这与参数的存在可能推断的情况相反。在常规的蜂鸣声通道中，“msgno”仅作为检查协议错误的一种手段。
Asynchronous channels are not suitable for applications where state established by requests is relied upon in subsequent requests or the ordering of messages is significant.
异步通道不适用于在后续请求中依赖由请求建立的状态或消息顺序非常重要的应用程序。
The "feature" attribute in the BEEP greeting contains a whitespace-separated list of features supported by each peer. If both lists contain the same feature, that feature may be used by either peer.
蜂鸣问候语中的“feature”属性包含一个以空格分隔的列表，其中列出了每个对等方支持的功能。如果两个列表包含相同的功能，则任何一个对等方都可以使用该功能。
This document registers the feature "async". If either peer does not include this feature in the greeting message, neither peer is able to create an asynchronous channel.
本文档注册了“异步”功能。如果任一对等方未在问候消息中包含此功能，则两个对等方都无法创建异步通道。
Figure 1 shows an example exchange where both peers declare willingness to use this feature.
图1显示了一个示例交换，其中两个对等方都声明愿意使用此功能。
L: <wait for incoming connection>
I: <open connection>
L: RPY 0 0 . 0 133
L: Content-Type: application/beep+xml
L:
L: <greeting features="async x-foo">
L: <profile uri="http://example.com/beep/APP" />
L: </greeting>
L: END
I: RPY 0 0 . 0 69
I: Content-Type: application/beep+xml
I:
I: <greeting features="async" />
I: END
L: <wait for incoming connection>
I: <open connection>
L: RPY 0 0 . 0 133
L: Content-Type: application/beep+xml
L:
L: <greeting features="async x-foo">
L: <profile uri="http://example.com/beep/APP" />
L: </greeting>
L: END
I: RPY 0 0 . 0 69
I: Content-Type: application/beep+xml
I:
I: <greeting features="async" />
I: END
Figure 1: BEEP Greetings with Asynchronous Feature
图1：具有异步功能的蜂鸣问候语
The registration template for BEEP features is included in Section 5.
BEEP功能的注册模板包含在第5节中。
To create an asynchronous channel, an "async" parameter set to "true" is included in the "start" request. If omitted, or set to "false", the channel is not asynchronous.
要创建异步通道，“启动”请求中包含一个设置为“true”的“async”参数。如果省略或设置为“false”，则通道不是异步的。
Figure 2 shows how the "async" attribute can be used to start an asynchronous channel.
图2显示了如何使用“async”属性启动异步通道。
C: MSG 0 1 . 52 130
C: Content-Type: application/beep+xml
C:
C: <start number="1" async="true">
C: <profile uri="http://example.org/protocol"/>
C: </start>
C: END
S: RPY 0 1 . 221 102
S: Content-Type: application/beep+xml
S:
S: <profile uri="http://example.org/protocol"/>
S: END
C: MSG 0 1 . 52 130
C: Content-Type: application/beep+xml
C:
C: <start number="1" async="true">
C: <profile uri="http://example.org/protocol"/>
C: </start>
C: END
S: RPY 0 1 . 221 102
S: Content-Type: application/beep+xml
S:
S: <profile uri="http://example.org/protocol"/>
S: END
Figure 2: Asynchronous Channel Start
图2：异步通道启动
If the serving peer is unable to create an asynchronous channel for any reason, the channel start is rejected. This could occur if the selected profile is not suitable for an asynchronous channel. The response can include the "553" response code (parameter invalid) and an appropriate message, as shown in Figure 3.
如果服务对等方由于任何原因无法创建异步通道，则拒绝通道启动。如果所选配置文件不适用于异步通道，则可能发生这种情况。响应可以包括“553”响应代码（参数无效）和适当的消息，如图3所示。
C: MSG 0 1 . 52 128
C: Content-Type: application/beep+xml
C:
C: <start number="1" async="true">
C: <profile uri="http://example.org/serial"/>
C: </start>
C: END
S: ERR 0 1 . 221 152
S: Content-Type: application/beep+xml
S:
S: <error code="553">Profile <http://example.org/serial>
S: cannot be used for asynchronous channels.</error>
S: END
C: MSG 0 1 . 52 128
C: Content-Type: application/beep+xml
C:
C: <start number="1" async="true">
C: <profile uri="http://example.org/serial"/>
C: </start>
C: END
S: ERR 0 1 . 221 152
S: Content-Type: application/beep+xml
S:
S: <error code="553">Profile <http://example.org/serial>
S: cannot be used for asynchronous channels.</error>
S: END
Figure 3: Asynchronous Channel Start Error
图3：异步通道启动错误
Asynchronous channels differ from normal BEEP channels in one way only: an asynchronous channel is not subject to the restrictions in Section 2.6.1 of [RFC3080] regarding the processing and response ordering. A peer in the serving role may process and respond to requests in any order it chooses.
异步信道仅在一个方面不同于正常蜂鸣信道：异步信道不受[RFC3080]第2.6.1节中关于处理和响应顺序的限制。担任服务角色的对等方可以按照其选择的任何顺序处理和响应请求。
In an asynchronous channel, the "msgno" element of the frame header is used to correlate request and response. A BEEP peer receiving responses in a different order than the requests that triggered them must not regard this as a protocol error.
在异步通道中，帧头的“msgno”元素用于关联请求和响应。以不同于触发响应的请求的顺序接收响应的BEEP对等方不得将此视为协议错误。
"MSG" messages sent on an asynchronous channel may be processed in parallel by the serving peer. Responses ("RPY", "ANS", "NUL", or "ERR" messages) can be sent in any order. Different "ANS" messages that are sent in a one-to-many exchange may be interleaved with responses to other "MSG" messages.
在异步通道上发送的“MSG”消息可由服务对等方并行处理。响应（“RPY”、“ANS”、“NUL”或“ERR”消息）可以按任何顺序发送。在一对多交换中发送的不同“ANS”消息可能与对其他“MSG”消息的响应交错。
An asynchronous channel must still observe the rules in [RFC3080] regarding segmented messages. Each message must be completed before any other message can be sent on that same channel.
异步通道仍必须遵守[RFC3080]中有关分段消息的规则。在同一通道上发送任何其他消息之前，必须先完成每条消息。
Note: An exception to this rule is made in [RFC3080] for interleaved "ANS" segments sent in response to the same "MSG". It is recommended that BEEP peers do not generate interleaved ANS segments.
注：在[RFC3080]中，对于响应相同“MSG”而发送的交错“ANS”段，该规则有一个例外。建议BEEP对等方不要生成交错的ANS段。
The BEEP management channel (channel 0) is never asynchronous.
蜂鸣音管理通道（通道0）从不异步。
BEEP does not provide any mechanism for managing a peer that does not respond to a request. Synchronous channels cannot be used or even closed if a peer does not provide a response to a request. The only remedy available is closing the underlying transport. While an asynchronous channel cannot be closed, it can still be used for further requests. However, any outstanding request still consumes state resources. Client peers may dispose of such state after a configured interval, but must be prepared to discard unrecognized responses if they do so.
BEEP不提供任何机制来管理不响应请求的对等方。如果对等方不提供对请求的响应，则无法使用甚至关闭同步通道。唯一可用的补救办法是关闭基础传输。虽然异步通道无法关闭，但仍可以用于进一步的请求。但是，任何未完成的请求仍然会消耗状态资源。客户端对等方可以在配置的时间间隔后处理此类状态，但如果这样做，则必须准备放弃无法识别的响应。
The option presented in this document provides for asynchronous communication. Asynchronous channels might not be applicable in every circumstance, particularly where ordering of requests is significant. Depending on application protocol requirements, the alternatives discussed in this section could be more applicable.
本文档中提供的选项提供异步通信。异步通道可能不适用于所有情况，特别是在请求排序非常重要的情况下。根据应用协议要求，本节讨论的备选方案可能更适用。
In some cases, asynchronous channels can be used to remove limitations on message processing throughput. Alternatively, pipelining of requests can increase throughput significantly where network latency is the limiting factor. Spreading requests over several channels increases overall throughput, if throughput is the only consideration.
在某些情况下，可以使用异步通道来消除对消息处理吞吐量的限制。或者，在网络延迟是限制因素的情况下，请求的管道化可以显著提高吞吐量。如果吞吐量是唯一需要考虑的因素，那么将请求分散到多个通道上会提高总体吞吐量。
Note: Be wary of false optimizations that rely on the pipelining of requests. If later requests in a series of pipelined requests rely on state established by earlier requests, errors in earlier requests could invalidate later requests.
注意：要警惕依赖于请求管道的错误优化。如果一系列流水线请求中的后续请求依赖于早期请求建立的状态，则早期请求中的错误可能会使后续请求无效。
The flow control window used in the TCP mapping [RFC3081] can introduce a limiting factor in throughput for individual channels. Choice of TCP window size similarly limits throughput, see [RFC1323]. To avoid limitations introduced by flow control, receiving peers can increase the window size used; sending peers can open additional channels with the same profile. Correctly managing flow control also applies to asynchronous channels.
TCP映射[RFC3081]中使用的流量控制窗口可能会在各个通道的吞吐量中引入限制因素。TCP窗口大小的选择同样限制了吞吐量，请参见[RFC1323]。为了避免流控制带来的限制，接收对等方可以增加使用的窗口大小；发送对等方可以使用相同的配置文件打开其他通道。正确管理流控制也适用于异步通道。
With changes to the application protocol, serial channels can be used for asynchronous exchanges. Asynchrony can be provided at a protocol layer above BEEP by separating request and response. This requires the addition of proprietary MIME headers or modifications to the application protocol.
通过更改应用程序协议，串行通道可用于异步交换。通过分离请求和响应，可以在BEEP之上的协议层提供异步。这需要添加专有的MIME头或修改应用程序协议。
The serving peer provides an immediate "RPY" (or "NUL") response to requests. This frees the channel for further requests. The actual response is sent as a separate "MSG" using a special identifier included in the original request to correlate the response with the request. This second "MSG" can be sent on the same channel (since these are full duplex) or on a channel specifically created for this purpose.
服务对等方提供对请求的即时“RPY”（或“NUL”）响应。这将为进一步的请求释放通道。实际响应作为单独的“MSG”发送，使用原始请求中包含的特殊标识符将响应与请求关联起来。第二个“MSG”可以在同一通道上发送（因为它们是全双工的），或者在专门为此目的创建的通道上发送。
This method is not favored since it requires that the application protocol solve the problem of correlating request with response. BEEP aims to provide a general framework for the creation of an application protocol, and for it to not provide request/response correlation would limit its usefulness. Using a MIME header is also possible, but using "msgno" is the most elegant solution.
这种方法不受欢迎，因为它要求应用程序协议解决请求与响应之间的关联问题。BEEP旨在为创建应用程序协议提供一个通用框架，如果它不提供请求/响应关联，将限制其用途。使用MIME头也是可能的，但使用“msgno”是最优雅的解决方案。
Enabling asynchronous messaging for a channel potentially requires the maintenance of additional state information. A peer in the server role that does not reply to messages can cause the accumulation of state at the client peer. If this state information were not limited, this mode could be used to perform denial of service. This problem, while already present in BEEP, is potentially more significant due to the nature of the processing on the serving peer that might occur for requests received on an asynchronous channel. The extent to which denial is possible is limited by what a serving peer accepts; the number of outstanding requests can be restricted to protect against excessive accumulation of state.
为通道启用异步消息传递可能需要维护其他状态信息。服务器角色中不回复消息的对等方可能会导致客户端对等方的状态累积。如果此状态信息不受限制，则此模式可用于执行拒绝服务。这个问题虽然已经出现在BEEP中，但由于在异步通道上接收到的请求在服务对等方上可能会发生的处理性质，它可能更为重要。拒绝的可能程度受服务对等方接受的内容的限制；可以限制未完成请求的数量，以防止状态的过度累积。
A client peer maintains state for each request that it sends. A client peer should enforce a configurable limit on the number of requests that it will allow to be outstanding at any time. This limit could be enforced at channel, connection, or application scope. Once this limit is reached, the client peer might prevent or block further requests from been generated.
客户端对等方维护其发送的每个请求的状态。客户端对等方应该对其允许在任何时候未完成的请求数量实施可配置的限制。此限制可以在通道、连接或应用程序范围强制执行。一旦达到此限制，客户端对等方可能会阻止或阻止生成进一步的请求。
Peers that serve requests on asynchronous channels also accumulate state when a request is accepted for processing. Peers in the serving role may similarly limit to the number of requests that are processed concurrently. Once this limit is reached the receiving
在异步通道上为请求提供服务的对等方在接受请求进行处理时也会累积状态。服务角色中的对等方可以类似地限制并发处理的请求数量。一旦达到此限制，接收
peer can either stop reading new requests, or might start rejecting such requests by generating error responses. Alternatively, the flow control [RFC3081] can be used; "SEQ" frames can be suppressed, allowing the flow control window to close and preventing the receipt of further requests.
对等方可以停止读取新请求，也可以通过生成错误响应来拒绝此类请求。或者，可以使用流量控制[RFC3081]；“SEQ”帧可以被抑制，从而允许流控制窗口关闭并阻止接收进一步的请求。
This section registers the BEEP "async" feature in the BEEP parameters registry, following the template from Section 5.2 of [RFC3080].
本节按照[RFC3080]第5.2节中的模板，在蜂鸣参数注册表中注册蜂鸣“异步”功能。
Feature Identification: async
特征识别：异步
Feature Semantics: This feature enables the creation of asynchronous channels, see Section 2 of RFC 5573.
功能语义：此功能支持创建异步通道，请参阅RFC 5573第2节。
Contact Information: Martin Thomson <martin.thomson@andrew.com>
Contact Information: Martin Thomson <martin.thomson@andrew.com>
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[RFC3080]Rose，M.，“块可扩展交换协议核心”，RFC 30802001年3月。
[RFC3081] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.
[RFC3081]Rose，M.，“将BEEP核心映射到TCP”，RFC 3081，2001年3月。
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]Jacobson，V.，Braden，B.，和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
Author's Address
作者地址
Martin Thomson Andrew PO Box U40 Wollongong University Campus, NSW 2500 AU
马丁·汤姆森·安德鲁·波克斯U40卧龙岗大学校园，新南威尔士州2500
Phone: +61 2 4221 2915
EMail: martin.thomson@andrew.com
URI: http://www.andrew.com/
Phone: +61 2 4221 2915
EMail: martin.thomson@andrew.com
URI: http://www.andrew.com/