[要約] RFC 5573は、BEEP（Blocks Extensible Exchange Protocol）の非同期チャネルに関する仕様であり、BEEPの拡張性と柔軟性を向上させることを目的としています。このRFCは、非同期通信のための新しいチャネルタイプを定義し、BEEPの機能を拡張します。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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）は、アプリケーションプロトコルの開発のためのプロトコルフレームワークを提供します。このドキュメントでは、個々のチャネルの非同期を可能にするビープ機能について説明します。
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
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.
ブロック拡張可能な交換プロトコル（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.
このドキュメントでは、非同期チャネルの作成を可能にするビープ音の拡張機能について説明します。非同期チャネルは、クライアントピアが送信したリクエストの順序に応答順序が固定されていないチャネルです。非同期チャネルは、変更されていないフレーミングを使用して、他のチャネルと同じです。要求が並行して処理され、応答が任意の順序で送信される場合があります。
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.
ビープ機能の交渉は、両方のピアが非同期チャネルを相互に喜んで作成することを保証するために使用されます。非同期チャネルを確立するための手段について説明します。
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.
非同期チャネルは、ビープフレームヘッダーの「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.
Beep Greetingの「機能」属性には、各ピアがサポートする特徴の白人分離されたリストが含まれています。両方のリストに同じ機能が含まれている場合、その機能はどちらのピアでも使用できます。
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.
このドキュメントは、機能「Async」を登録します。どちらかのピアがこの機能をグリーティングメッセージに含めていない場合、どちらのピアも非同期チャネルを作成することはできません。
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
Figure 1: BEEP Greetings with Asynchronous Feature
図1：非同期機能を備えたビープ音
The registration template for BEEP features is included in Section 5.
ビープ機能の登録テンプレートは、セクション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」に設定された「非同期」パラメーターが「start」リクエストに含まれています。省略または「false」に設定した場合、チャネルは非同期ではありません。
Figure 2 shows how the "async" attribute can be used to start an asynchronous channel.
図2は、「非同期」属性を使用して非同期チャネルを起動する方法を示しています。
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.
サービングピアが何らかの理由で非同期チャネルを作成できない場合、チャネルの開始は拒否されます。これは、選択したプロファイルが非同期チャネルに適していない場合に発生する可能性があります。応答には、図3に示すように、「553」応答コード（パラメーター無効）と適切なメッセージを含めることができます。
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.
非同期チャネルは、通常のビープチャネルとは1つの方法でのみ異なります。非同期チャネルは、処理および応答の順序付けに関して[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」要素を使用して、要求と応答を相関させます。トリガーされた要求とは異なる順序で応答を受信するビープピアは、これをプロトコルエラーと見なしてはなりません。
"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"メッセージ）は、任意の順序で送信できます。1対多くの交換で送信される異なる「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.
注：このルールの例外は、同じ「MSG」に応じて送信されたインターリーブ「ANS」セグメントの[RFC3080]で行われます。ビープピアがインターリーブした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.
ビープは、リクエストに応答しないピアを管理するためのメカニズムを提供しません。同期チャネルは、ピアがリクエストへの応答を提供しない場合、使用したり、閉じたりすることさえできません。利用可能な唯一の治療法は、基礎となる輸送を閉じることです。非同期チャネルは閉じることはできませんが、さらにリクエストに使用できます。ただし、未解決のリクエストは依然として州のリソースを消費します。クライアントのピアは、設定された間隔の後にそのような状態を処分する場合がありますが、そうする場合は認識されていない応答を破棄する準備をする必要があります。
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.
アプリケーションプロトコルを変更すると、非同期交換にシリアルチャネルを使用できます。非同期は、リクエストと応答を分離することにより、ビープ音の上のプロトコル層で提供できます。これには、独自の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」として送信されます。この2番目の「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.
チャネルの非同期メッセージングを有効にするには、追加の状態情報のメンテナンスが潜在的に必要です。メッセージに返信しないサーバーの役割のピアは、クライアントピアに状態が蓄積する可能性があります。この状態情報が制限されていない場合、このモードを使用してサービスの拒否を実行できます。この問題は、すでにビープ音に存在しますが、非同期チャネルで受け取ったリクエストに対して発生する可能性のあるサービングピアの処理の性質により、潜在的により重要です。拒否が可能である程度は、サービングピアが受け入れるものによって制限されます。未解決の要求の数は、国家の過度の蓄積から保護するために制限される可能性があります。
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
機能識別：async
Feature Semantics: This feature enables the creation of asynchronous channels, see Section 2 of RFC 5573.
機能セマンティクス：この機能により、非同期チャネルの作成が可能になります。RFC5573のセクション2を参照してください。
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 3080、2001年3月。
[RFC3081] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.
[RFC3081] Rose、M。、「ビープコアのマッピング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拡張のためのTCP拡張」、RFC 1323、1992年5月。
Author's Address
著者の連絡先
Martin Thomson Andrew PO Box U40 Wollongong University Campus, NSW 2500 AU
マーティントムソンアンドリューポックスU40ウロンゴン大学キャンパス、NSW 2500 AU
Phone: +61 2 4221 2915
EMail: martin.thomson@andrew.com
URI: http://www.andrew.com/