Network Working Group M. Rose
Request for Comments: 3081 Invisible Worlds, Inc.
Category: Standards Track March 2001
Network Working Group M. Rose
Request for Comments: 3081 Invisible Worlds, Inc.
Category: Standards Track March 2001
Mapping the BEEP Core onto TCP
将BEEP核心映射到TCP
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This memo describes how a BEEP (Blocks Extensible Exchange Protocol) session is mapped onto a single TCP (Transmission Control Protocol) connection.
此备忘录描述了BEEP（块可扩展交换协议）会话如何映射到单个TCP（传输控制协议）连接。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Session Management . . . . . . . . . . . . . . . . . . . . . 2
3. Message Exchange . . . . . . . . . . . . . . . . . . . . . . 2
3.1 Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1.1 Channel Creation . . . . . . . . . . . . . . . . . . . . . . 3
3.1.2 Sending Messages . . . . . . . . . . . . . . . . . . . . . . 3
3.1.3 Processing SEQ Frames . . . . . . . . . . . . . . . . . . . 4
3.1.4 Use of Flow Control . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . 6
References . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . 6
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Session Management . . . . . . . . . . . . . . . . . . . . . 2
3. Message Exchange . . . . . . . . . . . . . . . . . . . . . . 2
3.1 Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1.1 Channel Creation . . . . . . . . . . . . . . . . . . . . . . 3
3.1.2 Sending Messages . . . . . . . . . . . . . . . . . . . . . . 3
3.1.3 Processing SEQ Frames . . . . . . . . . . . . . . . . . . . 4
3.1.4 Use of Flow Control . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . 6
References . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . 6
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement . . . . . . . . . . . . . . . . . . 8
This memo describes how a BEEP [1] session is mapped onto a single TCP [2] connection. Refer to Section 2.5 of [1] for an explanation of the mapping requirements.
此备忘录描述了如何将蜂鸣声[1]会话映射到单个TCP[2]连接。有关映射要求的说明，请参阅[1]第2.5节。
The mapping of BEEP session management onto the TCP service is straight-forward.
BEEP会话管理到TCP服务的映射是直接的。
A BEEP session is established when a TCP connection is established between two BEEP peers:
在两个BEEP对等点之间建立TCP连接时，将建立BEEP会话：
o the BEEP peer that issues a passive TCP OPEN call is termed the listener; and,
o 发出被动TCP打开调用的BEEP对等方称为侦听器；和
o the BEEP peer that issues an active TCP OPEN call is termed the initiator.
o 发出活动TCP OPEN调用的BEEP对等方称为发起方。
A simultaneous TCP OPEN would result in both BEEP peers believing they are the initiator and neither peer will be able to start any channels. Because of this, services based on BEEP must be designed so that simultaneous TCP OPENs cannot occur.
同时打开TCP将导致两个BEEP对等方都认为自己是发起方，并且两个对等方都无法启动任何通道。因此，必须设计基于BEEP的服务，以避免同时打开TCP。
If both peers agree to release a BEEP session (c.f., [1]'s Section 2.4), the peer sending the "ok" reply, immediately issues the TCP CLOSE call. Upon receiving the reply, the other peer immediately issues the TCP CLOSE call.
如果两个对等方都同意释放一个BEEP会话（c.f.[1]的第2.4节），发送“ok”应答的对等方将立即发出TCP CLOSE呼叫。收到回复后，另一个对等方立即发出TCP CLOSE调用。
A BEEP session is terminated when either peer issues the TCP ABORT call, and the TCP connection is subsequently aborted.
当任一对等方发出TCP ABORT调用时，BEEP会话终止，TCP连接随后中止。
The mapping of BEEP exchanges onto the TCP service is less straight-forward.
BEEP交换到TCP服务的映射不那么直接。
Messages are reliably sent and received using TCP's SEND and RECEIVE calls. (This also provides ordered delivery of messages on the same channel.)
使用TCP的发送和接收呼叫可靠地发送和接收消息。（这还可以在同一通道上提供消息的有序传递。）
Although TCP imposes flow control on a per-connection basis, if multiple channels are simultaneously in use on a BEEP session, BEEP must provide a mechanism to avoid starvation and deadlock. To achieve this, BEEP re-introduces a mechanism used by the TCP: window-based flow control -- each channel has a sliding window that indicates the number of payload octets that a peer may transmit before receiving further permission.
Although TCP imposes flow control on a per-connection basis, if multiple channels are simultaneously in use on a BEEP session, BEEP must provide a mechanism to avoid starvation and deadlock. To achieve this, BEEP re-introduces a mechanism used by the TCP: window-based flow control -- each channel has a sliding window that indicates the number of payload octets that a peer may transmit before receiving further permission.translate error, please retry
Recall from Section 2.2.1.2 of [1] that every payload octet sent in each direction on a channel has an associated sequence number. Numbering of payload octets within a data frame is such that the first payload octet is the lowest numbered, and the following payload octets are numbered consecutively.
回想一下[1]第2.2.1.2节，在信道的每个方向上发送的每个有效负载八位组都有一个相关的序列号。数据帧内有效负载八位字节的编号应确保第一个有效负载八位字节的编号最低，并且后续有效负载八位字节的编号是连续的。
The actual sequence number space is finite, though very large, ranging from 0..4294967295 (2**32 - 1). Since the space is finite, all arithmetic dealing with sequence numbers is performed modulo 2**32. This unsigned arithmetic preserves the relationship of sequence numbers as they cycle from 2**32 - 1 to 0 again. Consult Sections 2 through 5 of [3] for a discussion of the arithmetic properties of sequence numbers.
实际的序列号空间是有限的，尽管非常大，范围在0..4294967295（2**32-1）之间。由于空间是有限的，所有处理序列号的算法都是以模2**32执行的。当序列号再次从2**32-1循环到0时，此无符号算术保留序列号之间的关系。有关序列号算术特性的讨论，请参阅[3]第2节至第5节。
When a channel is created, the sequence number associated with the first payload octet of the first data frame is 0, and the initial window size for that channel is 4096 octets. After channel creation, a BEEP peer may update the window size by sending a SEQ frame (Section 3.1.3).
当创建信道时，与第一数据帧的第一有效载荷八位组相关联的序列号为0，并且该信道的初始窗口大小为4096个八位组。信道创建后，BEEP对等方可通过发送SEQ帧更新窗口大小（第3.1.3节）。
If a BEEP peer is asked to create a channel and it is unable to allocate at least 4096 octets for that channel, it must decline creation of the channel, as specified in Section 2.3.1.2 of [1]. Similarly, during establishment of the BEEP session, if the BEEP peer acting in the listening role is unable to allocate at least 4096 octets for channel 0, then it must return a negative reply, as specified in Section 2.4 of [1], instead of a greeting.
如果BEEP对等方被要求创建一个通道，但它无法为该通道分配至少4096个八位字节，则它必须拒绝创建该通道，如[1]第2.3.1.2节所述。类似地，在建立BEEP会话期间，如果担任监听角色的BEEP对等方无法为通道0分配至少4096个八位字节，则它必须按照[1]第2.4节的规定返回否定回复，而不是问候语。
Before a message is sent, the sending BEEP peer must ensure that the size of the payload is within the window advertised by the receiving BEEP peer. If not, it has three choices:
在发送消息之前，发送蜂鸣声的对等方必须确保有效负载的大小在接收蜂鸣声的对等方公布的窗口内。如果没有，它有三个选择：
o if the window would allow for at least one payload octet to be sent, the BEEP peer may segment the message and start by sending a smaller data frame (up to the size of the remaining window);
o 如果该窗口将允许发送至少一个有效载荷八位字节，则该蜂鸣声对等方可将该消息分段并通过发送较小的数据帧（最大到剩余窗口的大小）开始；
o the BEEP peer may delay sending the message until the window becomes larger; or,
o BEEP对等方可能会延迟发送消息，直到窗口变大；或
o the BEEP peer may signal to its application that it is unable to send the message, allowing the application to try again at a later time (or perhaps signaling its application when a larger window is available).
o BEEP对等方可能会向其应用程序发出无法发送消息的信号，从而允许应用程序稍后重试（或者在较大窗口可用时向其应用程序发出信号）。
The choice is implementation-dependent, although it is recommended that the application using BEEP be given a mechanism for influencing the decision.
虽然建议为使用BEEP的应用程序提供一种影响决策的机制，但选择取决于实现。
As an application accepts responsibility for incoming data frames, its BEEP peer should send SEQ frames to advertise a new window.
当应用程序接受传入数据帧的责任时，它的BEEP对等方应该发送SEQ frames来公布新窗口。
The ABNF [4] for a SEQ frame is:
SEQ帧的ABNF[4]为：
seq = "SEQ" SP channel SP ackno SP window CR LF
seq=“seq”SP通道SP确认无SP窗口CR LF
ackno = seqno
ackno = seqno
window = size
window = size
; channel, seqno, and size are defined in Section 2.2.1 of [1].
; [1]第2.2.1节规定了通道、序号和尺寸。
The SEQ frame has three parameters:
SEQ帧有三个参数：
o a channel number;
o 频道号；
o an acknowledgement number, that indicates the value of the next sequence number that the sender is expecting to receive on this channel; and,
o 确认号，指示发送方期望在此信道上接收的下一个序列号的值；和
o a window size, that indicates the number of payload octets beginning with the one indicated by the acknowledgement number that the sender is expecting to receive on this channel.
o 窗口大小，指示有效负载八位字节的数量，从发送方期望在此信道上接收的确认号指示的八位字节开始。
A single space character (decimal code 32, " ") separates each component. The SEQ frame is terminated with a CRLF pair.
单个空格字符（十进制代码32“”）分隔每个组件。SEQ帧以CRLF对终止。
When a SEQ frame is received, if any of the channel number, acknowledgement number, or window size cannot be determined or is invalid, then the BEEP session is terminated without generating a response, and it is recommended that a diagnostic entry be logged.
当接收到SEQ帧时，如果无法确定通道号、确认号或窗口大小中的任何一个或其无效，则在不生成响应的情况下终止蜂鸣音会话，建议记录诊断条目。
The key to successful use of flow control within BEEP is to balance performance and fairness:
在BEEP中成功使用流量控制的关键是平衡性能和公平性：
o large messages should be segmented into frames no larger than two-thirds of TCP's negotiated maximum segment size;
o 大消息应分割成不大于TCP协商的最大段大小三分之二的帧；
o frames for different channels with traffic ready to send should be sent in a round-robin fashion;
o 具有准备发送的流量的不同信道的帧应以循环方式发送；
o each time a frame is received, a SEQ frame should be sent whenever the window size that will be sent is at least one half of the buffer space available to this channel; and,
o 每次接收到帧时，只要要发送的窗口大小至少是该信道可用缓冲区空间的一半，就应该发送一个SEQ帧；和
o if the transport service presents multiple frames to a BEEP peer simultaneously, then a single consolidating SEQ frame may be sent.
o 如果传输服务同时向BEEP对等方提供多个帧，则可以发送单个合并序列帧。
In order to avoid pathological interactions with the transport service, it is important that a BEEP peer advertise windows based on available buffer space, to allow data to be read from the transport service as soon as available. Further, SEQ frames for a channel must have higher priority than messages for that channel.
为了避免与传输服务的病态交互，重要的是BEEP对等机根据可用缓冲区空间通告窗口，以允许在可用时尽快从传输服务读取数据。此外，信道的SEQ帧必须比该信道的消息具有更高的优先级。
Implementations may wish to provide queue management facilities to the application using BEEP, e.g., channel priorities, (relative) buffer allocations, and so on. In particular, implementations should not allow a given channel to monopolize the underlying transport window (e.g., slow readers should get small windows).
实现可能希望使用BEEP向应用程序提供队列管理设施，例如通道优先级、（相对）缓冲区分配等。特别是，实现不应允许给定通道垄断底层传输窗口（例如，速度慢的读卡器应获得小窗口）。
In addition, where possible, implementations should support transport layer APIs that convey congestion information. These APIs allow an implementation to determine its share of the available bandwidth, and also be notified of changes in the estimated path bandwidth. Note that when a BEEP session has multiple channels that are simultaneously exchanging large messages, implementations without access to this information may have uncertain fairness and progress properties during times of network congestion.
此外，在可能的情况下，实现应该支持传输拥塞信息的传输层API。这些API允许实现确定其可用带宽的份额，并且还可以通知估计路径带宽的变化。请注意，当一个BEEP会话具有多个同时交换大型消息的通道时，在网络拥塞期间，无法访问此信息的实现可能具有不确定的公平性和进度属性。
Finally, implementors should follow the guidelines given in the relevant portions of RFC1122 [5] that deal with flow control (and bear in mind that issues such as retransmission, while they interact with flow control in TCP, are not applicable to this memo). For example, Section 4.2.2.16 of RFC1122 [5] indicates that a "receiver SHOULD NOT shrink the window, i.e., move the right window edge to the left" and then discusses the impact of this rule on unacknowledged data. In the context of mapping BEEP onto a single TCP connection, only the portions concerning flow control should be implemented.
最后，实施者应遵循RFC1122[5]中有关流量控制的相关部分中给出的指南（并记住，重传等问题在与TCP中的流量控制交互时不适用于本备忘录）。例如，RFC1122[5]第4.2.2.16节指出“接收器不应收缩窗口，即将右窗口边缘向左移动”，然后讨论此规则对未确认数据的影响。在将BEEP映射到单个TCP连接的上下文中，只应实现与流控制有关的部分。
Consult Section [1]'s Section 9 for a discussion of security issues.
有关安全问题的讨论，请参阅第[1]节的第9节。
References
工具书类
[1] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[1] Rose，M.，“块可扩展交换协议核心”，RFC 30802001年3月。
[2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[2] 《传输控制协议》，标准7，RFC 793，1981年9月。
[3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[3] Elz，R.和R.Bush，“序列号算术”，RFC 1982年，1996年8月。
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[4] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[5] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[5] Braden，R.，“互联网主机的要求——通信层”，STD 3，RFC 1122，1989年10月。
Author's Address
作者地址
Marshall T. Rose Invisible Worlds, Inc. 1179 North McDowell Boulevard Petaluma, CA 94954-6559 US
美国加利福尼亚州佩塔卢马北麦克道尔大道1179号马歇尔T.罗斯隐形世界公司，邮编94954-6559
Phone: +1 707 789 3700
EMail: mrose@invisible.net
URI: http://invisible.net/
Phone: +1 707 789 3700
EMail: mrose@invisible.net
URI: http://invisible.net/
The author gratefully acknowledges the contributions of: Dave Crocker, Steve Harris, Eliot Lear, Keith McCloghrie, Craig Partridge, Vernon Schryver, and, Joe Touch. In particular, Dave Crocker provided helpful suggestions on the nature of flow control in the mapping.
作者感谢戴夫·克罗克、史蒂夫·哈里斯、艾略特·李尔、基思·麦克洛格里、克雷格·帕特里奇、弗农·施莱弗和乔·图奇的贡献。特别是，Dave Crocker就映射中的流控制的性质提供了有用的建议。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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编辑功能的资金目前由互联网协会提供。