RFC1693 日本語訳
1693 An Extension to TCP : Partial Order Service. T. Connolly, P.Amer, P. Conrad. November 1994. (Format: TXT=90100 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group T. Connolly
Request for Comments: 1693 P. Amer
Category: Experimental P. Conrad
University of Delaware
November 1994
コメントを求めるワーキンググループT.コノリー要求をネットワークでつないでください: 1693年のP.アメアカテゴリ: 実験的なP.コンラッドデラウエア大学1994年11月
An Extension to TCP : Partial Order Service
TCPへの拡大: 部分的なオーダーサービス
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
IESG Note:
IESGは以下に注意します。
Note that the work contained in this memo does not describe an Internet standard. The Transport AD and Transport Directorate do not recommend the implementation of the TCP modifications described. However, outside the context of TCP, we find that the memo offers a useful analysis of how misordered and incomplete data may be handled. See, for example, the discussion of Application Layer Framing by D. Clark and D. Tennenhouse in, "Architectural Considerations for a New Generation of Protocols", SIGCOM 90 Proceedings, ACM, September 1990.
このメモに含まれた仕事がインターネット標準について説明しないことに注意してください。 Transport ADとTransport Directorateは変更が説明したTCPの実装を推薦しません。 しかしながら、TCPの文脈の外では、私たちは、メモがmisorderedされて不完全なデータがどう扱われるかもしれないかに関する役に立つ分析を提供するのがわかりました。 例えば、D.クラークと中のD.TennenhouseによるApplication Layer Framingの議論、「プロトコルの新しい世代建築問題」と見てください、SIGCOM90Proceedings、ACM、1990年9月。
Abstract
要約
This RFC introduces a new transport mechanism for TCP based upon partial ordering. The aim is to present the concepts of partial ordering and promote discussions on its usefulness in network communications. Distribution of this memo is unlimited.
このRFCは順序に基づくTCPのために新しい移送機構を紹介します。 目的は、順序の概念を提示して、ネットワークコミュニケーションの有用性についての議論を促進することです。 このメモの分配は無制限です。
Introduction
序論
A service which allows partial order delivery and partial reliability is one which requires some, but not all objects to be received in the order transmitted while also allowing objects to be transmitted unreliably (i.e., some may be lost).
部分的な注文配送と部分的な信頼性を許容するサービスはすべてのオブジェクトではなく、何かがまた、オブジェクトが当てにならずに伝えられるのを許容している間に伝えられたオーダーに受け取られるのを必要とするもの(すなわち、或るものは失われるかもしれない)です。
The realization of such a service requires, (1) communication and/or negotiation of what constitutes a valid ordering and/or loss-level, and (2) an algorithm which enables the receiver to ascertain the deliverability of objects as they arrive. These issues are addressed here - both conceptually and formally - summarizing the results of research and initial implementation efforts.
到着するとき受信機がオブジェクトのデリベラビリティを確かめるのを可能にする(2) サービスが必要とするそのようなもの、(1)コミュニケーション、そして/または、有効な注文、そして/または、損失レベルを構成することに関する交渉と、アルゴリズムの実現。 これらの問題は、研究と初期の実装取り組みの結果をまとめながら、ここで概念的に正式に扱われます。
Connolly, Amer & Conrad [Page 1] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[1ページ]RFC1693: 部分的なオーダーサービス1994年11月
The authors envision the use of a partial order service within a connection-oriented, transport protocol such as TCP providing a further level of granularity to the transport user in terms of the type and quality of offered service. This RFC focuses specifically on extending TCP to provide partial order connections.
作者は、TCPなどの接続指向の輸送プロトコルの中の部分的なオーダーサービスの使用が提供サービスのタイプと品質に関してさらなるレベルの粒状を輸送ユーザに提供するのを思い描きます。 このRFCは、部分的なオーダー接続を提供するために特にTCPを広げるのは焦点を合わせます。
The idea of a partial order service is not limited to TCP. It may be considered a useful option for any transport protocol and we encourage researchers and practitioners to investigate further the most effective uses for partial ordering whether in a next-generation TCP, or another general purpose protocol such as XTP, or perhaps within a "special purpose" protocol tailored to a specific application and network profile.
部分的にオーダーサービスの考えはTCPに制限されません。 研究者と開業医がさらに順序への最も効果的な用途を調査するようそれはどんなトランスポート・プロトコルのための役に立つオプションであるとも考えられるかもしれなくて、私たちは、次世代TCPか、XTPなどの別の汎用のプロトコルか恐らく特定のアプリケーションとネットワーク・プロファイルに適合した「専用である」プロトコル以内にかかわらず奨励します。
Finally, while the crux of this RFC relates to and introduces a new way of considering object ordering, a number of other classic transport mechanisms are also seen in a new light - among these are reliability, window management and data acknowledgments.
また、最終的に、このRFCの要所がオブジェクト注文を考える新しい方法に関連して、導入している間、多くの他の古典的な移送機構が新しい光の中で見られます--このうち、信頼性、ウィンドウ管理、およびデータ承認があります。
Keywords: partial order, quality of service, reliability, multimedia, client/server database, Windows, transport protocol
キーワード: 部分的な注文、サービスの質、信頼性、マルチメディア、クライアント/サーバデータベース、Windows、トランスポート・プロトコル
Table of Contents
目次
1. Introduction and motivation .................................. 3 2. Partial Order Delivery ....................................... 4 2.1 Example 1: Remote Database .................................. 4 2.2 Example 2: Multimedia ....................................... 8 2.3 Example 3: Windows Screen Refresh ........................... 9 2.4 Potential Savings ........................................... 10 3. Reliability vs. Order ........................................ 12 3.1 Reliability Classes ......................................... 13 4. Partial Order Connection ..................................... 15 4.1 Connection Establishment .................................... 16 4.2 Data Transmission ........................................... 19 4.2.1 Sender .................................................... 22 4.2.2 Receiver .................................................. 25 5. Quantifying and Comparing Partial Order Services ............. 30 6. Future Direction ............................................. 31 7. Summary ...................................................... 32 8. References ................................................... 34 Security Considerations ......................................... 35 Authors' Addresses .............................................. 36
1. 序論と動機… 3 2. 部分的な注文配送… 4 2.1 例1: リモートデータベース… 4 2.2 例2: マルチメディア… 8 2.3 例3: ウィンドウスクリーンはリフレッシュします… 9 2.4の潜在的貯蓄… 10 3. 信頼性対オーダー… 12 3.1 信頼性は属します… 13 4. 部分的なオーダー接続… 15 4.1 接続設立… 16 4.2データ伝送… 19 4.2 .1送付者… 22 4.2 .2受信機… 25 5. 部分的なオーダーサービスを定量化して、比較します… 30 6. 将来の方向… 31 7. 概要… 32 8. 参照… 34 セキュリティ問題… 35人の作者のアドレス… 36
Connolly, Amer & Conrad [Page 2] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[2ページ]RFC1693: 部分的なオーダーサービス1994年11月
1. Introduction and motivation
1. 序論と動機
Current applications that need to communicate objects (i.e., octets, packets, frames, protocol data units) usually choose between a fully ordered service such as that currently provided by TCP and one that does not guarantee any ordering such as that provided by UDP. A similar "all-or-nothing" choice is made for object reliability - reliable connections which guarantee all objects will be delivered verses unreliable data transport which makes no guarantee. What is more appropriate for some applications is a partial order and/or partial reliability service where a subset of objects being communicated must arrive in the order transmitted, yet some objects may arrive in a different order, and some (well specified subset) of the objects may not arrive at all.
通常、オブジェクト(すなわち、八重奏、パケット(フレーム)はデータ単位について議定書の中で述べる)を伝える必要がある現在のアプリケーションが現在UDPによって提供されたそれなどのようにどんな注文も保証しないTCPともの時までに提供されているそれなどの完全に命令されたサービスを選びます。 A同様である、「オール、無、」 オブジェクトの信頼性のために選択をします--オブジェクトが提供されるすべてが保証を全くしない頼り無いデータ伝送の作詩をするのを保証する頼もしい接続。 いくつかのアプリケーションには、より適切なことは部分的な注文です、そして、伝えられるオブジェクトの部分集合がオーダーに到達しなければならないのを部分的な信頼性のサービスは伝わりました、そして、しかし、いくつかのオブジェクトが異なったオーダーに届くかもしれません、そして、いくつかのオブジェクト(よく指定された部分集合)は全く届かないかもしれません。
One motivating application for a partial order service is the emerging area of multimedia communications. Multimedia traffic is often characterized either by periodic, synchronized parallel streams of information (e.g., combined audio-video), or by structured image streams (e.g., displays of multiple overlapping and nonoverlapping windows). These applications have a high degree of tolerance for less-than-fully-ordered data transport as well as data loss. Thus they are ideal candidates for using a partial order, partial reliability service. In general, any application which communicates parallel and/or independent data structures may potentially be able to profit from a partial order service.
部分的なオーダーサービスの申請を動機づける1つはマルチメディア通信の現れている領域です。 情報の周期的で、連動している平行なストリーム(例えば、結合したオーディオのビデオ)、または構造化されたイメージストリーム(例えば、複数の重なって「非-重な」ることの窓のディスプレイ)によってマルチメディアトラフィックはしばしば特徴付けられます。 これらのアプリケーションには、データの損失と同様に完全にそれほど命令されないというわけではないデータ伝送のための高度合いの寛容があります。 したがって、彼らは部分的な注文、部分的な信頼性のサービスを利用する理想的な候補です。 一般に、平行な、そして/または、独立しているデータ構造を伝えるどんなアプリケーションも潜在的に部分的なオーダーサービスから利益を得ることができるかもしれません。
A second application that could benefit from a partial order service involves remote or distributed databases. Imagine the case where a database user transmitting queries to a remote server expects objects (or records) to be returned in some order, although not necessarily total order. For example a user writing an SQL data query might specify this with the "order by" clause. There exist today a great number of commercial implementations of distributed databases which utilize - and thus are penalized by - an ordered delivery service.
サービスがかかわる部分的なオーダーのリモートな状態で利益を得ることができた2番目のアプリケーションか分散データベース。 リモートサーバに質問を伝えるデータベース利用者が、オブジェクト(または、記録)が何らかのオーダーで返されると予想するケースを想像してください、必ず総オーダーであるというわけではありませんが。 例えば、SQLデータ質問を書いているユーザは「注文してください」という節でこれを指定するかもしれません。 分散データベースのかなりの数の商業実装が今日存在する、どれ、利用して、その結果、罰せられるか、命令されたデリバリ・サービス。
Currently these applications must use and pay for a fully ordered/fully reliable service even though they do not need it. The introduction of partial services allows applications to lower the demanded quality of service (QOS) of the communication assuming that such a service is more efficient and less costly. In effect, a partial order extends the service level from two extremes - ordered and unordered - to a range of discreet values encompassing both of the extremes and all possible partial orderings in between. A similar phenomenon is demonstrated in the area of reliability.
現在の、これらのアプリケーションは、完全に信頼できるサービスを利用して、彼らはそれを必要としませんが、完全に規則正しい/のために支払わなければなりません。 間引き運転の導入は、そのようなサービスが、より効率的であって、それほど高価でないと仮定しながらコミュニケーションの要求されたサービスの質(QOS)を下げるためにアプリケーションを許容します。 事実上、部分的なオーダーは中間で注文されて順不同の2つの極端から極端の両方を取り囲むさまざまな慎重な値と可能な部分的なすべての受注業務までサービスレベルを広げています。 同様の現象は信頼性の領域に示されます。
Connolly, Amer & Conrad [Page 3] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[3ページ]RFC1693: 部分的なオーダーサービス1994年11月
It is worth mentioning that a TCP implementation providing a partial order service, as described here, would be able to communicate with a non-partial order implementation simply by recognizing this fact at connection establishment - hence this extension is backward compatible with earlier versions of TCP. Furthermore, it is conceivable for a host to support the sending-half (or receiving- half) of a partial order connection alone to reduce the size of the TCP as well as the effort involved in the implementation. Similar "levels of conformance" have been proposed in other internet extensions such as [Dee89] involving IP multicasting.
ここで説明されるように部分的なオーダーサービスを提供するTCP実装が非部分的なオーダー実装で単にコネクション確立でこの事実を認識することによって交信できると言及する価値があります--したがって、この拡大はTCPの以前のバージョンと互換性があった状態で後方です。 その上、ホストが実装にかかわる取り組みと同様にTCPのサイズを減少させるために単独の部分的なオーダー接続の発信半分(半分を受け取って)をサポートするのが想像できます。 同様の「順応のレベル」はIPマルチキャスティングにかかわる[Dee89]などの他のインターネット拡大で提案されました。
This RFC proceeds as follows. The principles of partial order delivery, published in [ACCD93a], are presented in Section 2. The notion of partial reliability, published in [ACCD93b], is introduced in Section 3 followed by an explanation of "reliability classes". Then, the practical issues involved with setting up and maintaining a Partial Order Connection (POC) within a TCP framework are addressed in Section 4 looking first at connection establishment, and then discussing the sender's role and the receiver's role. Section 5 provides insights into the expected performance improvements of a partial order service over an ordered service and Section 6 discusses some future directions. Concluding remarks are given in Section 7.
このRFCは以下の通り続きます。 [ACCD93a]で発行された部分的な注文配送の原則はセクション2に提示されます。 [ACCD93b]で発行された部分的な信頼性の概念は「信頼性のクラス」に関する説明があとに続いたセクション3で紹介されます。 そして、実用的な問題はTCPフレームワークの中の最初に、コネクション確立を見るセクション4で扱われて、次に送付者の役割と受信機の役割について議論する(POC)にPartial Order Connectionをセットアップして、維持するのにかかわりました。 セクション5は部分的なオーダーサービスオーバーの予想された性能改良への洞察に命令されたサービスを提供します、そして、セクション6はいくつかの将来の方向について議論します。 セクション7で結びの言葉を与えます。
2. Partial Order Delivery
2. 部分的な注文配送
Partial order services are needed and can be employed as soon as a complete ordering is not mandatory. When two objects can be delivered in either order, there is no need to use an ordered service that must delay delivery of the second one transmitted until the first arrives as the following examples demonstrate.
完全な注文が義務的でないとすぐに、部分的なオーダーサービスを必要であり、使うことができます。 オーダーで2個のオブジェクトを提供できるとき、以下の例が示すように1番目が到着するまで伝えられた2番目のものの配送を遅らせなければならない命令されたサービスを利用する必要は全くありません。
2.1 Example 1: Remote Database
2.1 例1: リモートデータベース
Simpson's Sporting Goods (SSG) has recently installed a state-of-
the-art enterprise-wide network. Their first "network application"
is a client/server SQL database with the following four records,
numbered {1 2 3 4} for convenience:
シンプソンのSporting Goods(SSG)が最近状態をインストールした、-、-、-、芸術、企業全体のネットワーク。 それらの最初の「ネットワーク応用」は以下の4つの記録があるクライアント/サーバSQLデータベースです、便宜のための番号付の1 2 3 4:
SALESPERSON LOCATION CHARGES DESCRIPTION
------------- ----------------- --------- -----------------
1 Anderson Atlanta, GA $4,200 Camping Gear
2 Baker Boston, MA $849 Camping Gear
3 Crowell Boston, MA $9,500 Sportswear
4 Dykstra Wash., DC $1,000 Sportswear
販売員位置は記述を請求します。------------- ----------------- --------- ----------------- 1 アンダーソン・アトランタ(ジョージア)・4,200ドルのキャンプ用具2ベイカー・ボストン、MA849ドルのキャンプ用具3クロウェル・ボストン(MA)の9,500ドルのスポーツウェア4のディクトラワシントン州(DC)の1,000ドルのスポーツウェア
SSG employees running the client-side of the application can query the database server from any location in the enterprise net using standard SQL commands and the results will be displayed on their
アプリケーションのクライアント側を実行するSSG従業員が企業ネットにおけるどんな位置からもコマンドと結果が表示される標準のSQLを使用することでデータベースサーバーについて質問できる、それら
Connolly, Amer & Conrad [Page 4] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[4ページ]RFC1693: 部分的なオーダーサービス1994年11月
screen. From the employee's perspective, the network is completely reliable and delivers data (records) in an order that conforms to their SQL request. In reality though, it is the transport layer protocol which provides the reliability and order on top of an unreliable network layer - one which introduces loss, duplication, and disorder.
上映します。 従業員の見解から、ネットワークは、完全に信頼できて、彼らのSQL要求に従うオーダーにおけるデータ(記録)を提供します。 もっとも、それはほんとうは、頼り無いネットワーク層の上で信頼性と注文を提供するトランスポート層プロトコルです--損失、複製、および混乱を導入するもの。
Consider the four cases in Figure 1 - in the first query (1.a), ordered by SALESPERSON, the records have only one acceptable order at the destination, 1,2,3,4. This is evident due to the fact that there are four distinct salespersons. If record 2 is received before record 1 due to a network loss during transmission, the transport service can not deliver it and must therefore buffer it until record 1 arrives. An ordered service, also referred to as a virtual circuit or FIFO channel, provides the desired level of service in this case.
図1、最初の質問における4つのケースを考えてください。(SALESPERSONによって注文された1.a)、目的地、1のときに、記録には1つの許容できるオーダーしかない、2、3、4。 これは4人の異なった販売員がいるという事実のために明白です。 記録的な2がトランスミッションの間のネットワークの損失への記録的な1つの支払われるべきものの前に受け取られているなら、輸送サービスは、それを提供できないで、したがって、記録的な1が到着するまで、それをバッファリングしなければなりません。 また、仮想の回路か先入れ先出し法チャンネルと呼ばれた命令されたサービスはこの場合必要なレベルのサービスを提供します。
At the other extreme, an unordered service is motivated in Figure 1.d where the employee has implicitly specified that any ordering is valid simply by omitting the "order by" clause. Here any of 4! = 24 delivery orderings would satisfy the application, or from the transport layer's point of view, all records are immediately deliverable as soon as they arrive from the network. No record needs to buffered should it arrive out of sequential order. As notation, 4 ordered objects are written 1;2;3;4 and 4 unordered objects are written using a parallel operator: 1||2||3||4.
それとは正反対に、順不同のサービスは従業員がどんな注文も単に「注文してください」という節を省略することによって有効であるとそれとなく指定した図1.dで動機づけられています。 ここ、4のいずれも! = 24の配送受注業務がアプリケーションを満たすだろうか、トランスポート層の観点から、すべての記録がすぐにである、提出物、同じくらいすぐ、それらのように、ネットワークから到着してください。 連続したオーダーから到着するならバッファリングされて、どんな記録も、必要がありません。 記法として、4個の命令されたオブジェクトが書かれた1です; 2;3、4と4個の順不同のオブジェクトが平行なオペレータを使用することで書かれています: 1||2||3||4.
Figures 1.b and 1.c demonstrate two possible partial orders that permit 2 and 4 orderings respectively at the destination. Using the notation just described, the valid orderings for the query in 1.b are specified as 1;(2||3);4, which is to say that record 1 must be delivered first followed by record 2 and 3 in either order followed by record 4. Likewise, the ordering for 1.c is (1||2);(3||4). In these two cases, an ordered service is too strict and an unordered service is not strict enough.
数字の1.bと1.cは目的地にそれぞれ2を可能にする2つの可能な部分的な注文と4つの受注業務を示します。 ただ説明された記法を使用する1.bでの質問のための有効な受注業務が1として指定されます。; (2| | 3); 4 どれが、最初に記録的な1を提供しなければならないと言うことになっているかが記録的な4があとに続いたオーダーで記録を2と3に続けました。 1.cのための同様に注文はそうです。(1| | 2); (3| | 4)。 これらの2つの場合では、命令されたサービスは厳し過ぎます、そして、順不同のサービスは十分厳しくはありません。
Connolly, Amer & Conrad [Page 5] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[5ページ]RFC1693: 部分的なオーダーサービス1994年11月
+-----------------------------------------------------------------+
| SELECT SALESPERSON, LOCATION, CHARGES, DESCRIPTION |
| FROM BILLING_TABLE |
| |
| SALESPERSON LOCATION CHARGES DESCRIPTION |
| ------------- ----------------- --------- --------------- |
| 1 Anderson Atlanta, GA $4,200 Camping Gear |
| 2 Baker Boston, MA $849 Camping Gear |
| 3 Crowell Boston, MA $9,500 Sportswear |
| 4 Dykstra Wash., DC $1,000 Sportswear |
+=================================================================+
|a - ORDER BY SALESPERSON |
| |
| 1,2,3,4 1,2,3,4 |
| |
| Sender -----------> NETWORK --------------> Receiver |
| (1 valid ordering) |
+-----------------------------------------------------------------+
|b - ORDER BY LOCATION |
| 1,2,3,4 |
| 1,2,3,4 1,3,2,4 |
| |
| Sender -----------> NETWORK --------------> Receiver |
| (2 valid orderings) |
+-----------------------------------------------------------------+
|c - ORDER BY DESCRIPTION |
| 1,2,3,4 |
| 2,1,3,4 |
| 1,2,3,4 1,2,4,3 |
| 2,1,4,3 |
| |
| Sender -----------> NETWORK --------------> Receiver |
| (4 valid orderings) |
+-----------------------------------------------------------------+
|d - (no order by clause) |
| 1,2,3,4 |
| 1,2,4,3 |
| 1,2,3,4 ... |
| 4,3,2,1 |
| |
| Sender -----------> NETWORK --------------> Receiver |
| (4!=24 valid orderings) |
+-----------------------------------------------------------------+
Figure 1: Ordered vs. Partial Ordered vs. Unordered Delivery
+-----------------------------------------------------------------+ | 販売員、位置、料金、記述を選択してください。| | 支払い_テーブルから| | | | 販売員位置の料金記述| | ------------- ----------------- --------- --------------- | | 1 アンダーソン・アトランタ(ジョージア)の4,200ドルのキャンプ用具| | 2 ベイカー・ボストン(MA)の849ドルのキャンプ用具| | 3のクロウェル・ボストン(MA)の9,500ドルのスポーツウェア| | 4のディクトラワシントン州(DC)の1,000ドルのスポーツウェア| +=================================================================+ |a--販売員によるオーダー| | | | 1,2,3,4 1,2,3,4 | | | | 送付者----------->ネットワーク-------------->受信機| | (1の有効な注文) | +-----------------------------------------------------------------+ |b--ORDER BY LOCATION| | 1,2,3,4 | | 1,2,3,4 1,3,2,4 | | | | 送付者----------->ネットワーク-------------->受信機| | (2つの有効な受注業務) | +-----------------------------------------------------------------+ |c--ORDER BY DESCRIPTION| | 1,2,3,4 | | 2,1,3,4 | | 1,2,3,4 1,2,4,3 | | 2,1,4,3 | | | | 送付者----------->ネットワーク-------------->受信機| | (4つの有効な受注業務) | +-----------------------------------------------------------------+ |d--(節によるオーダーがありません)| | 1,2,3,4 | | 1,2,4,3 | | 1,2,3,4 ... | | 4,3,2,1 | | | | 送付者----------->ネットワーク-------------->受信機| | (24の有効な4!=受注業務) | +-----------------------------------------------------------------+ 図1: 部分的な順不同のに対して命令された配送に対して注文します。
It is vital for the transport layer to recognize the exact requirements of the application and to ensure that these are met. However, there is no inherent need to exceed these requirements; on
トランスポート層が、アプリケーションの正確な要件を認めて、これらが会われるのを保証するのは、重大です。 しかしながら、これらの要件を超える固有の必要は全くありません。 オン
Connolly, Amer & Conrad [Page 6] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[6ページ]RFC1693: 部分的なオーダーサービス1994年11月
the contrary, by exceeding these requirements unecessary resources are consumed. This example application requires a reliable connection - all records must eventually be delivered - but has some flexibility when it comes to record ordering.
反対であり、これらの要件を超えていることによって、unecessaryリソースは消費されます。 この例のアプリケーションには、結局すべての記録を送らなければならないという頼もしい接続を必要としますが、注文を記録するようになるとき、何らかの柔軟性があります。
In this example, each query has a different partial order. In total, there exist 16 different partial orders for the desired 4 records. For an arbitrary number of objects N, there exist many possible partial orders each of which accepts some number of valid orderings between 1 and N! (which correspond to the ordered and unordered cases respectively). For some classes of partial orders, the number of valid orderings can be calculated easily, for others this calculation is intractable. An in-depth discussion on calculating and comparing the number of orderings for a given partial order can be found in [ACCD93a].
この例では、各質問は異なった部分的なオーダーを持っています。 合計で、必要な4つの記録のための16の異なった部分的な命令が存在しています。 物Nの特殊活字の数字のために、多くのそれのそれぞれが何らかの数の有効な受注業務を1とNの間に受け入れる可能な部分的な命令が存在しています! (それぞれ注文されて順不同のケースに対応します。) 数人のクラスの部分的な注文において、有効な受注業務の数について容易に計算できて、他のものにとって、この計算は手に負えません。 [ACCD93a]で与えられた部分的なオーダーのために受注業務の数を計算して、比較するのと徹底的な議論を見つけることができます。
Connolly, Amer & Conrad [Page 7] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[7ページ]RFC1693: 部分的なオーダーサービス1994年11月
2.2 Example 2: Multimedia
2.2 例2: マルチメディア
A second example application that motivates a partial order service is a multimedia broadcast involving video, audio and text components. Consider an extended presentation of the evening news - extended to include two distinct audio channels, a text subtitle and a closed- captioned sign language video for the hearing impaired, in addition to the normal video signal, as modeled by the following diagram.
部分的なオーダーサービスを動機づける2番目の例のアプリケーションはビデオ、オーディオ、およびテキストコンポーネントにかかわるマルチメディア放送です。 2つの異なった音声チャンネル、テキストを含むように拡張している晩のニュースの拡張プレゼンテーションが字幕をつけて、公聴会のための閉じている見出しをつけられた手話ビデオが損なったと考えてください、正常なビデオ信号に加えて、以下のダイヤグラムでモデル化されるように。
(left audio) (right audio)
+------+ +------+
| ++++ | | ++++ |
| ++++ | | ++++ |
+------+ +------+
===================================================
I +---------------+I
I | |I
I | (hand signs) |I
I | |I
I +---------------+I
I I
I I
I (Main Video) I
I I
I I
I I
I I
I +------------------------------------------+ I
I | (text subtitle) | I
I +------------------------------------------+ I
I I
===================================================
Figure 2: Multimedia broadcast example
(オーディオに残されます) (右のオーディオ)+------+ +------+ | ++++ | | ++++ | | ++++ | | ++++ | +------+ +------+ =================================================== I+---------------+ I I| |I I| (手のサイン) |I I| |I I+---------------+ I I I I I I(メインビデオ)I I I I I I I I I I+------------------------------------------+ I I| (テキストが字幕をつける、) | I I+------------------------------------------+ I I I=================================================== 図2: マルチメディア放送の例
The multimedia signals have differing characteristics. The main video signal may consist of full image graphics at a rate of 30 images/sec while the video of hand signs requires a lower quality, say 10 images/sec. Assume the audio signals are each divided into 60 sound fragments/sec and the text object each second consists of either (1) new text, (2) a command to keep the previous second of text, or (3) a command for no subtitle.
マルチメディア信号には、異なった特性があります。 手のサインのビデオがやや劣る品質を必要としている間、メインビデオ信号は30イメージ/秒の速度で完全なイメージグラフィックスから成るかもしれなくて、10イメージ/秒を言ってください。 音声信号がそれぞれ60音の断片/秒と各2番目が(2) (1) 新しいテキスト、テキストの前の2番目を保つコマンドか(3) コマンドのどちらかから成るテキストオブジェクトに分割されると仮定してください。いいえは字幕をつけます。
During a one-second interval of the broadcast, a sender transmits 30 full-motion video images, 10 closed-captioned hand sign images, 60 packets of a digitized audio signal for each of the audio streams and a single text packet. The following diagram then might represent the characteristics of the multimedia presentation in terms of the media types, the number of each, and their ordering. Objects connected by a
放送の2分の1の間隔の間、送付者は30のフルモーションビデオ画像、10の閉じられて見出しをつけられた手のサインイメージ、それぞれのオーディオストリームと単一のテキストパケットのためのデジタル化している音声信号の60のパケットを伝えます。 そして、以下のダイヤグラムはメディアタイプ、それぞれの数、および彼らの注文でマルチメディアを使ったプレゼンテーションの特性を表すかもしれません。 aによって接続された物
Connolly, Amer & Conrad [Page 8] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[8ページ]RFC1693: 部分的なオーダーサービス1994年11月
horizontal line must be received in order, while those in parallel have no inherent ordering requirement.
オーダーで水平な台詞を受けなければなりませんが、平行なものには、どんな固有の注文要件もありません。
+----------------------------------------------------------------------+
| |
| |-o-|-o-|-o-|-o-|-o-|-o-|-o-|-o-|-o-...-o-|-o-|-o-| right audio |
| | | | | | | | | | | | | (60/sec) |
| | | | | | | | | | | | | |
| |-o-|-o-|-o-|-o-|-o-|-o-|-o-|-o-|-o-...-o-|-o-|-o-| left audio |
| | | | | | | | (60/sec) |
| | | | | | | | |
| |---o---|---o---|---o---|---o---|---...---|---o---| normal video |
| | | | (30/sec) |
| | | | |
| |-----------o-----------|--------o--...--------o--| hand signs |
| | | (10/sec) |
| | | |
| |-----------------------------o-----...-----------| text |
| | | (1/sec) |
| |
+----------------------------------------------------------------------+
Figure 3: Object ordering in multimedia application
+----------------------------------------------------------------------+ | | | |-o-|-o-|-o-|-o-|-o-|-o-|-o-|-o-|-o-...-o-|-o-|-o-| 右のオーディオ| | | | | | | | | | | | | | (60/秒) | | | | | | | | | | | | | | | | |-o-|-o-|-o-|-o-|-o-|-o-|-o-|-o-|-o-...-o-|-o-|-o-| オーディオに残されます。| | | | | | | | | (60/秒) | | | | | | | | | | | |---o---|---o---|---o---|---o---|---...---|---o---| 正常なビデオ| | | | | (30/秒) | | | | | | | |-----------o-----------|--------o--...--------o--| 手のサイン| | | | (10/秒) | | | | | | |-----------------------------o-----...-----------| テキスト| | | | (1/秒) | | | +----------------------------------------------------------------------+ 図3: マルチメディア応用を入るように命じて、反対してください。
Of particular interest to our discussion of partial ordering is the fact that, while objects of a given media type generally must be received in order, there exists flexibility between the separate "streams" of multimedia data (where a "stream" represents the sequence of objects for a specific media type). Another significant characteristic of this example is the repeating nature of the object orderings. Figure 3 represents a single, one-second, partial order snapshot in a stream of possibly thousands of repeating sequential periods of communication.
特定では、私たちの順序の議論への関心はオーダーに一般に与えられたメディアタイプの物を受け取らなければなりませんが、柔軟性が存在しているというマルチメディアデータ(「流れ」が特定のメディアタイプのために物の系列を表すところ)の別々の「流れ」の間の事実です。 この例の別の重要な特性は物の受注業務の繰り返している本質です。 図3はシングルを表します、1秒、ことによると何千回もの繰り返している連続した期間に関するコミュニケーションのストリームにおける部分的なオーダースナップ。
It is assumed that further synchronization concerns in presenting the objects are addressed by a service provided on top of the proposed partial order service. Temporal ordering for synchronized playback is considered, for example, in [AH91, HKN91].
物を提示することにおけるさらなる同期関心が提案された部分的なオーダーサービスの上で提供されたサービスで記述されると思われます。 例えば、連動している再生のための時の注文は[AH91、HKN91]で考えられます。
2.3 Example 3: Windows Screen Refresh
2.3 例3: ウィンドウスクリーンはリフレッシュします。
A third example to motivate a partial order service involves refreshing a workstation screen/display containing multiple windows from a remote source. In this case, objects (icons, still or video images) that do not overlap have a "parallel" relationship (i.e., their order of refreshing is independent) while overlapping screen objects have a "sequential" relationship and should be delivered in order. Therefore, the way in which the windows overlap induces a partial order.
部分的なオーダーサービスを動機づける3番目の例は、リモートソースから連窓を含むワークステーションスクリーン/表示をリフレッシュすることを伴います。 この場合、重ならない物(アイコン、スチール写真またはビデオ画像)は重なっているスクリーン物を「連続した」関係を持って、整然とした状態で届けるべきである間、「平行な」関係(すなわち、彼らのリフレッシュの注文は独立している)を持っています。 したがって、窓が重なる方法は部分的なオーダーを引き起こします。
Connolly, Amer & Conrad [Page 9] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[9ページ]RFC1693: 部分的なオーダーサービス1994年11月
Consider the two cases in Figure 4. A sender wishes to refresh a
remote display that contains four active windows (objects) named {1 2
3 4}. Assume the windows are transmitted in numerical order and the
receiving application refreshes windows as soon as the transport
service delivers them. If the windows are configured as in Figure
4a, then there exist two different orderings for redisplay, namely
1,2,3,4 or 1,3,2,4. If window 2 is received before window 1, the
transport service cannot deliver it or an incorrect image will be
displayed. In Figure 4b, the structure of the windows results in six
possible orderings - 1,2,3,4 or 1,3,2,4 or 1,3,4,2 or 3,4,1,2 or
3,1,4,2 or 3,1,2,4.
図4における2つのケースを考えてください。 送付者は1 2 3 4という4つのアクティブウィンドウ(物)を含むリモート表示をリフレッシュしたがっています。 窓が番号順に伝えられて、輸送サービスがそれらを渡すとすぐに、受信アプリケーションが窓をリフレッシュすると仮定してください。 窓が図4aのように構成されるなら、すなわち、再表示のための2つの異なった受注業務、1、2、3、4または1、3、2、4が存在しています。 窓1の前に窓2を受け取るなら、輸送サービスがそれを届けることができませんか、または不正確なイメージを表示するでしょう。 図4bでは、窓の構造は6つの可能な受注業務をもたらします--1、2、3、4 1、3、2、4 1、3、4、2 3、4、1、2 3、1、4、2または3、1、2、4。
+================================+============================+
|a +-----------+ |b +----------+ |
| | 1 | | | 1 | |
| | | | | +----------+ |
| +---------+ +----------+ | +-----| 2 | |
| | 2 |----| 3 | | | | |
| | +-----------+ | | +----------+ |
| | | 4 | | | +----------+ |
| +-----| |-------+ | | 3 | |
| | | | | +----------+ |
| +-----------+ | +------| 4 | |
| | | | |
| | +----------+ |
| | |
| 1;(2||3);4 | (1;2)||(3;4) |
+================================+============================+
Figure 4: Window screen refresh
+================================+============================+ |+-----------+ |b+----------+ | | | 1 | | | 1 | | | | | | | +----------+ | | +---------+ +----------+ | +-----| 2 | | | | 2 |----| 3 | | | | | | | +-----------+ | | +----------+ | | | | 4 | | | +----------+ | | +-----| |-------+ | | 3 | | | | | | | +----------+ | | +-----------+ | +------| 4 | | | | | | | | | +----------+ | | | | | 1;(2||3);4 | (1;2)||(3;4) | +================================+============================+ 図4: 窓網戸はリフレッシュします。
2.4 Potential Savings
2.4 潜在的貯蓄
In each of these examples, the valid orderings are strictly dependent upon, and must be specified by the application. Intuitively, as the number of acceptable orderings increases, the amount of resources utilized by a partial order transport service, in terms of buffers and retransmissions, should decrease as compared to a fully ordered transport service thus also decreasing the overall cost of the connection. Just how much lower will depend largely upon the flexibility of the application and the quality of the underlying network.
それぞれに関するこれらの例では、有効な受注業務に厳密に依存していて、アプリケーションで指定しなければなりません。 また、接続の全費用を下げながらこのようにして完全に命令された輸送サービスと比べて、許容できる受注業務の数が増加するのに従って、直観的に、バッファと「再-トランスミッション」に関して部分的なオーダー輸送サービスで利用されたリソースの量は減少するべきです。 まさしくどのくらい下ろすかは主にアプリケーションの柔軟性と基本的なネットワークの品質に依存するでしょう。
As an indication of the potential for improved service, let us briefly look at the case where a database has the following 14 records.
改良されたサービスの可能性のしるしとして、簡潔に、データベースが以下の14の記録を持っているケースを調べましょう。
Connolly, Amer & Conrad [Page 10] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[10ページ]RFC1693: 部分的なオーダーサービス1994年11月
SALESPERSON LOCATION CHARGES DESCRIPTION
------------- ----------------- --------- ---------------
1 Anderson Washington $4,200 Camping Gear
2 Anderson Philadelphia $2,000 Golf Equipment
3 Anderson Boston $450 Bowling shoes
4 Baker Boston $849 Sportswear
5 Baker Washington $3,100 Weights
6 Baker Washington $2000 Camping Gear
7 Baker Atlanta $290 Baseball Gloves
8 Baker Boston $1,500 Sportswear
9 Crowell Boston $9,500 Camping Gear
10 Crowell Philadelphia $6,000 Exercise Bikes
11 Crowell New York $1,500 Sportswear
12 Dykstra Atlanta $1,000 Sportswear
13 Dykstra Dallas $15,000 Rodeo Gear
14 Dykstra Miami $3,200 Golf Equipment
販売員位置の料金記述------------- ----------------- --------- --------------- 1 450ドルのアンダーソン・ワシントン・4,200ドルのキャンプ生活Gear2アンダーソン・フィラデルフィア2,000ドルのGolf Equipment3アンダーソン・ボストンBowlingがベイカーのボストンの849ドルのSportswear5のベイカーのワシントンの3,100ドルの4Weights6ベイカー・ワシントン・2000ドルのキャンプ生活Gear7ベイカー・アトランタ290ドルのBaseball Gloves8ベイカー・ボストンに1ドル靴をはかせます; 500 スポーツウェア9のクロウェルのボストンの9,500ドルのキャンプ用具10のクロウェルのフィラデルフィアの6,000ドルの運動用の自転車11のクロウェルのニューヨークの1,500ドルのスポーツウェア12のディクトラのアトランタの1,000ドルのスポーツウェア13のディクトラのダラスの1万5000ドルのロデオギヤ14のディクトラのマイアミの3,200ドルのゴルフ用品
Using formulas derived in [ACCD93a] one may calculate the total number of valid orderings for any partial order that can be represented in the notation mentioned previously. For the case where a user specifies "ORDER BY SALESPERSON", the partial order above can be expressed as,
[ACCD93a]1で引き出された定石を使用すると、有効な受注業務の総数は以前に言及された記法で表すことができるどんな部分的なオーダーのためにも計算されるかもしれません。 ケースにおいて、ユーザがどこで「販売員によるオーダー」を指定するかを上記の部分的なオーダーを言い表すことができます。
(1||2||3);(4||5||6||7||8);(9||10||11);(12||13||14)
(1||2||3);(4||5||6||7||8);(9||10||11);(12||13||14)
Of the 14!=87,178,291,200 total possible combinations, there exist 25,920 valid orderings at the destination. A service that may deliver the records in any of these 25,920 orderings has a great deal more flexibility than in the ordered case where there is only 1 valid order for 14 objects. It is interesting to consider the real possibility of hundreds or even thousands of objects and the potential savings in communication costs.
871億7829万1200の総可能な14!=組み合わせでは、2万5920の有効な受注業務が目的地に存在しています。 これらの2万5920の受注業務のどれかにおける記録を送るかもしれないサービスは規則正しいケースより中14個の物の1つの有効な注文しかない多くの柔軟性を大いに持っています。 数百の現実に起こり得ることか何千個もの物とコミュニケーションコストにおける潜在的貯蓄を考えるのはおもしろいです。
In all cases, the underlying network is assumed to be unreliable and may thus introduce loss, duplication, and disorder. It makes no sense to put a partial order service on top of a reliable network. While the exact amount of unreliability in a network may vary and is not always well understood, initial experimental research indicates that real world networks, for example the service provided by the Internet's IP level, "yield high losses, duplicates and reorderings of packets" [AS93,BCP93]. The authors plan to conduct further experimentation into measuring Internet network unreliability. This information would say a great deal about the practical merit of a partial order service.
すべての場合では、基本的なネットワークは、頼り無いと思われて、その結果、損失、複製、および混乱を導入するかもしれません。 それは信頼できるネットワークの上に部分的なオーダーサービスを置く意味に全くなりません。 ネットワークにおける正確な量の非信頼性が、異なるかもしれなくて、いつもよく理解されているというわけではありませんが、初期の実験的研究は、本当の世界ネットワーク(例えばインターネットのIPレベルによって提供されたサービス)が「パケットの高い損失、写し、および「再-受注業務」をもたらすこと」を示します[AS93、BCP93]。 作者は、測定インターネット網非信頼性にさらなる実験を行うのを計画しています。 この情報は実用的な部分的にオーダーサービスの長所に関して多くを言うでしょう。
Connolly, Amer & Conrad [Page 11] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[11ページ]RFC1693: 部分的なオーダーサービス1994年11月
3. Reliability vs. Order
3. 信頼性対オーダー
While TCP avoids the loss of even a single object, in fact for many applications, there exists a genuine ability to tolerate loss. Losing one frame per second in a 30 frame per second video or losing a segment of its accompanying audio channel is usually not a problem. Bearing this in mind, it is of value to consider a quality of service that combines a partial order with a level of tolerated loss (partial reliability). Traditionally there exist 4 services: reliable- ordered, reliable-unordered, unreliable-ordered, and unreliable- unordered. See Figure 5. Reliable-ordered service (denoted by a single point) represents the case where all objects are delivered in the order transmitted. File transfer is an example application requiring such a service.
TCPは事実上、多くのアプリケーションのために単一の物さえの損失を避けますが、損失を黙認する本物の能力は存在しています。 通常、2番目のビデオあたり1個の30フレームの秒あたりの喪失1フレームか付随の音声チャンネルのセグメントを失うのが、問題ではありません。 これを覚えておいて、許容損失(部分的な信頼性)のレベルに部分的なオーダーを結合するサービスの質を考えるために、それには価値があります。 4つのサービスが伝統的に存在しています: 信頼できる、注文されて、信頼できて順不同の、頼り無く注文されて、頼り無い、順不同のです。 図5を参照してください。 信頼できて命令されたサービス(1ポイント指示される)は物がオーダーで届けられるすべてが伝わったケースを表します。 ファイル転送はそのようなサービスを必要とする例のアプリケーションです。
reliable-ordered reliable-unordered
| |
| |
v v
zero loss-->*---------------------------------*
min loss-->|<-- |<--
. | |
. |<-- |<--
| |
|<-- unreliable- |<-- unreliable-
RELIABILITY | ordered | unordered
|<-- |<--
| |
|<-- |<--
max loss-->| |
+-+--+--+--+--+--+--+--+--+--+--+-+
ordered partial ordered unordered
信頼できて命令される、信頼できて順不同の| | | | vに対して、損失のゼロを合わせてください-->*---------------------------------* 分、損失-->| <-- | <-- . | | . | <-- | <--、|、| | <-- 頼り無い| <-- 頼り無いRELIABILITY| 注文します。| 順不同の| <-- | <--、|、| | <-- | <-- 損失に最大限にしてください-->|、| ++--+--+--+--+--+--+--+--+--+--++が注文された、部分的である、注文、順不同の
ORDER
オーダー
Figure 5: Quality Of Service: Reliability vs. Order -
Traditional Service Types
図5: サービスの質: 信頼性対オーダー--伝統的なサービスタイプ
In a reliable-unordered service (also a single point), all objects must be delivered, but not necessarily according to the order transmitted; in fact, any order will suffice. Some transaction processing applications such as credit card verification require such a service.
(1ポイントも)あたり1つの信頼できて順不同のサービスでは、すべての物を渡しますが、注文に従って、必ず伝えなければならないというわけではありません。 事実上、どんなオーダーも十分でしょう。 クレジットカード検証などのいくつかのトランザクション処理応用がそのようなサービスを必要とします。
Unreliable-ordered service allows some objects to be lost. Those that are delivered, however, must arrive in relative order (An "unreliable" service does not necessarily lose objects; rather, it may do so without failing to provide its advertised quality of
頼り無く命令されたサービスは、いくつかの物がなくされるのを許容します。 しかしながら、渡されるものが相対オーダに到着しなければならない、(「頼り無い」サービスは必ず物をなくすというわけではありません; 提供しないで上質で広告に掲載されていて、むしろ、それはそうするかもしれません。
Connolly, Amer & Conrad [Page 12] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[12ページ]RFC1693: 部分的なオーダーサービス1994年11月
service; e.g., the postal system provides an unreliable service). Since there are varying degrees of unreliability, this service is represented by a set of points in Figure 5. An unreliable-ordered service is applicable to packet-voice or teleconferencing applications.
サービス。 例えば、システムが頼り無いサービスを提供する郵便) 非信頼性の異なった度合いがあるので、このサービスは図5の1セットの先で表されます。 頼り無く命令されたサービスはパケット声か電子会議アプリケーションに適用されます。
Finally unreliable-unordered service allows objects to be lost and delivered in any order. This is the kind of service used for normal e-mail (without acknowledgment receipts) and electronic announcements or junk e-mail.
最終的に頼り無く順不同のサービスは、物が順不同になくされていて、届けられるのを許容します。 これは正常なメール(承認領収書のない)と電子発表かジャンクメールに利用されたサービスの種類です。
As mentioned previously, the concept of a partial order expands the order dimension from the two extremes of ordered and unordered to a range of discrete possibilities as depicted in Figure 6. Additionally, as will be discussed presently, the notion of reliability is extended to allow for varying degrees of reliability on a per-object basis providing even greater flexibility and improved resource utilization.
既述のとおり、部分的なオーダーの概念は図6に表現されるように注文され順不同の2つの極端から離散的なさまざまな可能性にオーダーの重要性を広くします。 さらに、信頼性の概念は、さらに大きい柔軟性と改良されたリソース利用を提供しながら対象分類で異なった度の信頼性を考慮するために現在議論するように敷衍されます。
reliable-PO
信頼できるPO
| | | | | | | | | | | |
| | | | | | | | | | | |
v v v v v v v v v v v v
zero loss-->*---------------------------------*
min loss-->| . . . . . . . . . . . |
. | . . . . . . . . . . . |
. | . . . . . . . . . . . |
| . . . . . . |
RELIABILITY | . . . unreliable-PO . . . |
| . . . . . . . . . . . |
| . . . . . . . . . . . |
| . . . . . . . . . . . |
| . . . . . . . . . . . |
max loss-->| . . . . . . . . . . . |
+-+--+--+--+--+--+--+--+--+--+--+-+
ordered partial ordered unordered
| | | | | | | | | | | | | | | | | | | | | | | | v v v v v対v v v v vに損失のゼロを合わせてください-->*---------------------------------* 分、損失-->| . . . . . . . . . . . | . | . . . . . . . . . . . | . | . . . . . . . . . . . | | . . . . . . | 信頼性| . . . 頼り無いPO…| | . . . . . . . . . . . | | . . . . . . . . . . . | | . . . . . . . . . . . | | . . . . . . . . . . . | 損失に最大限にしてください-->| . . . . . . . . . . . | ++--+--+--+--+--+--+--+--+--+--++が注文された、部分的である、注文、順不同の
ORDER
オーダー
Figure 6: Quality Of Service: Reliability vs. Order - Partial
Order Service
図6: サービスの質: 信頼性対オーダー--部分的なオーダーサービス
3.1 Reliability Classes
3.1 信頼性のクラス
When considering unreliable service, one cannot assume that all objects are equal with regards to their reliability. This classification is reasonable if all objects are identical (e.g.,
頼り無いサービスを考えるとき、人は、すべての物がそれらの信頼性への尊敬と対等にあると仮定できません。 すべての物が同じであるならこの分類が合理的である、(例えば。
Connolly, Amer & Conrad [Page 13] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[13ページ]RFC1693: 部分的なオーダーサービス1994年11月
video frames in a 30 frame/second film). Many applications, such as multimedia systems, however, often contain a variety of object types. Thus three object reliability classes are proposed: BART-NL, BART-L, and NBART-L. Objects are assigned to one of these classes depending on their temporal value as will be show presently.
30フレーム/秒のフレームが撮影するビデオ) しかしながら、マルチメディア・システムなどの多くの応用がしばしばさまざまなオブジェクト・タイプを含みます。 したがって、3つの物の信頼性のクラスが提案されます: ふしだらな娘-NL、バード-L、およびNBART-L。 物は現在ショーのようにそれらの時の値に依存するこれらのクラスの1つに割り当てられます。
BART-NL objects must be delivered to the destination. These objects have temporal value that lasts for an entire established connection and require reliable delivery (NL = No Loss allowed). An example of BART-NL objects would be the database records in Example 2.1 or the windows in the screen refresh in Example 2.3. If all objects are of type BART-NL, the service is reliable. One possible way to assure eventual delivery of a BART-NL object in a protocol is for the sender to buffer it, start a timeout timer, and retransmit it if no ACK arrives before the timeout. The receiver in turn returns an ACK when the object has safely arrived and been delivered (BART = Buffers, ACKs, Retransmissions, Timers).
バード-NL物を送付先に届けなければなりません。 これらの目的は、全体の確立した接続のために持続する時の値を持って、信頼できる配信(どんなLossも許容しなかったNL=)を必要とします。 バード-NL物に関する例はExample2.1のデータベース・レコードであるだろうかスクリーンの窓がExample2.3でリフレッシュします。 タイプバード-NLにすべての物があるなら、サービスは信頼できます。 プロトコルでバード-NL物を最後の配送に保証する1つの可能な方法は、どんなACKもタイムアウトの前に到着しないなら、送付者がそれをバッファリングして、タイムアウトタイマを始動して、それを再送することです。 物は安全に到着して、届けたとき(バードはバッファと等しいです、ACKs、Retransmissions、Timers)、受信機は順番にACKを返します。
BART-L objects are those that have temporal value over some intermediate amount of time - enough to permit timeout and retransmission, but not everlasting. Once the temporal value of these objects has expired, it is better to presume them lost than to delay further the delivery pipeline of information. One possibility for deciding when an object's usefulness has expired is to require each object to contain information defining its precise temporal value [DS93]. An example of a BART-L object would be a movie subtitle, sent in parallel with associated film images, which is valuable any time during a twenty second film sequence. If not delivered sometime during the first ten seconds, the subtitle loses its value and can be presumed lost. These objects are buffered- ACKed-retransmitted up to a certain point in time and then presumed lost.
バード-L物はいつかの中間的時間にわたって時の値を持っているものです--タイムアウトと「再-トランスミッション」を可能にすることができるくらいには永遠ではありません。 これらの物の時の値がいったん期限が切れると、それらが無くなると推定するのはさらに情報の配送パイプラインを遅らせるより良いです。 物の有用性がいつ期限が切れたかを決めるための1つの可能性は各物が正確な時の値[DS93]を定義する情報を含むのが必要であることです。 バード-L物に関する例は関連フィルムイメージと平行して送って、映画が22番目のフィルム系列の間いつでも貴重なものに字幕をつけるということでしょう。 最初の10秒間のいつか渡されないなら字幕をつける、価値を失って、無くなると推定できます。 これらの物は、ACKedによって再送されていた状態である程度までは時間内に、バッファリングされて、次に、無くなると推定されます。
NBART-L objects are those with temporal values too short to bother timing out and retransmitting. An example of a NBART-L object would be a single packet of speech in a packetized phone conversation or one image in a 30 image/sec film. A sender transmits these objects once and the service makes a best effort to deliver them. If the one attempt is unsuccessful, no further attempts are made.
調節するのを苦しめることができないくらい不足した時の値が外にあるそれらであり、再送していますNBART-Lが、反対する。 NBART-L物に関する例はpacketized電話の会話におけるスピーチか30イメージ/秒のフィルムの1つのイメージの単一のパケットでしょう。 送付者は一度これらの物を伝えます、そして、サービスで、aはそれらを渡すためにベストエフォート型になります。 1つの試みが失敗しているなら、さらなる試みを全くしません。
An obvious question comes to mind - what about NBART-NL objects? Do such objects exist? The authors have considered the notion of communicating an object without the use of BART and still being able to provide a service without loss. Perhaps with the use of forward error correction this may become a viable alternative and could certainly be included in the protocol. However, for our purposes in this document, only the first three classifications will be considered.
明白な疑問は思い浮かびます--NBART-NL物はどうですか? そのような物は存在していますか? 作者は、損失なしでバードとまだ提供できることの使用なしで物を伝えるという概念がサービスであると考えました。 恐らく前進型誤信号訂正の使用で、これは、実行可能な代案になるかもしれなくて、確かに、プロトコルで含めることができました。 しかしながら、このドキュメントの私たちの目的のために、最初の3つの分類だけが考えられるでしょう。
Connolly, Amer & Conrad [Page 14] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[14ページ]RFC1693: 部分的なオーダーサービス1994年11月
While classic transport protocols generally treat all objects equally, the sending and receiving functions of a protocol providing partial order/partial reliability service will behave differently for each class of object. For example, a sender buffers and, if necessary, retransmits any BART-NL or BART-L objects that are not acknowledged within a predefined timeout period. On the contrary, NBART-L objects are forgotten as soon as they are transmitted.
古典的なトランスポート・プロトコルである間、一般に、等しくすべての物を扱ってください、プロトコルの送受信機能がサービスがそれぞれのクラスの物のために異なって振る舞わせる部分的なオーダー/部分的な信頼性を提供して。 そして、例えば、送付者がバッファリングする、必要なら、事前に定義されたタイムアウト時間以内に承認されないどんなバード-NLかバード-L物も再送します。 これに反して、それらが伝えられるとすぐに、NBART-L物は忘れられています。
4. Partial Order Connection
4. 部分的なオーダー接続
The implementation of a protocol that provides partial order service requires, at a minimum, (1) communication of the partial ordering between the two endpoints, and (2) dynamic evaluation of the deliverability of objects as they arrive at the receiver. In addition, this RFC describes the mechanisms needed to (3) initiate a connection, (4) provide varying degrees of reliability for the objects being transmitted, and (5) improve buffer utilization at the sender based on object reliability.
受信機に到着するときサービスが最小限、2つの終点の間の順序に関する(1)コミュニケーション、および物のデリベラビリティの(2)動的評価法で必要とする部分的なオーダーに. In添加を提供するプロトコルの実現、このRFCは(3) 接続、(4)が異なった度の信頼性を伝えられる物に供給して、(5)がバッファ利用を改良する送付者が物の信頼性に基礎づけた開始に必要であるメカニズムについて説明します。
Throughout the discussion of these issues, the authors use the generic notion of "objects" in describing the service details. Thus, one of the underlying requirements of a partial order service is the ability to handle such an abstraction (e.g., recognize object boundaries). The details of object management are implementation dependent and thus are not specified in this RFC. However, as this represents a potential fundamental change to the TCP protocol, some discussion is in order.
これらの問題の議論の間中、作者はサービスの詳細について説明する際に「物」の一般的な概念を使用します。 したがって、基本的な部分的にオーダーサービスの要件の1つはそのような抽象化を扱う能力(例えば、物の限界を認識する)です。 オブジェクト管理の細部は、実現に依存していて、その結果、このRFCで指定されません。 しかしながら、これがTCPプロトコルへの潜在的根本的変化を表すとき、何らかの議論が整然としています。
At one extreme, it is possible to consider octets as objects and require that the application specify the partial order accordingly (octet by octet). This likely would entail an inordinate amount of overhead, processing each octet on an individual basis (literally breaking up contiguous segments to determine which, if any, octets are deliverable and which are not). At the other extreme, the transport protocol could maintain object atomicity regardless of size - passing arbitrarily large data structures to IP for transmission. At the sending side of the connection this would actually work since IP is prepared to perform source fragmentation, however, there is no guarantee that the receiving IP will be able to reassemble the fragments! IP relies on the TCP max segment size to prevent this situation from occurring[LMKQ89].
1つの極端では、八重奏を物と考えて、アプリケーションがそれに従って(八重奏による八重奏)、部分的なオーダーを指定するのが必要であるのは可能です。 これはおそらく過度の量のオーバーヘッドを伴うでしょう、個別的に各八重奏を処理して(八重奏がいくらか提出物とどれがないかということであるならどれを決定するかために文字通り隣接のセグメントを終えて)。 それとは正反対に、トランスミッションのために任意に大きいデータ構造をIPに通過して、トランスポート・プロトコルはサイズにかかわらず物の最小単位を維持するかもしれません。 しかしながら、IPがソース断片化を実行するように準備されるのでこれが実際に働かせる接続の送付側面には、受信IPが断片を組み立て直すことができるという保証が全くありません! IPは、この状況が起こるのを防ぐ[LMKQ89]ためにTCP最大セグメントサイズを当てにします。
A more realistic approach given the existing IP constraints might be to maintain the current notion of a TCP max segment size for the lower-layer interface with IP while allowing a much larger object size at the upper-layer interface. Of course this presents some additional complexities. First of all, the transport layer will now have to be concerned with fragmentation/reassembly of objects larger
既存のIP規制が与えられたより現実的なアプローチは上側の層のインタフェースにおけるはるかに大きい物のサイズを許容している間、TCP最大セグメントサイズの現在の概念をIPとの下層インタフェースに維持することであるかもしれません。 もちろん、これはいくつかの追加複雑さを提示します。 まず、物の断片化/再アセンブリが、より大きい状態でトランスポート層は現在、関係がなければならないでしょう。
Connolly, Amer & Conrad [Page 15] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[15ページ]RFC1693: 部分的なオーダーサービス1994年11月
than the max segment size and secondly, the increased object sizes will require significantly more buffer space at the receiver if we want to buffer the object until it arrives in entirety. Alternatively, one may consider delivering "fragments" of an object as they arrive as long as the ordering of the fragments is correct and the application is able to process the fragments (this notion of fragmented delivery is discussed further in Section 6).
最大はサイズを区分します、そして、第二に、全体に到着するまで物をバッファリングしたいと思うなら、増加する物のサイズは受信機でかなり多くのバッファ領域を必要とするでしょう。 あるいはまた、断片の注文が正しく、アプリケーションが断片を処理できる(セクション6で、より詳しく断片化している配送のこの概念について議論します)限り、到着するので物の「断片」を渡すと考えるかもしれません。
4.1 Connection Establishment
4.1 コネクション確立
By extending the transport paradigm to allow partial ordering and reliability classes, a user application may be able to take advantage of a more efficient data transport facility by negotiating the optimal service level which is required - no more, no less. This is accomplished by specifying these variables as QOS parameters or, in TCP terminology, as options to be included in the TCP header [Pos81].
順序と信頼性のクラスを許容するために輸送パラダイムを広げることによって、ユーザアプリケーションは必要でない最適のサービスレベルを交渉することによって、より効率的なデータ伝送施設を利用できるかもしれません、おまけに。 これは、QOSパラメタとして、または、TCP用語におけるオプションとしてTCPヘッダー[Pos81]に含まれるようにこれらの変数を指定することによって、達成されます。
A TCP implementation that provides a partial order service requires the use of two new TCP options. The first is an enabling option "POC-permitted" (Partial Order Connection Permitted) that may be used in a SYN segment to request a partial order service. The other is the "POC-service-profile" option which is used periodically to communicate the service characteristics. This second option may be sent only after successful transmission and acknowledgment of the POC-permitted option.
部分的なオーダーサービスを提供するTCP実現は2つの新しいTCPオプションの使用を必要とします。 1番目は可能なオプションが、SYNセグメントに使用されるかもしれない(部分的なOrder Connection Permitted)が部分的なオーダーサービスを要求するのを「POC可能にした」ということです。 もう片方がサービスの特性を伝えるのに定期的に使用される「POCサービスプロフィール」オプションです。 POCによって可能にされたオプションのうまくいっているトランスミッションと承認の後にだけこの2番目のオプションを送るかもしれません。
A user process issuing either an active or passive OPEN may choose to include the POC-permitted option if the application can benefit from the use of a partial order service and in fact, in cases where the viability of such service is unknown, it is suggested that the option be used and that the decision be left to the user's peer.
アプリケーションが部分的なオーダーサービスの使用の利益を得ることができるなら、アクティブであるか受け身のオープンを発行するユーザ・プロセスは、POCによって可能にされたオプションを含んでいるのを選ぶかもしれません、そして、事実上、そのようなサービスの生存力が未知である場合では、オプションが使用されて、決定がユーザの同輩に任せることが提案されます。
For example, a multimedia server might issue a passive <SYN> with the POC-permitted option in preparation for the connection by a remote user.
例えば、マルチメディアサーバはリモート・ユーザーによる接続に備えてPOCによって可能にされたオプションで受け身の<SYN>を発行するかもしれません。
Upon reception of a <SYN> segment with the POC-permitted option, the receiving user has the option to respond with a similar POC-permitted indication or may reject a partial order connection if the application does not warrant the service or the receiving user is simply unable to provide such a service (e.g., does not recognize the POC-permitted option).
POCによって可能にされたオプションがある<SYN>セグメントのレセプションでは、受信ユーザは、同様のPOCによって可能にされた指示で反応させるオプションを持っているか、またはアプリケーションが、サービスか受信ユーザが単にそのようなサービスを提供できないのを保証しないなら、部分的なオーダー接続を拒絶するかもしれません(例えば、POCによって可能にされたオプションを認識しません)。
In the event that simultaneous initial <SYN> segments are exchanged, the TCP will initiate a partial order connection only if both sides include the POC-permitted option.
同時の初期の<SYN>セグメントを交換すると、両側がPOCによって可能にされたオプションを含んでいる場合にだけ、TCPは部分的なオーダー接続を開始するでしょう。
Connolly, Amer & Conrad [Page 16] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[16ページ]RFC1693: 部分的なオーダーサービス1994年11月
A brief example should help to demonstrate this procedure. The following notation (a slight simplification on that employed in RFC 793) will be used. Each line is numbered for reference purposes. TCP-A (on the left) will play the role of the receiver and TCP-B will be the sender. Right arrows (-->) indicate departure of a TCP segment from TCP-A to TCP-B, or arrival of a segment at B from A. Left arrows indicate the reverse. TCP states represent the state AFTER the departure or arrival of the segment (whose contents are shown in the center of the line). Liberties are taken with the contents of the segments where only the fields of interest are shown.
簡潔な例は、この手順を示すのを助けるべきです。 以下の記法(RFC793で使われたそれにおけるわずかな簡素化)は使用されるでしょう。 各線は参照目的のために付番されます。 TCP-A(左の)は受信機の役割を果たすでしょう、そして、TCP-Bは送付者になるでしょう。 TCPセグメントのTCP-AからTCP-Bまでの出発、またはA.からのBにおけるセグメントの到着を示してください。右向きの矢、(-->) Left矢は逆を示します。 TCP州は州のAFTERを表します。セグメント(コンテンツは線のセンターに示される)の出発か到着。 興味がある分野だけが示されるところでセグメントのコンテンツで無作法を取ります。
TCP-A TCP-B
TCP-A TCP-B
1. CLOSED LISTEN
1. 閉じられて、聴いてください。
2. SYN-SENT --> <CTL=SYN><POC-perm> --> SYN-RECEIVED
2. SYNによって送られた(><CTL=SYN><POC-パーマ>)>はSYN受信されました。
3. ESTABLISHED <-- <CTL=SYN,ACK><POC-perm> <-- SYN-RECEIVED
3. 確立した<(<CTL=SYN、ACK><POC-パーマ><)はSYN受信されました。
4. ESTABLISHED --> <CTL=ACK> --> ESTABLISHED
4. 設立された確立した(><CTL=ACK>)>。
Figure 7. Basic 3-Way handshake for a partial order connection
図7。 部分的なオーダー接続に、基本的な3方法の握手
In line 1 of Figure 7, the sending user has already issued a passive OPEN with the POC-permitted option and is waiting for a connection. In line 2, the receiving user issues an active OPEN with the same option which in turn prompts TCP-A to send a SYN segment with the POC-permitted option and enter the SYN-SENT state. TCP-B is able to confirm the use of a PO connection and does so in line 3, after which TCP-A enters the established state and completes the connection with an ACK segment in line 4.
図7の線1では、送付ユーザは、既にPOCによって可能にされたオプションによる受け身のオープンを発行して、接続を待っています。 線2では、受信ユーザはTCP-AがPOCによって可能にされたオプションと共にSYNセグメントを送って、SYN-SENT状態に入れるように順番にうながす同じオプションによる活発なオープンを発行します。 TCP-BはPO接続の使用を確認できて、線3でそうして、線4でACKセグメントとの関係を終了します。(その時、TCP-Aは設立された状態に入りました後)。
In the event that either side is unable to provide partial order service, the POC-permitted option will be omitted and normal TCP processing will ensue.
どちらかの側が部分的なオーダーサービスを提供できないと、POCによって可能にされたオプションは省略されるでしょう、そして、通常のTCP処理は続くでしょう。
For completeness, the authors include the following specification for both the POC-permitted option and the POC-service-profile option in a format consistent with the TCP specification document [Pos81].
完全性のために、作者はTCP仕様ドキュメント[Pos81]と一致した形式でPOCによって可能にされたオプションとPOCサービスプロフィールオプションの両方のための以下の仕様を入れます。
TCP POC-permitted Option:
TCP POCによって可能にされたオプション:
Kind: 9 Length: - 2 bytes
種類: 9の長さ: - 2バイト
+-----------+-------------+
| Kind=9 | Length=2 |
+-----------+-------------+
+-----------+-------------+ | 種類=9| 長さ=2| +-----------+-------------+
Connolly, Amer & Conrad [Page 17] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[17ページ]RFC1693: 部分的なオーダーサービス1994年11月
TCP POC-service-profile Option:
TCP POCサービスプロフィールオプション:
Kind: 10 Length: 3 bytes
種類: 10の長さ: 3バイト
1 bit 1 bit 6 bits
+----------+----------+------------+----------+--------+
| Kind=10 | Length=3 | Start_flag | End_flag | Filler |
+----------+----------+------------+----------+--------+
1ビット1ビット6ビット+----------+----------+------------+----------+--------+ | 種類=10| 長さ=3| スタート_旗| エンド_旗| フィラー| +----------+----------+------------+----------+--------+
The first option represents a simple indicator communicated between the two peer transport entities and needs no further explanation. The second option serves to communicate the information necessary to carry out the job of the protocol - the type of information which is typically found in the header of a TCP segment - and raises some interesting questions.
第1の選択は、2つの同輩輸送実体の間で伝えられた簡単なインディケータを表して、詳細な説明を全く必要としません。 2番目のオプションは、プロトコル(TCPセグメントのヘッダーで通常見つけられる情報の種類)の仕事を行うために必要情報を伝えるのに役立って、いくつかの面白い質問を提起します。
Standard TCP maintains a 60-byte maximum header size on all segments. The obvious intuition behind this rule is that one would like to minimize the amount of overhead information present in each packet while simultaneously increasing the payload, or data, section. While this is acceptable for most TCP connections today, a partial-order service would necessarily require that significantly more control information be passed between transport entities at certain points during a connection. Maintaining the strict interpretation of this rule would prove to be inefficient. If, for example, the service profile occupied a total of 400 bytes (a modest amount as will be confirmed in the next section), then one would have to fragment this information across at least 10 segments, allocating 20 bytes per segment for the normal TCP header.
標準のTCPはすべてのセグメントの60バイトの最大のヘッダーサイズを維持します。 この規則の後ろの明白な直観は1つが同時にペイロードか、データ、セクションを増加させている間各パケットの現在の頭上の情報の量を最小にしたいということです。 ほとんどのTCP接続において、これが今日許容できる間、部分的なオーダーサービスは、必ずかなり多くの制御情報が接続の間ある一定のポイントの輸送実体の間で通過されるのを必要とするでしょう。 この規則の厳しい解釈を維持するのは効率が悪いと判明するでしょう。 例えば、サービスプロフィールが合計400バイト(次が区分する確認されたコネのような穏やかな量)を占領するなら、1つは少なくとも10のセグメントの向こう側にこの情報を断片化しなければならないでしょうに、普通のTCPヘッダーのために1セグメントあたり20バイトを割り当てて。
Instead, the authors propose that the service profile be carried in the data section of the segment and that the 3-byte POC-service- profile option described above be placed in the header to indicate the presence of this information. Upon reception of such a segment, the TCP extracts the service profile and uses it appropriately as will be discussed in the following sections.
代わりに、作者は、サービスプロフィールがセグメントの資料課で運ばれて、オプションが上で説明した3バイトのPOC-サービスプロフィールがこの情報の存在を示すためにヘッダーに置かれるよう提案します。 そのようなセグメントのレセプションでは、TCPは以下のセクションで議論するようにサービスプロフィールを抜粋して、適切にそれを使用します。
The option itself, as shown here, contains two 1-bit flags necessary to handle the case where the service profile does not fit in a single TCP segment. The "Start_flag" indicates that the information in the data section represents the beginning of the service profile and the "End_flag" represents the converse. For service profiles which fit completely in a single segment, both flags will be set to 1. Otherwise, the Start_flag is set in the initial segment and the End_flag in the final segment allowing the peer entity to reconstrcut the entire service profile (using the normal sequence numbers in the segment header). The "Filler" field serves merely to complete the third byte of the option.
ここに示されるオプション自体はサービスプロフィールがただ一つのTCPセグメントをうまくはめ込まないケースを扱うのに必要な2個の1ビットの旗を含んでいます。 「始め_旗」は、資料課の情報がサービスプロフィールの始まりを表すのを示します、そして、「終わり_旗」は逆を表します。 ただ一つのセグメントを完全にうまくはめ込むサービスプロフィールにおいて、両方の旗は1に設定されるでしょう。 さもなければ、Start_旗はreconstrcutへの全体のサービスプロフィールを同輩実体に許容する最終的なセグメントで初期のセグメントとEnd_旗で設定されます(セグメントヘッダーで標準の一連番号を使用して)。 「フィラー」分野は、単にオプションの3番目のバイトを完成するのに役立ちます。
Connolly, Amer & Conrad [Page 18] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[18ページ]RFC1693: 部分的なオーダーサービス1994年11月
Note that the length of the service profile may vary during the connection as the order or reliability requirements of the user change but this length must not exceed the buffering ability of the peer TCP entity since the entire profile must be stored. The exact makeup of this data structure is presented in Section 4.2.
ユーザ変化にもかかわらず、この長さに関するオーダーか信頼度要求事項が全体のプロフィールを格納しなければならないので同輩TCP実体のバッファリング能力を超えてはいけないのに従ってサービスプロフィールの長さが接続の間異なるかもしれないことに注意してください。 このデータ構造の正確な構成はセクション4.2に提示されます。
4.2 Data Transmission
4.2データ伝送
Examining the characteristics of a partial order TCP in chronological fashion, one would start off with the establishment of a connection as described in Section 4.1. After which, although both ends have acknowledged the acceptability of partial order transport, neither has actually begun a partial order transmission - in other words, both the sending-side and the receiving-side are operating in a normal, ordered-reliable mode. For the subsequent discussion, an important distinction is made in the terms sending-side and receiving-side which refer to the data flow from the sender and that from the receiver, respectively.
年代順のファッションにおける、部分的なオーダーTCPの特性を調べて、1つはセクション4.1で説明されるように接続の設立によって始められるでしょう。 どの両端が、部分的なオーダー輸送の受容性、どちらも実際に部分的なオーダー送信を始めていません--言い換えれば、発信側と受信側の両方が標準で作動していると認めていましたが、命令されて信頼できるモードの後に。 その後の議論において、発信側で用語で大切な区別をします、そして、データを示す受信側が送付者とそれから受信機からそれぞれ流れます。
For the partial ordering to commence, the TCP must be made aware of the acceptable object orderings and reliability for both the send- side and receive-side of the connection for a given set of objects (hereafter referred to as a "period"). This information is contained in the service profile and it is the responsibility of the user application to define this profile. Unlike standard TCP where applications implicitly define a reliable, ordered profile; with partial order TCP, the application must explicity define a profile.
順序が始まるように、TCPを両方において許容できる物の受注業務と信頼性を知るようにしなければならない、当然のことのための接続に横の、そして、側を受け取っているセットの物(今後「期間」に言及される)を送ってください。 この情報はサービスプロフィールに含まれています、そして、このプロフィールを定義するのは、ユーザアプリケーションの責任です。 アプリケーションがそれとなく信頼できて、規則正しいプロフィールを定義する標準のTCPと異なって。 TCP、アプリケーションがそうしなければならない部分的なオーダーで、explicityはプロフィールを定義します。
The representation of the service profile is one of the concerns for the transport protocol. It would be useful if the TCP could encode a partial ordering in as few bits as possible since these bits will be transmitted to the destination each time the partial order changes. A matrix representation appears to be well-suited to encoding the partial order and a vector has been proposed to communicate and manage the reliability aspects of the service. Temporal values may be included within the objects themselves or may be defined as a function of the state of the connection [DS93]. Using these data structures, the complete service profile would include (1) a partial order matrix, (2) a reliability vector and (3) an object_sizes vector which represents the size of the objects in octets (see [ACCD93a,CAC93] for a discussion on alternative structures for these variables).
サービスプロフィールの表現はトランスポート・プロトコルに関する心配の1つです。 部分的なオーダーが変化するたびにこれらのビットが目的地に伝えられるのでTCPができるだけ数ビットの順序をコード化できるなら、役に立つでしょうに。 マトリクス表現は部分的なオーダーをコード化するのに十分適しているように見えて、ベクトルは、サービスの信頼性の関連事項を伝えて、管理するために提案されました。 時の値は、物自体の中に含められているか、または接続[DS93]の状態の関数と定義されるかもしれません。 (3) これらのデータ構造を使用して、完全なサービスプロフィールは(2) (1) 部分的なオーダーマトリクス、信頼性のベクトルを含んでいるでしょう、そして、物の_は八重奏(これらの変数のための代替の構造についての議論に関して見ます[ACCD93a、CAC93])における、物のサイズを表すベクトルを大きさで分けます。
Throughout this section, we use the following service profile as a running example. Shown here is a partial order matrix and graphical representation for a simple partial order with 6 objects - ((1;2)||(3;4)||5);6. In the graphical diagram, arrows (-->) denote sequential order and objects in parallel can be delivered in either
このセクション中では、私たちは走行の例として以下のサービスプロフィールを使用します。 ここに示されているのは、6個の物--(| | | | (1;2)(3;4)5); 6がある簡単な部分的なオーダーのための部分的なオーダーマトリクスとグラフ表示です。 グラフィカルなダイヤグラム、矢、(--、>)、連続したオーダーを指示してください。そうすれば、どちらかで平行な物を届けることができます。
Connolly, Amer & Conrad [Page 19] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[19ページ]RFC1693: 部分的なオーダーサービス1994年11月
order. So in this example, object 2 must be delivered after object 1, object 4 must be delivered after object 3, and object 6 must be delivered after objects 1 through 5 have all been delivered. Among the 6 objects, there are 30 valid orderings for this partial order (each valid ordering is known as a linear extension of the partial order).
注文してください。 それで、この例では、次々と物2を1届けなければなりません、そして、次々と物4を3届けなければなりません、そして、次々と、1〜5がすべて渡された物6を届けなければなりません。 6個の物の中に、この部分的なオーダーのための30の有効な受注業務があります(それぞれの有効な注文は部分的なオーダーの直線的な拡大として知られています)。
1 2 3 4 5 6
+-------------+
1 | - 1 0 0 0 1 | | | |
2 | - - 0 0 0 1 | |-->1-->|-->2-->| |
3 | - - - 1 0 1 | | | |
4 | - - - - 0 1 | |-->3-->|-->4-->|-->6-->|
5 | - - - - - 1 | | | |
6 | - - - - - - | |------>5------>| |
+-------------+ | | |
1 2 3 4 5 6 +-------------+ 1 | - 1 0 0 0 1 | | | | 2 | - - 0 0 0 1 | |-->1-->|、-->2-->|、| 3 | - - - 1 0 1 | | | | 4 | - - - - 0 1 | |-->3-->|、-->4-->|、-->6-->| 5 | - - - - - 1 | | | | 6 | - - - - - - | |------>5------>|、| +-------------+ | | |
PO Matrix PO Graph
POマトリクスPOグラフ
In the matrix, a 1 in row i of column j denotes that object i must be delivered before object j. Note that if objects are numbered in any way such that 1,2,3,...,N is a valid ordering, only the upper right triangle of the transitively closed matrix is needed [ACCD93a]. Thus, for N objects, the partial order can be encoded in (N*(N-1)/2) bits.
マトリクスで、コラムjの列iの1は、物jの前に物iを渡さなければならないのを指示します。 物が何らかの方法で付番されるならそれに注意してください、その1つ、2、3、そのような…Nが有効な注文である、移行的に閉じているマトリクスの右上の三角形だけが必要です[ACCD93a]。 したがって、N物に関して、(N*(N-1)/2)ビットで部分的なオーダーをコード化できます。
The reliability vector for the case where reliability classes are
enumerated types such as {BART-NL=1, BART-L=2, NBART-L = 3} and all
objects are BART-NL would simply be, <1, 1, 1, 1, 1, 1>. Together
with the object_sizes vector, the complete service profile is
described.
信頼性のクラスがバード-NL=1、バード-L=2、NBART-L=3などの列挙型であり、すべての物がバード-NLであるケースのための信頼性のベクトルが単にあるでしょう、<1、1、1、1、1、1>。 物と共に、_はベクトルを大きさで分けて、完全なサービスプロフィールは説明されます。
This information must be packaged and communicated to the sending TCP before the first object is transmitted using a TCP service primitive or comparable means depending upon the User/TCP interface. Once the service profile has been specified to the TCP, it remains in effect until the connection is closed or the sending user specifies a new service profile. In the event that the largest object size can not be processed by the receiving TCP, the user application is informed that the connection cannot be maintained and the normal connection close procedure is followed.
最初の物が原始的にTCPサービスを利用することで伝えられる前に、この情報を発信しているTCPにパッケージされて、伝えなければならない、さもなければ、User/TCPによる匹敵する手段は連結します。 サービスプロフィールがいったんTCPに指定されると、接続が閉じられるか、または送付ユーザが新しいサービスプロフィールを指定するまで、それは有効なままで残っています。 受信TCPが最も大きい物のサイズを処理できないなら、ユーザアプリケーションは接続を維持できないと知らされます、そして、正常な接続近い手順は従われています。
Typically, as has been described here, the service profile definition and specification is handled at the sending end of the connection, but there could be applications (such as the screen refresh) where the receiving user has this knowledge. Under these circumstances the receiving user is obliged to transmit the object ordering on the
通常、サービスプロフィール定義と仕様は接続の送信側にここで説明されるように扱われますが、利用(スクリーンとしてのそのようなものはリフレッシュする)が受信ユーザがこの知識を持っているところにあるかもしれません。 こういう事情ですから受信ユーザが物の注文を伝えるのが強いられます。
Connolly, Amer & Conrad [Page 20] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[20ページ]RFC1693: 部分的なオーダーサービス1994年11月
return side of the connection (e.g., when making the request for a screen refresh) and have the sender interpret this data to be used on the send side of the connection.
接続の側面を返してくださいといって(例えば、スクリーンを求める要求をリフレッシュさせるとき)、送付者に使用されるこのデータを解釈させてください、接続の側面を送ってください。
Requiring that the sending application specify the service profile is not an arbitrary choice. To ensure proper object identification, the receiving application must transmit the new object numbering to the sending application (not the sending transport layer). Since the sending application must receive this information in any case, it simplifies matters greatly to require that the sending application be the only side that may specify the service profile to the transport layer.
送付アプリケーションがサービスプロフィールを指定するのが必要であるのは、気紛れな選択ではありません。 適切な物の識別を確実にするために、受信アプリケーションは送付アプリケーション(送付トランスポート層でない)に新しい物の付番を伝えなければなりません。 送付アプリケーションがどのような場合でもこの情報を受け取らなければならないので、それは送付アプリケーションがサービスプロフィールをトランスポート層に指定するかもしれない唯一の側であることが必要であるように件を大いに簡素化します。
Consider now the layered architecture diagram in Figure 8 and assume that a connection already is established. Let us now say that UserA specifies the service profile for the sending-side of the connection via its interface with TCP-A. TCP-A places the profile in the header of one or more data packets (depending upon the size of the service profile, the profile may require several packets), sets the POC- service-profile option and passes it to IP for transmission over the network. This packet must be transmitted reliably, therefore TCP-A buffers it and starts a normal retransmit timer. Subsequently, the service profile arrives at the destination node and is handed to TCP-B (as indicated by the arrows in Figure 8). TCP-B returns an acknowledgment and immediately adopts the service profile for one direction of data flow over the connection. When the acknowledgment arrives back at TCP-A, the cycle is complete and both sides are now able to use the partial order service.
今、図8の階層化アーキテクチャダイヤグラムを考えてください、そして、接続が既に確立されると仮定してください。 現在、UserAがインタフェースを通したTCP-Aがある接続の発信側面のためのサービスプロフィールを指定すると言いましょう。 TCP-Aはネットワークの上で1つ以上のデータ・パケットのヘッダーにプロフィールを置いて(サービスプロフィールのサイズによって、プロフィールはいくつかのパケットを必要とするかもしれません)、POCサービスプロフィールオプションを設定して、トランスミッションのためにそれをIPに通過します。 このパケットを確かに伝えなければならなくて、したがって、TCP-Aはそれをバッファリングして、正常な再送信タイマを始動します。 次に、サービスプロフィールは、目的地ノードに到着して、TCP-Bに手渡されます(図8の矢によって示されるように)。 TCP-Bは承認を返して、すぐに、接続に関してデータフローの一方向のためのサービスプロフィールを採用します。 承認がTCP-Aで帰って来るとき、サイクルは完了しています、そして、両側は現在、部分的なオーダーサービスを利用できます。
+--------+ +----------+
Service | UserA | | UserB |
Profile +--------+ +----------+
| | |
| | |
v | |
| +---------+ +-----------+ Service
| | TCP-A | | TCP-B | Profile
| +---------+ +-----------+ ^
| | | |
| | | |
| | | |
| +---------------------------------------+ |
v | | |
------>| ---- Service Profile -------------> |----->
+---------------------------------------+
+--------+ +----------+ サービス| UserA| | UserB| プロフィール+--------+ +----------+ | | | | | | v| | | +---------+ +-----------+ サービス| | TCP-A| | TCP-B| プロフィール| +---------+ +-----------+ ^ | | | | | | | | | | | | | +---------------------------------------+ | v| | | ------>| ---- サービスプロフィール------------->|----->+---------------------------------------+
Figure 8. Layered Communication Architecture
エイト環。 層にされた通信アーキテクチャ
Connolly, Amer & Conrad [Page 21] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[21ページ]RFC1693: 部分的なオーダーサービス1994年11月
Note that one of the TCP entities learns of the profile via its user interface, while the other TCP entity is informed via its network interface.
TCP実体のひとりがユーザーインタフェースを通してプロフィールを知っていることに注意してください、もう片方のTCP実体はネットワーク・インターフェースを通して知識がありますが。
For the remaining discussions, we will assume that a partial order profile has been successfully negotiated for a single direction of the connection (as depicted in Figure 8) and that we may now speak of a "sending TCP" (TCP-A) and a "receiving TCP" (TCP-B). As such, TCP-A refers to the partial order data stream as the "send-side" of the connection, while TCP-B refers to the same data stream as the "receive-side".
そして、残っている議論のために、私たちが部分的なオーダープロフィールが接続のただ一つの指示のために首尾よく交渉されて(図8に表現されるように)、現在「送付TCP」について話すかもしれないと思うつもりである、(TCP-a)、「受信TCP」(TCP-B。) そういうものとして、TCP-Aが部分的なオーダーデータ・ストリームを参照する、「側を発信させる、」、TCP-Bがデータが流れる同じくらいを言及する間の接続、「側を受け取る、」
Having established a partial order connection, the communicating TCPs each have their respective jobs to perform to ensure proper data delivery. The sending TCP ascertains the object ordering and reliability from the service profile and uses this information in its buffering/retransmission policy. The receiver modifications are more significant, particularly the issues of object deliverability and reliability. And both sides will need to redefine the notion of window management. Let us look specifically at how each side of the TCP connection is managed under this new paradigm.
部分的なオーダー接続を確立したので、交信しているTCPsには、それぞれ適切なデータ配送を確実にするためにする彼らのそれぞれの仕事があります。 発信しているTCPはサービスプロフィールから物の注文と信頼性を確かめて、バッファリング/「再-トランスミッション」方針でこの情報を使用します。 受信機変更は、より重要特に物のデリベラビリティと信頼性の問題です。 そして、両側は、ウィンドウ管理の概念を再定義する必要があるでしょう。 TCP接続の各側面がこの新しい発想の下で特にどう管理されるかを見ましょう。
4.2.1 Sender
4.2.1 送付者
The sender's concerns are still essentially four-fold - transmitting data, managing buffer space, processing acknowledgments and retransmitting after a time-out - however, each takes on a new meaning in a partial order service. Additionally, the management of the service profile represents a fifth duty not previously needed.
データを送って、送付者の関心はまだ本質的には4倍です、タイムアウトの後のバッファ領域、処理承認、および再送を管理して--しかしながら、それぞれが部分的なオーダーサービスにおける新しい意味を帯びます。 さらに、サービスプロフィールの経営者側は以前に必要でなかった5番目の義務を表します。
Taking a rather simplistic view, normal TCP output processing involves (1) setting up the header, (2) copying user data into the outgoing segment, (3) sending the segment, (4) making a copy in a send buffer for retransmission and (5) starting a retransmission timer. The only difference with a partial order service is that the reliability vector must be examined to determine whether or not to buffer the object and start a timer - if the object is classified as NBART-L, then steps 4 and 5 are omitted.
かなり安易な意見を取って、正常なTCP出力処理はヘッダーをセットアップしながら、(1)を伴います、(2) 外向的なセグメントに利用者データをコピーして、(3) セグメントを送って、(4) 再送信タイマーを始動して、aでのコピーに「再-トランスミッション」と(5)のためにバッファを送らせて。 部分的なオーダーサービスがある唯一の違いは物をバッファリングして、タイマを出発させるかどうか決定するために信頼性のベクトルを調べなければならないということです--物がNBART-Lとして分類されるなら、ステップ4と5は省略されます。
Buffer management at the sending end of a partial order connection is dependent upon the object reliability class and the object size. When transmitting NBART-L objects the sender need not store the data for later possible retransmission since NBART-L objects are never retransmitted. The details of buffer management - such as whether to allocate fixed-size pools of memory, or perhaps utilize a dynamic heap allocation strategy - are left to the particular system implementer.
部分的なオーダー接続の送信側のバッファ管理は、物の信頼性のクラスの扶養家族と物のサイズです。 NBART-L物を伝えるとき、NBART-L物が決して再送されないので、送付者は後の可能な「再-トランスミッション」のためのデータを格納する必要はありません。 メモリの固定サイズプールを割り当てるか、または恐らくダイナミックなヒープ割り付け戦略を利用などかなどのバッファ管理の細部は特定のシステムimplementerに残されます。
Connolly, Amer & Conrad [Page 22] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[22ページ]RFC1693: 部分的なオーダーサービス1994年11月
Acknowledgment processing remains essentially intact - acknowledgments are cumulative and specify the peer TCP's window advertisement. However, determination of this advertisement is no longer a trivial process dependent only upon the available buffer space (this is discussed further in Section 4.2.2). Moreover, it should be noted that the introduction of partial ordering and partial reliability presents several new and interesting alternatives for the acknowledgment policy. The authors are investigating several of these strategies through a simulation model and have included a brief discussion of these issues in Section 6.
承認処理は本質的には完全なままで残っています--承認は、累積していて、同輩TCPの窓の広告を指定します。 しかしながら、この広告の決断はもう利用可能なバッファ領域だけの些細な過程扶養家族(セクション4.2.2で、より詳しくこれについて議論する)ではありません。 そのうえ、順序と部分的な信頼性の導入が承認方針のためにいくつかの新しくておもしろい選択肢を提示することに注意されるべきです。 作者は、シミュレーションモデルを通してこれらのいくつかの戦略を調査していて、セクション6における、これらの問題の簡潔な議論を入れました。
The retransmit function of the TCP is entirely unchanged and is therefore not discussed further.
再送してください。TCPの機能は、完全に変わりがなく、したがって、さらに議論しないで、変わりがありません。
For some applications, it may be possible to maintain the same partial order for multiple periods (e.g., the application repeats the same partial order). In the general case, however, the protocol must be able to change the service profile during an existing connection. When a change in the service profile is requested, the sending TCP is obliged to complete the processing of the current partial order before commencing with a new one. This ensures consistency between the user applications in the event of a connection failure and simplifies the protocol (future study is planned to investigate the performance improvement gained by allowing concurrent different partial orders). The current partial order is complete when all sending buffers are free. Then negotiation of the new service profile is performed in the same manner as with the initial profile.
いくつかのアプリケーションに、複数の期間の同じ部分的な注文を維持するのは可能であるかもしれません(例えば、アプリケーションは同じ部分的なオーダーを繰り返します)。 しかしながら、一般的な場合では、既存の接続の間、プロトコルはサービスプロフィールを変えることができなければなりません。 サービスプロフィールにおける変化が要求されているとき、発信しているTCPが新しいものと共に始まる前に現在の部分的なオーダーの処理を終了するのが強いられます。 これは、接続失敗の場合、ユーザアプリケーションの間の一貫性を確実にして、プロトコルを簡素化します(今後の研究は同時発生の異なった部分的な命令を許すことによって獲得された性能改良を調査するために計画されています)。 すべての送付バッファが無料であるときに、現在の部分的なオーダーは完全です。 そして、新しいサービスプロフィールの交渉は初期のプロフィールのように同じ方法で実行されます。
Combining these issues, we propose the following simplified state machine for the protocol (connection establishment and tear down remains the same and is not show here).
これらの問題を結合して、私たちはプロトコルのために以下の簡易型の州のマシンを提案します(設立と裂け目が倒す接続は、同じままで残っていて、ここのショーではありません)。
(1)Send Request (5)Ack Arrival
+------+ +-----------+
| | | |
| V | |
+----------+ (4) New PO Profile +----------+ |
+---->| |----------------------->| PO |<-----+
| | ESTAB | | |
(2) | | | | SETUP |
Ack +-----| |<-----------------------| |<-----+
Arrival +----------+ (7)PO Setup Complete +----------+ |
^ | | |
| | | |
+------+ +---------+
(3)Timeout (6)Timeout
(1) 要求(5)Ack到着+を送ってください。------+ +-----------+ | | | | | V| | +----------+ (4) 新しいPOプロフィール+----------+ | +---->| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| ポー| <、-、-、-、--+ | | ESTAB| | | (2) | | | | セットアップ| Ack+-----| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| | <、-、-、-、--+ 到着+----------+ (7) POのセットアップの完全な+----------+ | ^ | | | | | | | +------+ +---------+ (3) タイムアウト(6)タイムアウト
Connolly, Amer & Conrad [Page 23] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[23ページ]RFC1693: 部分的なオーダーサービス1994年11月
Event (1) - User Makes a Data Send Request
=========
If Piggyback Timer is set then
cancel piggyback timer
Package and send the object (with ACK for receive-side)
If object type = (BART-L,BART-NL) then
Store the object and start a retransmit timer
If sending window is full then
Block Event (1) - allow no further send requests from user
出来事(1)--ユーザはデータに要求を送らせます。========= Piggyback Timerが当時のキャンセルを設定することであるならタイマパッケージを背負ってくださいといって、物を送ってください、(ACK、側を受け取る、)、オブジェクト・タイプが次に、ストアと等しいなら(バード-L、バード-NL)、窓を送る物とスタートa再送信タイマIfは完全であり、Block Event(1)--いいえを許容するのが次に、ユーザから要求をさらに送ります。
Event (2) - ACK Arrives
=========
If ACKed object(s) is buffered then
Release the buffer(s) and stop the retransmit timer(s)
Extract the peer TCP's window advertisement
If remote TCP's window advertisement > sending window then
Enable Event (1)
If remote TCP's window advertisement <= sending window then
Block Event (1) - allow no further send requests from user
Adjust sending window based on received window advertisement
出来事(2)--ACKは到着します。========= ACKed物がバッファリングされた当時のReleaseであるなら、バッファと次に、リモートTCPのウィンドウ広告<=送付ウィンドウBlock Event(1)--いいえを許容するなら窓の当時のEnable Event(1)を送る停止再送信タイマ抽出の同輩TCPの窓の広告のIfリモートなTCPの窓の広告>が受け取られていている窓の広告に基づく窓を送るユーザAdjustから要求をさらに送ります。
Event (3) - Retransmit Timer Expires
=========
If Piggyback Timer is set then
cancel piggyback timer
Re-transmit the segment (with ACK for receive-side)
Restart the timer
出来事(3)--再送信タイマは期限が切れます。========= Piggyback Timerによる設定当時のキャンセルがタイマを背負うということであるならセグメントをRe伝えてください、(ACK、側を受け取る、)、タイマを再開してください。
Event (4) - PO Service Profile Arrives at the User Interface
=========
Transition to the PO SETUP state
Store the Send-side PO service profile
Package the profile into 1 or more segments, setting the
POC-Service-Profile option on each
If Piggyback Timer is set then
cancel piggyback timer
Send the segment(s) (with ACK for receive-side)
Store the segment(s) and start a retransmit timer
出来事(4)--POサービスプロフィールはユーザーインタフェースに届きます。========= 変遷PO SETUP州のストアへのSend-サイドPOが1以上へのプロフィールが区分するプロフィールパッケージを調整して、各If Piggyback TimerにPOCサービスプロフィールオプションを設定するのが設定されて、次に、キャンセルがタイマSendを背負う、セグメント、(ACK、側を受け取る、)、セグメントを格納してください、そして、再送信タイマを始動してください。
Event (5) - ACK Arrival
=========
If ACKed object(s) is buffered then
Release the buffer(s) and stop the retransmit timer(s)
Extract the peer TCP's window advertisement
If all objects from previous service profile have been ACKed and
the new service profile has been ACKed then enable Event (7)
出来事(5)--ACK到着========= ACKed物がバッファリングされた当時のReleaseであるなら、再送信タイマ抽出同輩TCPの窓の広告Ifが前のサービスプロフィールからすべて反対させるバッファと停止はACKedです、そして、新しいサービスプロフィールによる次に、ACKedがEventを有効にするということでした。(7)
Connolly, Amer & Conrad [Page 24] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[24ページ]RFC1693: 部分的なオーダーサービス1994年11月
Event (6) - Retransmit Timer Expires
=========
If Piggyback Timer is set then
cancel piggyback timer
Re-transmit the segment (with ACK for receive-side)
Restart the timer
出来事(6)--再送信タイマは期限が切れます。========= Piggyback Timerによる設定当時のキャンセルがタイマを背負うということであるならセグメントをRe伝えてください、(ACK、側を受け取る、)、タイマを再開してください。
Event (7) - PO Setup Completed
=========
Transition to the ESTAB state and begin processing new service
profile
出来事(7)--終了するPOセットアップ========= ESTABへの変遷は、処理新しいサービスプロフィールを述べて、始めます。
4.2.2 Receiver
4.2.2 受信機
The receiving TCP has additional decisions to make involving object deliverability, reliability and window management. Additionally, the service profile must be established (and re-established) periodically and some special processing must be performed at the end of each period.
受信TCPには、物のデリベラビリティにかかわる、信頼性、およびウィンドウ管理を作るという追加決定があります。 さらに、定期的にサービスプロフィールを設立しなければなりません、そして、(そして、復職します)それぞれの期間の終わりに何らかの特別な処理を実行しなければなりません。
When an object arrives, the question is no longer, "is this the next deliverable object?", but rather, "is this ONE OF the next deliverable objects?" Hence, it is convenient to think of a "Deliverable Set" of objects with a partial order protocol. To determine the elements of this set and answer the question of deliverability, the receiver relies upon the partial order matrix but, unlike the sender, the receiver dynamically updates the matrix as objects are processed thus making other objects (possibly already buffered objects) deliverable as well. A check of the object type also must be performed since BART-NL and BART-L objects require an ACK to be returned to the sender but NBART-L do not. Consider our example from the previous section.
いつ物は届きますが、質問がもう「これは次の提出物の物ですか?」ですが、むしろ、「このONE OFは次の提出物の物ですか?」 したがって、部分的なオーダープロトコルがある物の「提出物のセット」を考えるのは便利です。 このセットの要素を測定して、デリベラビリティの問題に答えるために、受信機は部分的なオーダーマトリクスを当てにしますが、物がその結果、他の物(ことによると既にバッファリングされた物)をまた提出物にしながら処理されるとき、送付者と異なって、受信機はダイナミックにマトリクスをアップデートします。 バード-NLとバード-L目的が、ACKが送付者に返されるのを必要としますが、NBART-Lが実行しないので、オブジェクト・タイプのチェックも実行しなければなりません。 前項からの私たちの例を考えてください。
1 2 3 4 5 6
+-------------+
1 | - 1 0 0 0 1 | | | |
2 | - - 0 0 0 1 | |-->1-->|-->2-->| |
3 | - - - 1 0 1 | | | |
4 | - - - - 0 1 | |-->3-->|-->4-->|-->6-->|
5 | - - - - - 1 | | | |
6 | - - - - - - | |------>5------>| |
+-------------+ | | |
1 2 3 4 5 6 +-------------+ 1 | - 1 0 0 0 1 | | | | 2 | - - 0 0 0 1 | |-->1-->|、-->2-->|、| 3 | - - - 1 0 1 | | | | 4 | - - - - 0 1 | |-->3-->|、-->4-->|、-->6-->| 5 | - - - - - 1 | | | | 6 | - - - - - - | |------>5------>|、| +-------------+ | | |
PO Matrix PO Graph
POマトリクスPOグラフ
When object 5 arrives, the receiver scans column 5, finds that the object is deliverable (since there are no 1's in the column) and immediately delivers the object to the user application. Then, the
物5がすぐに届くとき、受信機は、コラム5をスキャンして、物が提出物(コラムには1が全くないので)であることがわかって、ユーザアプリケーションに物を届けます。 そして
Connolly, Amer & Conrad [Page 25] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[25ページ]RFC1693: 部分的なオーダーサービス1994年11月
matrix is updated to remove the constraint of any object whose delivery depends on object 5 by clearing all entries of row 5. This may enable other objects to be delivered (for example, if object 2 is buffered then the delivery of object 1 will make object 2 deliverable). This leads us to the next issue - delivery of stored objects.
配送が列5をすべてのエントリーから取り除くことによって物5によるどんな物の規制も取り除くためにマトリクスをアップデートします。 これは、他の物が届けられるのを可能にするかもしれません(例えば、物2がバッファリングされると、物1の配送は物を2提出物にするでしょう)。 これは私たちを次の問題に導きます--格納された物の配送。
In general, whenever an object is delivered, the buffers must be examined to see if any other stored object(s) becomes deliverable. CAC93 describes an efficient algorithm to implement this processing based on traversing the precedence graph.
一般に、物を届けるときはいつも、他の格納された物が提出物になるかどうか確認するためにバッファを調べなければなりません。 CAC93は、先行グラフを横断することに基づいてこの処理を実行するために効率的なアルゴリズムを説明します。
Consideration of object reliability is interesting. The authors have taken a polling approach wherein a procedure is executed periodically, say once every 100 milliseconds, to evaluate the temporal value of outstanding objects on which the destination is waiting. Those whose temporal value has expired (i.e. which are no longer useful as defined by the application) are "declared lost" and treated in much the same manner as delivered objects - the matrix is updated, and if the object type is BART-L, an ACK is sent. Any objects from the current period which have not yet been delivered or declared lost are candidates for the "Terminator" as the procedure is called. The Terminator's criterion is not specifically addressed in this RFC, but one example might be for the receiving user to periodically pass a list of no-longer-useful objects to TCP-B.
物の信頼性の考慮はおもしろいです。 作者は手順が定期的に実行される世論調査アプローチを取って、一度100人のミリセカンド毎を言って、目的地が待っている傑出している物の時の値を評価してください。 時の値が期限が切れた(すなわち、どれがもうアプリケーションで定義されるように役に立ちませんか)それらは、「無くなると宣言され」て、渡された物への似たり寄ったりの方法で扱われます--マトリクスをアップデートして、オブジェクト・タイプがバード-Lであるなら、ACKを送ります。 手順が呼ばれるように当期からのまだ届けないか、または無くなると申告していないどんな物も「ターミネーター」の候補です。 ターミネーターの評価基準がこのRFCに明確に記述されませんが、1つの例が定期的にリストを渡す受信ユーザのためのものであるかもしれない、 より長く役に立つ、TCP-Bへの物。
Another question which arises is, "How does one calculate the send and receive windows?" With a partial order service, these windows are no longer contiguous intervals of objects but rather sets of objects. In fact, there are three sets which are of interest to the receiving TCP one of which has already been mentioned - the Deliverable Set. Additionally, we can think of the Bufferable Set and the Receivable Set. Some definitions are in order:
起こる別の質問がそうである、「人がどのように計算するか、窓を送って、受けるか、」 部分的なオーダーサービスで、これらの窓はもう物の隣接の間隔ではなく、むしろ物のセットです。 事実上、それのTCP1が既に言及された受信には興味がある3セットがあります--Deliverable Set。 さらに、私たちはBufferable SetとReceivable Setを考えることができます。 いくつかの定義が整然としています:
Deliverable Set: objects which can be immediately passed up to
the user.
提出物はセットしました: すぐにユーザまで渡すことができる物。
Buffered Set: objects stored in a buffer awaiting delivery.
バッファリングされたセット: 配送を待ちながらバッファに格納された物。
Bufferable Set: objects which can be stored but not immediately
delivered (due to some ordering constraint).
Bufferableはセットしました: 格納されますが、すぐに格納できない物は配送されました(何らかの注文規制のため)。
Receivable Set: union of the Deliverable Set and the Bufferable
Set (which are disjoint) - intuitively, all objects which
are "receivable" must be either "deliverable" or
"bufferable".
受け取ることができるセット: Deliverable SetとBufferable Set(どれがあるかはばらばらになる)の組合--すべての「受け取ることができている」物が、直観的に、どちらかの「提出物」であるか"「バッファ-可能」する"でなければなりません。
Connolly, Amer & Conrad [Page 26] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[26ページ]RFC1693: 部分的なオーダーサービス1994年11月
The following example will help to illustrate these sets. Consider our simple service profile from earlier for the case where the size of each object is 1 MByte and the receiver has only 2 MBytes of buffer space (enough for 2 objects). Define a boolean vector of length N (N = number of objects in a period) called the Processed Vector which is used to indicate which objects from the current period have been delivered or declared lost. Initially, all buffers are empty and the PO Matrix and Processed Vector are as shown here,
以下の例は、これらのセットを例証するのを助けるでしょう。 ケースのための前からのそれぞれの物のサイズが1MByteであり、受信機がバッファ領域の2MBytesしか持っていない私たちの簡単なサービスプロフィールが(2個の物に十分)であると考えてください。 どれが当期からのどの物を届けるか、または無くなると申告したかを示すのに使用されるかをProcessed Vectorと呼ばれる長さN(Nは期間の物の数と等しいです)の論理演算子ベクトルに定義してください。 初めは、すべてのバッファが空です、そして、ここで示されるとしてPOマトリクスとProcessed Vectorがあります。
1 2 3 4 5 6
+-------------+
1 | - 1 0 0 0 1 |
2 | - - 0 0 0 1 |
3 | - - - 1 0 1 |
4 | - - - - 0 1 |
5 | - - - - - 1 | [ F F F F F F ]
6 | - - - - - - | 1 2 3 4 5 6
+-------------+
1 2 3 4 5 6 +-------------+ 1 | - 1 0 0 0 1 | 2 | - - 0 0 0 1 | 3 | - - - 1 0 1 | 4 | - - - - 0 1 | 5 | - - - - - 1 | [F F F F F F] 6| - - - - - - | 1 2 3 4 5 6 +-------------+
PO Matrix Processed Vector
POマトリクスはベクトルを処理しました。
From the PO Matrix, it is clear that the Deliverable Set =
{(1,1),(1,3),(1,5)}, where (1,1) refers to object #1 from period #1,
asssuming that the current period is period #1.
それがそれをクリアするPOマトリクスからの、ことである、Deliverable Setが等しい、(1、1) (1、3) (1、5)、(1、1)が期間#1から物#1を呼ぶところでそれをasssumingして、当期は期間#1です。
The Bufferable Set, however, depends upon how one defines bufferable objects. Several approaches are possible. The authors' initial approach to determining the Bufferable Set can best be explained in terms of the following rules,
しかしながら、Bufferable Setは人がどう「バッファ-可能」物を定義するかによります。 いくつかのアプローチが可能です。 以下の規則でBufferable Setを決定することへの作者の初期のアプローチについて説明できるのは最も良いです。
Rule 1: Remaining space must be allocated for all objects from
period i before any object from period i+1 is buffered
規則1: 期間のi+1からのどんな物もバッファリングする前にすべての物のために期間iからスペースのままで残っているのを割り当てなければなりません。
Rule 2: In the event that there exists enough space to buffer
some but not all objects from a given period, space will
be reserved for the first objects (i.e. 1,2,3,...,k)
規則2: スペースが与えられた期間からすべての物ではなく、いくつかをバッファリングできるくらい存在していると、スペースは最初の物のために予約されるでしょう。(すなわち、1、2、3、…、k)
With these rules, the Bufferable Set = {(1,2),(1,4)}, the Buffered
Set is trivially equal to the empty set, { }, and the Receivable Set
= {(1,1),(1,2),(1,3),(1,4),(1,5)}.
これらが統治されて、Bufferable Setが=である、(1、2、)(1、4)、Buffered Setが空集合と些細なことに等しい、Receivable Set、等しさ、(1、1) (1、2) (1、3) (1、4) (1、5)
Note that the current acknowledgment scheme uses the min and max values in the Receivable Set for its window advertisement which is transmitted in all ACK segments sent along the receive-side of the connection (from receiver to sender). Moreover, the "piggyback_delay" timer is still used to couple ACKs with return data (as utilized in standard TCP).
現在の承認計画がすべてのACKセグメントで伝えられる窓の広告にReceivable Setで分と最大値を使用するというメモは、接続(受信機から送付者までの)について側を受け取るのを送りました。 そのうえ、「_遅れを背負ってください」というタイマはリターンデータでまだカップルACKsまで使用されています(標準のTCPで利用されるように)。
Connolly, Amer & Conrad [Page 27] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[27ページ]RFC1693: 部分的なオーダーサービス1994年11月
Returning to our example, let us now assume that object 1 and then 3 arrive at the receiver and object 2 is lost. After processing both objects, the PO Matrix and Processed Vector will have the following updated structure,
私たちの例に戻って、現在、物1と当時3が受信機に届いて、物2が無くなると仮定しましょう。 両方の物を処理した後に、POマトリクスとProcessed Vectorには、以下のアップデートされた構造があるでしょう。
1 2 3 4 5 6
+-------------+
1 | - 0 0 0 0 0 |
2 | - - 0 0 0 1 |
3 | - - - 0 0 0 |
4 | - - - - 0 1 |
5 | - - - - - 1 | [ T F T F F F ]
6 | - - - - - - | 1 2 3 4 5 6
+-------------+
1 2 3 4 5 6 +-------------+ 1 | - 0 0 0 0 0 | 2 | - - 0 0 0 1 | 3 | - - - 0 0 0 | 4 | - - - - 0 1 | 5 | - - - - - 1 | [T F T F F F] 6| - - - - - - | 1 2 3 4 5 6 +-------------+
PO Matrix Processed Vector
POマトリクスはベクトルを処理しました。
We can see that the Deliverable Set = {(1,2),(1,4),(1,5)}, but what
should the Bufferable Set consist of? Since only one buffer is
required for the current period's objects, we have 1 Mbyte of
additional space available for "future" objects and therefore include
the first object from period #2 in both the Bufferable and the
Receivable Set,
私たちが見ることができる、Deliverable Setが等しい、(1、2) (1、4) (1、5)、Bufferable Setがことから成るはずである、-- 1つのバッファだけが当期の物に必要であるので、私たちは、「将来」の物に利用可能な追加スペースの1メガバイトを持って、したがって、BufferableとReceivable Setの両方の期間#2からの最初の物を入れます。
Deliverable Set = {(1,2),(1,4),(1,5)}
提出物のセット={(1,2),(1,4),(1,5)}
Bufferable Set = {(1,6),(2,1)}
Bufferableは=を設定します。{(1,6),(2,1)}
Buffered Set = { }
バッファリングされたセット={ }
Receivable Set = {(1,2),(1,4),(1,5),(1,6),(2,1)}
受け取ることができるセット={(1,2),(1,4),(1,5),(1,6),(2,1)}
In general, the notion of window management takes on new meaning with a partial order service. One may re-examine the classic window relations with a partial order service in mind and devise new, less restrictive relations which may shed further light on the operation of such a service.
一般に、ウィンドウ管理の概念は部分的なオーダーサービスで新しい意味を帯びます。 念頭での部分的なオーダーサービスと新しい捻出との古典的な窓の関係を再検討するかもしれません、さらにそのようなサービスの操作を解明するかもしれないそれほど制限していない関係。
Two final details: (1) as with the sender, the receiver must periodically establish or modify the PO service profile and (2) upon processing the last object in a period, the receiver must re-set the PO matrix and Processed vector to their initial states.
2つの最終的な詳細: (1) 1回の時代に最後の物を処理するとき受信機が送付者と共にPOサービスプロフィールと(2)を定期的に設立しなければならないか、または変更しなければならないとき、受信機はPOマトリクスとProcessedベクトルをそれらの初期状態にリセットしなければなりません。
Connolly, Amer & Conrad [Page 28] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[28ページ]RFC1693: 部分的なオーダーサービス1994年11月
Let us look at the state machine and pseudo-code for the receiver.
受信機のために州のマシンと中間コードを見ましょう。
(2)Data Segment Arrival (5)PO Profile fragment Arrival
+------+ +-------+
| | | |
| V (1)First PO Profile | V
+---------+ fragment arrives +---------+(6) Data Segment
+---->| |----------------------->| |<-----+ Arrival
| | ESTAB | | PO |------+
| | | | |
| | | | SETUP |<-----+
(3) +-----| |<-----------------------| |------+
Terminator+---------+ (9)PO Setup complete +---------+(7) Terminator
^ | | ^
| | | |
+------+ +------+
(4)Piggyback Timeout (8)Piggyback Timeout
(2) データSegment Arrival(5)PO Profile断片Arrival+------+ +-------+ | | | | | V(1)最初のPOプロフィール| +に対して---------+ 断片が届く、+---------+ (6) データ・セグメント+---->| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| | <、-、-、-、--+ 到着| | ESTAB| | ポー|------+ | | | | | | | | | セットアップ| <、-、-、-、--+ (3) +-----| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |------+ ターミネーター+---------+ (9) PO Setupの完全な+---------+ (7) ターミネーター^| | ^ | | | | +------+ +------+ (4)が(8)が背負うタイムアウトを背負う、タイムアウト
Event 1 - First PO Service Profile fragment arrives at network
======= interface
Transition to the PO SETUP state
Store the PO service profile (fragment)
Send an Acknowledgement of the PO service profile (fragment)
出来事1--最初のPO Service Profile断片はネットワークに届きます。======= POサービスが輪郭を描く(断片化します)PO SETUP州のストアへのインタフェースTransitionはPOサービスプロフィールのAcknowledgementを送ります。(断片)
Event 2 - Data Segment Arrival
=======
If object is in Deliverable Set then
Deliver the object
Update PO Matrix and Processed Vector
Check buffers for newly deliverable objects
If all objects from current period have been processed then
Start the next period (re-initialize data structures)
Start piggyback_delay timer to send an ACK
Else if object is in Bufferable Set then
Store the object
Else
Discard object
Start piggyback_delay timer to send an ACK
出来事2--データ・セグメント到着======= 物がDeliverable Setの当時のDeliver物のUpdate POマトリクスであって、物がBufferable Setの当時のストアにあるならProcessed Vector CheckバッファがIfが当期からすべて反対させる提出物の物が新たに処理当時のStart次の期間(データ構造を再初期化する)の始めであるのでACK Elseを送るために_ディレイタイマを背負うなら、物のElse Discard物のStartは、ACKを送るために_ディレイタイマを背負います。
Event 3 - Periodic call of the Terminator
=======
For all unprocessed objects in the current period do
If object is "no longer useful" then
Update PO Matrix and Processed Vector
If object is in a buffer then
Release the buffer
Check buffers for newly deliverable objects
出来事3--ターミネーターの周期的な呼び出し======= 当期の未加工の物がするすべてに関しては、If目的は「もう役に立たない」当時のUpdate POマトリクスです、そして、提出物が新たに反対するので、Processed Vector If物が次に、ReleaseバッファCheckがバッファリングするバッファにあります。
Connolly, Amer & Conrad [Page 29] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[29ページ]RFC1693: 部分的なオーダーサービス1994年11月
If all objects from current period have been processed
then Start the next period (re-initialize data
structures)
次の期間に当期からのすべての物が処理当時のStartであるなら(データ構造を再初期化します)
Event 4 - Piggyback_delay Timer Expires
=======
Send an ACK
Disable piggyback_delay timer
出来事4--ディレイタイマが吐き出す_を背負ってください。======= 発信、ACK Disableは_ディレイタイマを背負います。
Event 5 - PO Service Profile fragment arrives at network interface
=======
Store the PO service profile (fragment)
Send an Acknowledgement of the PO service profile (fragment)
If entire PO Service profile has been received then enable Event
(9)
出来事5--PO Service Profile断片はネットワーク・インターフェースに届きます。======= 全体のPO Serviceプロフィールを受け取ったなら、サービスプロフィール(断片)がPOサービスプロフィール(断片)のAcknowledgementを送るPOを格納してください、そして、次に、Eventを有効にしてください。(9)
Event 6 - Data Segment arrival
=======
(See event 2)
出来事6--データSegment到着======= (出来事2を見ます)
Event 7 - Periodic call of the terminator
=======
(See Event 3)
出来事7--ターミネータの周期的な呼び出し======= (出来事3を見ます)
Event 8 - Piggyback_delay Timer Expires
=======
(See Event 4)
出来事8--ディレイタイマが吐き出す_を背負ってください。======= (出来事4を見ます)
Event 9 - PO Setup Complete
=======
Transition to the ESTAB state
出来事9--POは完全な状態でセットアップします。======= ESTAB状態への変遷
Note that, for reasons of clarity, we have used a transitively closed matrix representation of the partial order. A more efficient implementation based on an adjacency list representation of a transitively reduced precedence graph results in a more efficient running time [CAC93].
私たちが明快の理由に部分的なオーダーの移行的に閉じているマトリクス表現を使用したことに注意してください。 より効率的な実現は、より効率的な実行時間[CAC93]で結果を移行的に減少している先行グラフの隣接番組リスト表現に基礎づけました。
5. Quantifying and Comparing Partial Order Services
5. 部分的なオーダーサービスを定量化して、比較します。
While ordered, reliable delivery is ideal, the existence of less- than-ideal underlying networks can cause delays for applications that need only partial order or partial reliability. By introducing a partial order service, one may in effect relax the requirements on order and reliability and presumably expect some savings in terms of buffer utilization and bandwidth (due to fewer retransmissions) and shorter overall delays. A practical question to be addressed is, "what are the expected savings likely to be?"
注文されて、信頼できる配送が理想的である間、理想より少ない基本的なネットワークの存在は部分的なオーダーか部分的な信頼性だけを必要とするアプリケーションのために遅れをきたすことができます。 部分的なオーダーサービスを導入することによって、事実上、注文と信頼性で要件を弛緩して、おそらく、バッファ利用、帯域幅(より少ない「再-トランスミッション」による)、および、より少しな総合的な遅れに関していくつかの貯蓄を予想するかもしれません。 記述されるべき実用的な質問は「予想された貯蓄は何が傾向がありますか?」ということです。
Connolly, Amer & Conrad [Page 30] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[30ページ]RFC1693: 部分的なオーダーサービス1994年11月
As mentioned in Section 2, the extent of such savings will depend largely on the quality of the underlying network - bandwidth, delay, amount and distribution of loss/duplication/disorder - as well as the flexibility of the partial order itself - specified by the PO matrix and reliability vector. If the underlying network has no loss, a partial order service essentially becomes an ordered service. Collecting experimental data to ascertain realistic network conditions is a straightforward task and will help to quantify in general the value of a partial order service [Bol93]. But how can one quantify and compare the cost of providing specific levels of service?
セクション2で言及されるように、そのような貯蓄の範囲を主に基本的なネットワークの品質に依存するでしょう--部分的なオーダー自体の柔軟性と同様にPOマトリクスと信頼性のベクトルによって指定された損失/複製/混乱の帯域幅、遅れ、量、および分配。 基本的なネットワークに損失が全くないなら、部分的なオーダーサービスは本質的には命令されたサービスになります。 現実的なネットワーク状態を確かめるために実験データを集めるのは、簡単なタスクであり、一般に、部分的にオーダーサービス[Bol93]の価値を定量化するのを助けるでしょう。 しかし、1つは、どうしたら特定のレベルのサービスを提供する費用を定量化して、比較できますか?
Preliminary research indicates that the number of linear extensions (orderings) of a partial order in the presence of loss effectively measures the complexity of that order. The authors have derived formulae for calculating the number of extensions when a partial order is series-parallel and have proposed a metric for comparing partial orders based on this number [ACCD93b]. This metric could be used as a means for charging for the service, for example. What also may be interesting is a specific head-to-head comparison between different partial orders with varying degrees of flexibility. Work is currently underway on a simulation model aimed at providing this information. And finally, work is underway on an implementation of TCP which includes partial order service.
予備調査は、事実上、損失の面前で部分的なオーダーの直線的な拡大(受注業務)の数がそのオーダーの複雑さを測定するのを示します。 作者は、部分的なオーダーが直並列であるときに拡大の数について計算するために公式を引き出して、この数[ACCD93b]に基づく部分的な命令を比較するのにおける、メートル法のaを提案しました。 これほどメートル法、例えばサービスに課金するのに手段として使用できました。 また、おもしろいかもしれないことは異なった度の柔軟性がある異なった部分的な命令での特定の大接戦の比較です。 仕事は現在、この情報を提供するのが目的とされたシミュレーションモデルで進行中です。 そして、最終的に、仕事は部分的なオーダーサービスを含んでいるTCPの実現のときに進行中です。
6. Future Direction
6. 今後の指示
In addition to the simulation and implementation work the authors are pursuing several problems related to partial ordering which will be mentioned briefly.
作者が追求しているシミュレーションと実現仕事に加えて、いくつかの問題が簡潔に言及される順序に関連しました。
An interesting question arises when discussing the acknowledgment strategy for a partial order service. For classic protocols, a cumulative ACK of object i confirms all objects "up to and including" i. But the meaning of "up to and including" with a partial order service has different implications than with an ordered service.
部分的なオーダーサービスのための承認戦略について議論するとき、面白い質問は起こります。 古典的なプロトコルのために、物iの累積しているACKはi「を含めて」すべての物を確認します。 しかし、意味、aについて部分的「を含めて」、オーダーサービスには、命令されたサービスと異なった意味があります。
Consider our example partial order, ((1;2)||(3;4)||5);6). What should a cumulative ACK of object 4 confirm? The most logical definition would say it confirms receipt of object 4 and all objects that precede 4 in the partial order, in this case, object 3. Nothing is said about the arrival of objects 1 or 2. With this alternative interpretation where cumulative ACKs depend on the partial order, the sender must examine the partial order matrix to determine which buffers can be released. In this example, scanning column 4 of the matrix reveals that object 3 must come before object 4 and therefore both object buffers (and any buffers from a previous period) can be released.
私たちの例が部分的な注文、(| | | | (1;2)(3;4)5);6)であると考えてください。 物4の累積しているACKは何を確認するはずですか? 最も論理的な定義は、部分的なオーダーで4に先行する物4とすべての物の領収書を確認すると言うでしょう、この場合、物3。 何も物1か2の到着に関して言われていません。 累積しているACKsが部分的なオーダーによるこの代替の解釈で、送付者は、どのバッファを発表できるかを決定するために部分的なオーダーマトリクスを調べなければなりません。 この例では、マトリクスに関するスキャンコラム4は、物4としたがって、物のバッファ(そして、前の期間からのどんなバッファも)の両方を放出できる前に物3が来なければならないのを明らかにします。
Connolly, Amer & Conrad [Page 31] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[31ページ]RFC1693: 部分的なオーダーサービス1994年11月
Other partial order acknowledgment policies are possible for a protocol providing a partial order service including the use of selective ACKs (which has been proposed in [JB88] and implemented in the Cray TCP [Chang93]) as well as the current TCP strategy where an ACK of i also ACKs everything <= i (in a cyclical sequence number space). The authors are investigating an ACK policy which utilizes a combination of selective and "partial-order-cumulative" acknowledgments. This is accomplished by replacing the current TCP cumulative ACK with one which has the partial order meaning as described above and augmenting this with intermittent selective ACKs when needed.
現在のTCP戦略と同様に選択しているACKs([JB88]で提案されて、クレイTCP[Chang93]で実行された)の使用を含む部分的なオーダーサービスを提供するプロトコルに、他の部分的なオーダー承認方針が可能である、どこ、ACK、i ACKsではも、<のすべてがiと等しいか(周期的な一連番号スペースで)。 そして、作者が選択することの組み合わせを利用するACK方針を調査している、「部分的なオーダー累積する、」 承認。 これは、現在のTCP累積しているACKを必要であると、間欠選択しているACKsと共にこれを上で説明されて、増大させるとして部分的なオーダー意味を持っているものに取り替えることによって、達成されます。
In another area, the notion of fragmented delivery, mentioned in the beginning of Section 4, looks like a promising technique for certain classes of applications which may offer a substantial improvement in memory utilization. Briefly, the term fragmented delivery refers to the ability to transfer less-than-complete objects between the transport layer and the user application (or session layer as the case may be). For example, a 1Mbyte object could potentially be delivered in multiple "chunks" as segments arrive thus freeing up valuable memory and reducing the delay on those pieces of data. The scenario becomes somewhat more complex when multiple "parallel streams" are considered where the application could now receive pieces of multiple objects associated with different streams.
別の領域では、セクション4の始めに言及された断片化している配送の概念がメモリ使用量における実質的な改善を提供するかもしれないあるクラスのアプリケーションのための有望なテクニックに似ています。 簡潔に、用語の断片化している配送はトランスポート層とユーザアプリケーション(または、場合によってセッション層)の間にあまり完全でない物を移す能力について言及します。 例えば、貴重なメモリを開けて、それらのデータで遅れを減少させながら複数の「塊」で潜在的に1メガバイトの物を届けて、その結果、セグメントは到着できました。 アプリケーションが現在異なった流れに関連している複数の物の断片を受けるかもしれないところで複数の「平行な流れ」が考えられるとき、シナリオはいくらか複雑になります。
Additional work in the area of implementing a working partial order protocol is being performed both at the University of Delaware and at the LAAS du CNRS laboratory in Toulouse, France - particularly in support of distributed, high-speed, multimedia communication. It will be interesting to examine the processing requirements for an implementation of a partial order protocol at key events (such as object arrival) compared with a non-partial order implementation.
デラウエア大学において特にトゥールーズ(フランス)分配されて、高速なマルチメディア通信を支持したラースdu CNRS実験室で働く部分的なオーダープロトコルを実行する領域での追加仕事をしています。 部分的なオーダープロトコルの実現がないかどうか主要な出来事(物の到着などの)で非部分的なオーダー実現と比べて処理所要を調べるのはおもしろいでしょう。
Finally, the authors are interested in the realization of a network application utilizing a partial order service. The aim of such work is threefold: (1) provide further insight into the expected performance gains, (2) identify new issues unique to partial order transport and, (3) build a road-map for application designers interested in using a partial order service.
最終的に、作者は部分的なオーダーサービスを利用するネットワーク応用の実現に興味を持っています。 そのような仕事の目的は三倍です: (1) 予想された性能向上に関するさらなる洞察を提供してください、そして、(2) 部分的なオーダー輸送にユニークな新規発行を特定してください、そして、(3) 部分的なオーダーサービスを利用したがっていたアプリケーション設計者のために道路地図を造ってください。
7. Summary
7. 概要
This RFC introduces the concepts of a partial order service and discusses the practical issues involved with including partial ordering in a transport protocol. The need for such a service is motivated by several applications including the vast fields of distributed databases, and multimedia. The service has been presented as a backward-compatible extension to TCP to adapt to
このRFCは部分的にオーダーサービスの概念を紹介して、トランスポート・プロトコルに順序を含んでいるのにかかわる実用的な問題について議論します。 そのようなサービスの必要性は分散データベース、およびマルチメディアの広大な分野を含むいくつかのアプリケーションで動機づけられています。 サービスは、順応するために後方コンパチブル拡大としてTCPに提示されました。
Connolly, Amer & Conrad [Page 32] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[32ページ]RFC1693: 部分的なオーダーサービス1994年11月
applications with different needs specified in terms of QOS parameters.
異なった必要性があるアプリケーションはQOSパラメタに関して指定しました。
The notion of a partial ordering extends QOS flexibility to include object delivery, reliability, and temporal value thus allowing the transport layer to effectively handle a wider range of applications (i.e., any which might benefit from such mechanisms). The service profile described in Section 4 accurately characterizes the QOS for a partial order service (which encompasses the two extremes of total ordered and unordered transport as well).
事実上、トランスポート層が、より広い範囲のアプリケーション(すなわち、そのようなメカニズムの利益を得るかもしれないいずれも)を扱うのを許容しながら、順序の概念はその結果、物の配送、信頼性、および時の値を含むようにQOSの柔軟性を広げています。 セクション4で説明されたサービスプロフィールは部分的なオーダーサービス(また、総注文されて順不同の輸送の2つの極端を取り囲む)のために正確にQOSを特徴付けます。
Several significant modifications have been proposed and are summarized here:
いくつかの重要な変更が、提案されて、ここへまとめられます:
(1) Replacing the requirement for ordered delivery with one for
application-dependent partial ordering
(1) 命令された配送のための要件をアプリケーション依存する順序のための1つに取り替えること。
(2) Allowing unreliable and partially reliable data transport
(2) 頼り無くて部分的に信頼できるデータ伝送を許容すること。
(3) Conducting a non-symmetrical connection (not entirely foreign
to TCP, the use of different MSS values for the two sides
of a connection is an example)
(3) 非対称の接続を指導すること。(TCPに完全に外国ではありません、異なったMSS値の接続の2つの側面の使用は例です)
(4) Management of "objects" rather than octets
(4) 八重奏よりむしろ「物」の管理
(5) Modified acknowledgment strategy
(5) 変更された承認戦略
(6) New definition for the send and receive "windows"
(6) 新しい定義、「窓」を送って、受けてください。
(7) Extension of the User/TCP interface to include certain
QOS parameters
(7) あるQOSパラメタを含むUser/TCPインタフェースの拡大
(8) Use of new TCP options
(8) 新しいTCPオプションの使用
As evidenced by this list, a partial order and partial reliability service proposes to re-examine several fundamental transport mechanisms and, in so doing, offers the opportunity for substantial improvement in the support of existing and new application areas.
このリストによって証明されるように、そうする際に、部分的な注文と部分的な信頼性のサービスは、数個の基本的な移送機構を再検討するよう提案して、存在と新しい応用分野のサポートにおける実質的な改善の機会を申し出ます。
Connolly, Amer & Conrad [Page 33] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[33ページ]RFC1693: 部分的なオーダーサービス1994年11月
8. References
8. 参照
[ACCD93a] Amer, P., Chassot, C., Connolly, T., and M. Diaz,
"Partial Order Transport Service for Multimedia
Applications: Reliable Service", Second International
Symposium on High Performance Distributed Computing
(HPDC-2), Spokane, Washington, July 1993.
[ACCD93a] アメア、P.、Chassot、C.、コノリー、T.、およびM.ディアーズ、「部分的なオーダーはマルチメディア応用のためのサービスを輸送します」。 「信頼できるサービス」、高性能分散コンピューティング(HPDC-2)、スポーケンワシントン、1993年7月の第2国際シンポジウム。
[ACCD93b] Amer, P., Chassot, C., Connolly, T., and M. Diaz,
"Partial Order Transport Service for Multimedia
Applications: Unreliable Service", Proc. INET '93, San
Francisco, August 1993.
[ACCD93b] アメア、P.、Chassot、C.、コノリー、T.、およびM.ディアーズ、「部分的なオーダーはマルチメディア応用のためのサービスを輸送します」。 「頼り無いサービス」、Proc。 INET93年、サンフランシスコ、1993年8月。
[AH91] Anderson, D., and G. Homsy, "A Continuous Media I/O
Server and its Synchronization Mechanism", IEEE
Computer, 24(10), 51-57, October 1991.
[AH91] アンダーソン、D.、G.Homsy、および「Continuousメディア入出力ServerとそのSynchronization Mechanism」、51-57、10月1991 24(10)、日IEEEコンピュータ、
[AS93] Agrawala, A., and D. Sanghi, "Experimental Assessment
of End-to-End Behavior on Internet," Proc. IEEE INFOCOM
'93, San Francisco, CA, March 1993.
[AS93] Agrawala、A.、およびD.Sanghi、「インターネットにおける終わりから終わりへの振舞いの実験的な査定」、Proc。 1993年のサンフランシスコ(カリフォルニア)の行進のIEEE INFOCOM93年。
[BCP93] Claffy, K., Polyzos, G., and H.-W. Braun, "Traffic
Characteristics of the T1 NSFNET", Proc. IEEE INFOCOM
'93, San Francisco, CA, March 1993.
[BCP93] Claffy、K.、Polyzos、G.、およびH.W。 ブラウン、「T1 NSFNETの交通の特性」、Proc。 1993年のサンフランシスコ(カリフォルニア)の行進のIEEE INFOCOM93年。
[Bol93] Bolot, J., "End-to-End Packet Delay and Loss Behavior
in the Internet", SIGCOMM '93, Ithaca, NY, September
1993.
SIGCOMMイタケー(ニューヨーク)1993年9月93年の間の[Bol93]Bolotと、J.と、「インターネットの終わりから終わりへのパケット遅れと損失の振舞い」
[CAC93] Conrad, P., Amer, P., and T. Connolly, "Improving
Performance in Transport-Layer Communications Protocols
by using Partial Orders and Partial Reliability",
Work in Progress, December 1993.
[CAC93] 「部分的な注文と部分的な信頼性を使用することによって、トランスポート層通信規約における性能を向上し」て、コンラッド、P.、アメア、P.、およびT.コノリーは進行中(1993年12月)で働いています。
[Chang93] Chang, Y., "High-Speed Transport Protocol Evaluation --
the Final Report", MCNC Center for Communications
Technical Document, February 1993.
[Chang93] チャン、Y.、MCNCがコミュニケーション技術文献、2月1993に中心に置く「高速輸送は評価について議定書の中で述べます--決勝は報告します」。
[Dee89] Deering, S., "Host Extensions for IP Multicasting," STD
5, RFC 1112 Stanford University, August 1989.
[Dee89] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、1112年のRFCスタンフォード大学、1989年8月。
[DS93] Diaz, M., and P. Senac, "Time Stream Petri Nets: A
Model for Multimedia Synchronization", Proceedings of
Multimedia Modeling '93, Singapore, 1993.
[DS93] ディアーズ、M.、およびP.Senac、「Streamペトリが以下を網状にならせる時」 「マルチメディア同期のためのモデル」、1993の93年、シンガポールをモデル化するマルチメディアの議事
Connolly, Amer & Conrad [Page 34] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[34ページ]RFC1693: 部分的なオーダーサービス1994年11月
[HKN91] Hardt-Kornacki, S., and L. Ness, "Optimization Model
for the Delivery of Interactive Multimedia Documents",
In Proc. Globecom '91, 669-673, Phoenix, Arizona,
December 1991.
Procの[HKN91]ハート-Kornacki、S.、およびL.ネス湖、「インタラクティブ・マルチメディアドキュメントの配送のための最適化モデル。」 669-673と、フェニックス(アリゾナ)1991年12月のGlobecom91年。
[JB88] Jacobson, V., and R. Braden, "TCP Extensions for
Long-Delay Paths", RFC 1072, LBL, USC/Information
Sciences Institute, October 1988.
[JB88] ジェーコブソン、V.、およびR.ブレーデン、「長時間の遅延経路のためのTCP拡張子」、RFC1072、LBL、科学が1988年10月に任命するUSC/情報。
[JBB92] Jacobson, V., Braden, R., and D. Borman, "TCP
Extensions for High Performance", RFC 1323, LBL, Cray
Research, USC/Information Sciences Institute, May 1992.
[JBB92]ジェーコブソンとV.とブレーデン、R.とD.ボーマン、「高性能のためのTCP拡張子」RFC1323、LBL、クレイリサーチ(科学が設けるUSC/情報)は1992がそうするかもしれません。
[LMKQ89] Leffler, S., McKusick, M., Karels, M., and J.
Quarterman, "4.3 BSD UNIX Operating System",
Addison-Wesley Publishing Company, Reading, MA, 1989.
[LMKQ89]レフラーとS.とマキュージックとM.とKarels、M.とJ.Quarterman、「4.3BSD Unixオペレーティングシステム」、アディソン-ウエスリー出版社読書、MA、1989
[OP91] O'Malley, S., and L. Peterson, "TCP Extensions
Considered Harmful", RFC 1263, University of Arizona,
October 1991.
[OP91]オマリー、S.とL.ピーターソン、「有害であると考えられたTCP拡張子」RFC1263、アリゾナ大学、1991年10月。
[Pos81] Postel, J., "Transmission Control Protocol - DARPA
Internet Program Protocol Specification," STD 7,
RFC 793, DARPA, September 1981.
[Pos81] ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD7、RFC793、DARPA、1981年9月。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Connolly, Amer & Conrad [Page 35] RFC 1693 An Extension to TCP: Partial Order Service November 1994
コノリー、アメア、およびTCPへの1拡大あたりコンラッド[35ページ]RFC1693: 部分的なオーダーサービス1994年11月
Authors' Addresses
作者のアドレス
Tom Connolly 101C Smith Hall Department of Computer & Information Sciences University of Delaware Newark, DE 19716 - 2586
コンピュータのトムコノリー101Cスミスホール部と情報科学デラウエア大学ニューアーク(DE)19716--2586
EMail: connolly@udel.edu
メール: connolly@udel.edu
Paul D. Amer 101C Smith Hall Department of Computer & Information Sciences University of Delaware Newark, DE 19716 - 2586
コンピュータのポールD.アメア101Cスミスホール部と情報科学デラウエア大学ニューアーク(DE)19716--2586
EMail: amer@udel.edu
メール: amer@udel.edu
Phill Conrad 101C Smith Hall Department of Computer & Information Sciences University of Delaware Newark, DE 19716 - 2586
コンピュータのフィルコンラッド101Cスミスホール部と情報科学デラウエア大学ニューアーク(DE)19716--2586
EMail: pconrad@udel.edu
メール: pconrad@udel.edu
Connolly, Amer & Conrad [Page 36]
コノリー、アメア、およびコンラッド[36ページ]
一覧
スポンサーリンク
