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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
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と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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
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）は、アプリケーションプロトコルの開発に必要な側面の多くを管理するプロトコル・フレームワークを提供します。しかし、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.
この文書は、非同期チャネルの使用を可能にBEEP機能を定義します。非同期チャネルは、応答の順序について[RFC3080]のセクション2.6.1の制限を受けないBEEPチャンネルです。要求が処理され、サービングピアによって任意の順序でに対応することができます。
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」要素を使用します。定期BEEPチャンネルは、パラメータの存在によって推論されるかもしれないものに反し要求/応答の相関関係、のための「MSGNO」を使用しないでください。正規BEEPチャネルにおいて、「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の挨拶で「機能」属性は、各ピアでサポートされている機能の空白で区切られたリストが含まれています。両方のリストが同じの機能が含まれている場合は、その機能は、いずれかのピアが使用することができます。
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：私は<着信接続を待つ>：<オープン接続> L：RPY 0 0。 0 133 L：コンテンツタイプ：アプリケーション/ビープ+ XMLのL：L <挨拶機能= "非同期X-FOO"> L <プロファイルURI = "http://example.com/beep/APP" /> L ：</挨拶> L：END I：RPY 0 0。 0 69 I：のContent-Type：アプリケーション/ビープ音+ xmlのI：I：<挨拶機能= "非同期" /> I：END
Figure 1: BEEP Greetings with Asynchronous Feature
図1：非同期機能付きBEEPあいさつ
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.
非同期チャネルを作成するには、「真」に設定し、「非同期」パラメータが「開始」の要求に含まれています。省略、または「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
C：MSG 0 1。 52 130 C：コンテンツタイプ：アプリケーション/ビープ+ XMLのC：C：<開始番号= "1" 非同期= "真"> C <プロファイルURI = "http://example.org/protocol" /> C <開始/> C：ENDのS：RPY 0 1。 221 102 S：コンテンツタイプ：アプリケーション/ビープ+ XMLのS：S：<プロファイル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
C：MSG 0 1。 52 128 C：コンテンツタイプ：アプリケーション/ビープ+ XMLのC：C：<開始番号= "1" 非同期= "真"> C <プロファイルURI = "http://example.org/serial" /> C <開始/> C：ENDのS：0 1 ERR。 221 152 S：コンテンツタイプ：アプリケーション/ビープ+ XMLのS：S：<エラーコード= "553">プロフィール＆LT; HTTP：//example.org/serial& GT。 S：非同期チャネルに使用することはできません。</エラー> 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.
非同期チャネルは、一方向にのみ正常BEEPチャネルから異なる：非同期チャネルを処理し、応答順序について[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" メッセージ）を任意の順序で送信することができます。 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.
注：この規則の例外は、インターリーブのために[RFC3080]に構成されている「ANS」セグメントは、同じ「MSG」に応答して送信されます。 BEEPピアは、インターリーブANSセグメントを生成しないことをお勧めします。
The BEEP management channel (channel 0) is never asynchronous.
BEEP管理チャネル（チャネル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節からテンプレート以下、BEEPパラメータレジストリにBEEP「非同期」機能を登録します。
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>
お問い合わせ先：マーティン・トムソン<martin.thomson@andrew.com>
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[RFC3080]ローズ、M.、 "ブロック拡張可能交換プロトコルコア"、RFC 3080、2001年3月。
[RFC3081] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.
[RFC3081]ローズ、M.、 "TCP上にBEEPコアのマッピング"、RFC 3081、2001年3月。
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン、V.、ブレーデン、B.、およびD.ボーマン、 "ハイパフォーマンスのための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/
電話：+61 2 4221 2915 Eメール：martin.thomson@andrew.com URI：http://www.andrew.com/