RFC1301 日本語訳
1301 Multicast Transport Protocol. S. Armstrong, A. Freier, K.Marzullo. February 1992. (Format: TXT=91976 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Armstrong
Request for Comments: 1301 Xerox
A. Freier
Apple
K. Marzullo
Cornell
February 1992
コメントを求めるワーキンググループS.アームストロングの要求をネットワークでつないでください: 1301 ゼロックスA.フライアアップルK.Marzulloコーネル1992年2月
Multicast Transport Protocol
マルチキャストトランスポート・プロトコル
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Summary
概要
This memo describes a protocol for reliable transport that utilizes the multicast capability of applicable lower layer networking architectures. The transport definition permits an arbitrary number of transport providers to perform realtime collaborations without requiring networking clients (aka, applications) to possess detailed knowledge of the population or geographical dispersion of the participating members. It is not network architectural specific, but does implicitly require some form of multicasting (or broadcasting) at the data link level, as well as some means of communicating that capability up through the layers to the transport.
このメモは適切な下層ネットワークアーキテクチャのマルチキャスト能力を利用する信頼できる輸送のためにプロトコルについて説明します。 輸送定義は、ネットワーククライアント(通称アプリケーション)には人口に関する詳細な知識か参加しているメンバーの地理的な分散がある必要でない輸送プロバイダーの特殊活字の数字がリアルタイムで共同研究を実行することを許可します。 それは、建築詳細をネットワークでつながないことですが、データリンク・レベルでそれとなく、何らかのフォームのマルチキャスティング(または、放送する)を必要とします、層を通してその能力を輸送に伝えるいくつかの手段と同様に。
Keywords: reliable transport, multicast, broadcast, collaboration, networking.
キーワード: マルチキャスト、放送、共同がネットワークでつながれる信頼できる輸送。
Table of Contents
目次
1. Introduction 2
2. Protocol description 3
2.1 Definition of terms 3
2.2 Packet format 6
2.2.1. Protocol version 7
2.2.2. Packet type and modifier 7
2.2.3. Subchannel 9
2.2.4. Source connection identifier 9
2.2.5. Destination connection identifier 10
2.2.6. Message acceptance 10
2.2.7. Heartbeat 12
2.2.8. Window 12
2.2.9. Retention 12
1. 序論2 2。 用語3 2.2Packet形式6 2.2.1の記述3 2.1Definitionについて議定書の中で述べてください。 プロトコルバージョン7 2.2 .2。 パケットタイプと修飾語7 2.2、.3 サブチャネル、9 2.2 .4。 ソース接続識別子9 2.2.5。 目的地接続識別子10 2.2.6。 メッセージ承認10 2.2.7。 鼓動、12 2.2 .8。 2.2に.9に12に窓を付けてください。 保有12
Armstrong, Freier & Marzullo [Page 1] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[1ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
2.3 Transport addresses 12
2.3.1. Unknown transport address 12
2.3.2. Web's multicast address 13
2.3.3. Member addresses 13
3. Protocol behavior 13
3.1. Establishing a transport 13
3.1.1. Join request 14
3.1.2. Join confirm/deny 16
3.2 Maintaining data consistency 17
3.2.1. Transmit tokens 17
3.2.2. Data transmission 20
3.2.3. Empty packets 23
3.2.4. Missed data 26
3.2.5. Retrying operations 26
3.2.6. Retransmission 27
3.2.7. Duplicate suppression 29
3.2.8. Banishment 29
3.3 Terminating the transport 29
3.3.1. Voluntary quits 30
3.3.2. Master quit 30
3.3.3. Banishment 30
3.4 Transport parameters 30
3.4.1. Quality of service 30
3.4.2. Selecting parameter values 31
3.4.3. Caching member information 33
A. Appendix: MTP as an Internet Protocol transport 34
A.1 Internet Protocol multicast addressing 34
A.2 Encapsulation 35
A.3 Fields of the bridge protocol 35
A.4 Relationship to other Internet Transports 36
References 36
Footnotes 37
Security Considerations 37
Authors' Addresses 38
2.3 輸送は2.3に.1に12を扱います。 未知の輸送アドレス12 2.3.2。 ウェブのマルチキャストアドレス13 2.3.3。 メンバーは3に13を扱います。 振舞い13 3.1について議定書の中で述べてください。 3.1に.1に輸送13を確立します。 .2に要求14 3.1を接合してください。 接合してください。16 3.2Maintainingデータ一貫性17 3.2.1を確認するか、または否定します。 .2にトークン17 3.2を伝えてください。 データ伝送、20 3.2 .3。 .4にパケット23 3.2を空にしてください。 データ26 3.2に、.5に消えます。 .6に操作26 3.2を再試行します。 Retransmission、27 3.2 .7。 写し抑圧29 3.2.8。 追放29 3.3Terminating、3.3に.1に29を輸送してください。 自発的である、3.3に.2に30をやめます。 マスターは3.3に.3に30をやめました。 追放30 3.4Transportパラメタ30 3.4.1。 サービス30 3.4上質の.2 3.4に.3にパラメタ値31を選択します。 メンバー情報33A.Appendixをキャッシュします: ブリッジの34A.2 Encapsulation35A.3フィールズに演説するインターネットプロトコル輸送34A.1インターネットプロトコルマルチキャストとしてのMTPは他のインターネットTransports36References36Footnotes37Security Considerations37AuthorsのAddresses38に35A.4 Relationshipについて議定書の中で述べます。
1. Introduction
1. 序論
This document describes a flow controlled, atomic multicasting transport protocol (MTP). The purpose of this document is to present sufficient information to implement the protocol.
このドキュメントは制御された流れ、原子マルチキャスティングトランスポート・プロトコル(MTP)について説明します。 このドキュメントの目的はプロトコルを実装するために十分な情報を提示することです。
The MTP design has been influenced by the large body of the networking and distributed systems literature and technology that has been introduced during the last decade and a half. Representative sources include [Xer81], [BSTM79] and [Pos81] for transport design, and [Bog83] and [DIX82] for general concepts of broadcast and multicast. [CLZ87] influenced MTP's retransmission mechanisms, and [Fre84] influenced the transport timings. MTP over IP uses mechanisms
MTPデザインは最後の10年間と半分の間に導入されているネットワーク、分散システム文学、および技術の大きいボディーによって影響を及ぼされました。 代表しているソースは放送とマルチキャストに関する一般概念のための[Xer81]、輸送デザインのための[BSTM79]と[Pos81]、[Bog83]、および[DIX82]を入れます。 [CLZ87]はMTPの「再-トランスミッション」メカニズムに影響を及ぼしました、そして、[Fre84]は輸送タイミングに影響を及ぼしました。 IPの上のMTPはメカニズムを使用します。
Armstrong, Freier & Marzullo [Page 2] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[2ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
described in [Dee89]. MTP's ordering and agreement protocols were influenced by work done in [CM87], [JB89] and [Cri88]. Finally, a description of MTP's philosophy and its motivation can be found in [AFM91].
[Dee89]では、説明されます。 [CM87]、[JB89]、および[Cri88]で行われた仕事でMTPの注文と協定プロトコルは影響を及ぼされました。 最終的に、[AFM91]でMTPの哲学とその動機の記述を見つけることができます。
2. Protocol description
2. プロトコル記述
MTP is a transport in that it is a client of the network layer (as defined by the OSI networking model) [1]. MTP provides reliable delivery of client data between one or more communicating processes, as well as a predefined principal process. The collection of processes is called a web.
それがネットワーク層(OSIネットワークモデルによって定義されるように)[1]のクライアントであるので、MTPは輸送です。 MTPは1かさらに交信しているプロセスと、事前に定義された主要なプロセスの間にクライアントデータの信頼できる配信を提供します。 プロセスの収集はウェブと呼ばれます。
In addition to transporting data reliably and efficiently, MTP provides the synchronization necessary for web members to agree on the order of receipt of all messages and can agree on the delivery of the message even in the face of partitions. This ordering and agreement protocol uses serialized tokens granted by the master to producers.
確かに効率的にデータを輸送することに加えて、MTPはウェブ材がすべてのメッセージの領収書の注文に同意するのに必要な同期を提供して、パーティションに直面してさえメッセージの配送に同意できます。 この注文と協定プロトコル用途はマスターによってプロデューサーに与えられたトークンを連載しました。
The processes may have any one of three levels of capability. One member must be the master. The master instantiates and controls the behavior of the web, including its membership and performance. Non master members may be either producer/consumers or pure consumers. The former class of member is permitted to transmit user data to the entire membership (and expected to logically hear itself), while the latter is prohibited from transmitting user data.
プロセスには、能力の3つのレベルのいずれもあるかもしれません。 1人のメンバーはマスターであるに違いありません。 マスターは、その会員資格と性能を含むウェブの振舞いを例示して、制御します。 非マスターメンバーは、プロデューサー/消費者か純粋な消費者のどちらかであるかもしれません。 前のクラスのメンバーが全体の会員資格(そして、それ自体の声を論理的に聞くと予想する)に利用者データを伝えることが許可されています、後者は利用者データを伝えるのが禁止されていますが。
MTP is a negative acknowledgement protocol, exploiting the highly reliable delivery of the local area and wide area network technologies of today. Successful delivery of data is accepted by consuming stations silently rather than having the successful delivery noted to the producing process, thus reducing the amount of reverse traffic required to maintain synchronization.
MTPは否定的承認プロトコルです、局部の高信頼性配送と今日の広域ネットワーク技術を利用して。 うまくいっている配送を生産プロセスに注意させるより静かにむしろステーションを消費することによって、データのうまくいっている配送を受け入れます、その結果、同期を維持するのに必要である逆のトラフィックの量を減少させます。
2.1 Definition of terms
2.1 用語の定義
The following terms are used throughout this document. They are defined here to eliminate ambiguity.
次の用語はこのドキュメント中で使用されます。 それらは、あいまいさを排除するためにここで定義されます。
consumer A consumer is a transport that is capable only of
receiving user data. It may transmit control packets,
such as negative acknowledgements, but may never transmit
any requests for the transmit token or any form of data
or empty messages.
消費者A消費者は単に利用者データを受け取ることができる輸送です。 コントロールパケットを伝えるかもしれません、どんな要求も決して伝えないかもしれなくて否定的承認などのようにデータか空のメッセージのトークンかあらゆる書式を伝えてください。
heartbeat A heartbeat is an interval of time, nominally measured in
milliseconds. It is a key parameter in the transport's
鼓動A鼓動は名目上はミリセカンドで測定された時間の間隔です。 それは輸送のもので主要なパラメタです。
Armstrong, Freier & Marzullo [Page 3] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[3ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
state and can be adapted to the requirements of the
transport's client to provide the desired quality of
service.
輸送のクライアントが必要なサービスの質を提供するという要件に述べて、適合している場合があります。
master The master is the principal member of the web. The master
capability is a superset of a producer member. The
master is mainly responsible for giving out transmit
tokens to members who wish to send data, and overseeing
the web's membership and operational parameters.
マスター、マスターはウェブの主要メンバーです。 マスター能力はプロデューサーのメンバーのスーパーセットです。 マスターはデータを送りたがっているメンバーにトークンを伝えて、ウェブの会員資格と操作上のパラメタを監督しながら尽きるのに主に責任感が強いです。
member A web member is any process that has been permitted to
join the web (by the master) as well as the master
itself.
メンバーAウェブ材はマスター自体と同様にウェブを接合することが(マスターで)許可されているあらゆるプロセスです。
membership Every member is classified as to its intentions for
class joining the web. Membership classes are defined to be
consumer, producer and master. Each successive class is a
formal superset of the previous.
会員資格Everyメンバーはウェブに合流するクラスのために意志に関して分類されます。 会員資格のクラスは、消費者と、生産者とマスターになるように定義されます。 それぞれの連続したクラスは前の正式なスーパーセットです。
message An MTP message is a concatenation of the user data
portions of a series of data packets with the last packet
in the series carrying an end of message indication. A
message may contain any number of bytes of user data,
including zero.
メッセージAn MTPメッセージはシリーズにおける最後のパケットがメッセージ指示の終わりを運んでいる一連のデータ・パケットのユーザデータ部の連結です。 メッセージはゼロを含むどんなバイト数の利用者データも含むかもしれません。
NSAP The network service access point. This is the network
address, or the node address of the machine, where a
service is available.
NSAP、ネットワークサービスアクセスポイント。 これは、ネットワーク・アドレス、またはマシンのノードアドレスです。(そこでは、サービスが利用可能です)。
producer Producer is a class of membership that is a formal
superset of a consumer. A producer is permitted (and
expected) to transmit client data as well as consume data
transmitted by other producers.
プロデューサーProducerは消費者の正式なスーパーセットである会員資格のクラスです。 プロデューサーは、クライアントデータを伝えて、他のプロデューサーによって送られたデータを消費することを許可されています(そして、予想されます)。
retention Retention is one of the three fundamental parameters that
make up the transport's state (along with heartbeat and
window). Retention is a number of heartbeats, and though
applied in several different circumstances, is primarily
used as the number of heartbeats a producing client must
maintain buffered data should it need to be
retransmitted.
保有Retentionは輸送の状態(鼓動と窓に伴う)を構成している3つの基本パラメータの1つです。 保有は、鼓動の数であり、もっとも、いくつかの異なった事情で適用されて、数であり、再送される必要があるなら生産しているクライアントがバッファリングされたデータであることを支持しなければならない鼓動の数として主として使用されます。
token In order to transmit, a producer must first be in
possesion of a token. Tokens are granted only by the
master and include the message sequence number.
Consequently, they are fundamental in the operation of
the ordering and agreement protocol used by MTP.
トークンInは伝わるように注文して、プロデューサーは最初に、トークンのpossesionにいるに違いありません。 トークンは、単にマスターによって与えられて、メッセージ通番を含んでいます。 その結果、それらはMTPによって使用された注文と協定プロトコルの操作で基本的です。
Armstrong, Freier & Marzullo [Page 4] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[4ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
TSAP The transport service access point. This is the address
that uniquely defines particular instantiation of a
service. TSAPs are formed by logically concatenating the
node's NSAP with a transport identifier (and perhaps a
packet/protocol type).
TSAP、輸送サービスアクセスポイント。 これは唯一特定のサービスの具体化を定義するアドレスです。 TSAPsは、輸送識別子(そして、恐らくパケット/プロトコルタイプ)でノードのNSAPを論理的に連結することによって、形成されます。
user data User data is the client information carried in MTP data
packets and treated as uninterpreted octets by the
transport. The end of message and subchannel indicators
are also be treated as user data.
利用者データUserデータはMTPデータ・パケットで運ばれて、輸送で非解釈された八重奏として扱われたクライアント情報です。 また、メッセージとサブチャネルインディケータの終わりはユーザとして扱われたデータです。
web A collection of processes collaborating on the solution
of a single problem.
ただ一つの問題の解決で共同するプロセスのウェブA収集。
window The window is one of the fundamental elements of the
transport's state that can be controlled to affect the
quality of service being provided to the client. It
represents the number of user data carrying packets that
may be multicast into the web during a heartbeat by a
single member.
窓、窓はクライアントに提供されるサービスの質に影響するように制御できる輸送の状態の基本的な要素の1つです。 それは鼓動の間に独身のメンバーでマルチキャストであるかもしれないパケットをウェブまで運ぶ利用者データの数を表します。
Armstrong, Freier & Marzullo [Page 5] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[5ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
2.2 Packet format
2.2 パケット・フォーマット
An MTP packet consists of a transport protocol header followed by a variable amount of data. The protocol header, shown in Figure 1, is part of every packet. The remainder of the packet is either user data (packet type = data) or additional transport specific information. The fields in the header are statically defined as n-bit wide quantities. There are no undefined fields or fields that may at any time have undefined values. Reserved fields, if they exist, must always have a value of zero.
MTPパケットは可変データ量があとに続いたトランスポート・プロトコルヘッダーから成ります。 図1で見せられたプロトコルヘッダーはあらゆるパケットの一部です。 パケットの残りは利用者データ(パケットタイプはデータと等しい)であるか追加輸送が特殊情報です。 ヘッダーの分野は静的にnビットの広い量と定義されます。 どんな未定義の分野もないか、またはいつでもそうするかもしれない分野は未定義値を持っています。 予約された分野には、存在しているなら、ゼロの値がいつもなければなりません。
0 7 8 15 16 23 24 31
---------------------------------------------------------- -----
| protocol | packet | type | client | |
| version | type | modifier | channel | |
---------------------------------------------------------- |
| | |
| source connection identifier | |
---------------------------------------------------------- |
| | |
| destination connection identifier |
---------------------------------------------------------- transport
| | header
| message acceptance criteria |
---------------------------------------------------------- |
| | |
| heartbeat | |
---------------------------------------------------------- |
| | | |
| window | retention | |
---------------------------------------------------------- -----
| | |
| | |
| | |
| (data content and format |
| dependent on packet type | data
| and modifier) | fields
| |
| | |
| | |
| | |
---------------------------------------------------------- -----
0 7 8 15 16 23 24 31 ---------------------------------------------------------- ----- | プロトコル| パケット| タイプ| クライアント| | | バージョン| タイプ| 修飾語| チャンネル| | ---------------------------------------------------------- | | | | | ソース接続識別子| | ---------------------------------------------------------- | | | | | 目的地接続識別子| ---------------------------------------------------------- 輸送| | ヘッダー| メッセージ合否基準| ---------------------------------------------------------- | | | | | 鼓動| | ---------------------------------------------------------- | | | | | | 窓| 保有| | ---------------------------------------------------------- ----- | | | | | | | | | | (データは、パケットタイプ| データで| | 扶養家族を満足して、フォーマットします|、修飾語) | 分野| | | | | | | | | | | ---------------------------------------------------------- -----
Figure 1. MTP packet format
図1。 MTPパケット・フォーマット
Armstrong, Freier & Marzullo [Page 6] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[6ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
2.2.1. Protocol version
2.2.1. プロトコルバージョン
The first 8 bits of the packet are the protocol version number. This document describes version 1 of the Multicast Transport Protocol and thus the version field has a value of 0x01.
パケットの最初の8ビットはプロトコルバージョン番号です。 このドキュメントはMulticast Transportプロトコルのバージョン1について説明します、そして、その結果、バージョン分野には、0×01の値があります。
2.2.2. Packet type and modifier
2.2.2. パケットタイプと修飾語
The second byte of the header is the packet type and the following byte contains the packet type modifier. Typical control message exchanges are in a request/response pair. The modifier field simplifies the construction of responses by permitting reuse of the incoming message with minimal modification. The following table gives the packet type field values along with their modifiers. The modifiers are valid only in the context of the type. In the prose of the definitions and later in the document, the syntax for referring to one of the entries described in the following table will be type[modifier]. For example, a reference to data[eow] would be a packet of type data with an end of window modifier.
ヘッダーの2番目のバイトはパケットタイプです、そして、以下のバイトはパケットタイプ修飾語を含んでいます。 典型的なコントロール交換処理が要求/応答組であります。 修飾語分野は、最小量の変更による入力メッセージの再利用を可能にすることによって、応答の工事を簡素化します。 以下のテーブルはそれらの修飾語に伴うパケットタイプ分野値を与えます。 修飾語はタイプの文脈だけで有効です。 定義に関する散文とドキュメントで、より遅く、以下のテーブルで説明されたエントリーの1つについて言及するための構文はタイプにな[修飾語]るでしょう。 例えば、データ[eow]の参照は窓の修飾語の終わりがあるタイプデータのパケットでしょう。
type modifier description
修飾語記述をタイプしてください。
data(0) data(0) The packet is one that contains user
information. Only the process possessing a
transmit token is permitted to send data
unless specifically requested to retransmit
previously transmitted data. All packets of
type data are multicast to the entire web.
データ(0)データ、(0) パケットはユーザー情報を含むものです。 aを所有している過程だけが象徴を伝えます。以前に伝えられたデータを再送するよう明確に要求されない場合データを送ることが許可されています。 タイプデータのすべてのパケットが全体のウェブへのマルチキャストです。
eow(1) A data packet with the eow (end of window)
modifier set indicates that the transmitter
intends to send no more packets in this
heartbeat either because it has sent as many
as permitted given the window parameter or
simply has no more data to send during the
current heartbeat. This is not client
information but rather a hint to be used by
transport providers to synchronize the
computation and transmission of naks.
eow(窓の端)修飾語セットがあるデータ・パケットが、現在の鼓動の間、送るためにそれが窓のパラメタを考えて、可能にするか、または単にそれ以上のデータを全く持っていないのと同じくらい多くを送ったので送信機がこの鼓動におけるそれ以上のパケットも全く送らないつもりであるのを示すeow(1)。 これはクライアント情報ではなく、むしろ輸送プロバイダーによって使用された、naksの計算とトランスミッションを同時にさせるべきであるヒントです。
eom(2) Data[eom] marks the end of the message to the
consumers, and the surrendering of the
transmit token to the master. And like a
data[eow] a data[eom] packet implies the end
of window.
eom(2)データが消費者、および引き渡しへのメッセージの終わりを示す、[eom]象徴をマスターに伝えてください。 そして、データ[eow]のように、データ[eom]パケットは窓の端を含意します。
nak(1) request(0) A nak[request] packet is a consumer
requesting a retransmission of one or more
nak[要求する]パケットが1以上の「再-トランスミッション」を要求する消費者であるというnak(1)要求(0)
Armstrong, Freier & Marzullo [Page 7] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[7ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
data packets. The data field contains an
ordered list of packet sequence numbers that
are being requested. Naks of any form are
always unicast.
データ・パケット。 データ・フィールドは要求されているパケット一連番号の規則正しいリストを含んでいます。 いつもどんな形式のNaksもユニキャストです。
deny(1) A nak[deny] message indicates that the
producer source of the nak[deny]) cannot
retransmit one or more of the packets
requested. The process receiving the
nak[deny] must report the failure to its
client.
(1) nak[否定する]メッセージが、nak[否定する)のプロデューサーの情報筋が要求されたパケットの1つ以上を再送できないのを示すことを否定してください。 nak[否定する]を受ける過程は失敗をクライアントに報告しなければなりません。
empty(2) dally(0) An empty[dally] packet is multicast to
maintain synchronization when no client data
is available.
空の(2)はふざけます。(0) [ぶらぶらつぶします]空のパケットはクライアントデータがないのが利用可能である同期を維持するマルチキャストです。
cancel(1) If a producer finds itself in possession of a
transmit token and has no data to send, it
may cancel the token[request] by multicasting
an empty[cancel] message.
気付くと、プロデューサーがaの所有物にいるなら、キャンセル(1)は、象徴を伝えて、送らないデータを全く持って、それは空の[キャンセル]が通信させるマルチキャスティングで、象徴[要求する]を取り消すかもしれません。
hibernate(2) If the master possesses all of the web's
transmit tokens and all outstanding messages
have been accepted or rejected, the master
may transmit empty[hibernate] packets at a
rate significantly slower than indicated by
the web's value of heartbeat.
(2) マスターがすべてを所有しているなら、避寒します。すべての傑出しているメッセージをウェブのものでは、象徴を伝えて、受け入れるか、または拒絶しました、そして、マスターはウェブの鼓動の値によって示されるよりかなり遅い速度で空[冬眠する]のパケットを伝えてもよいです。
join(3) request(0) A join[request] packet is sent by a process
wishing to join a web to the web's unknown
TSAP (see section 2.2.5).
(3) Aが工程でパケットを送るというウェブの未知のTSAPにウェブを接合したがっている[要求]を接合するという(セクション2.2.5を見てください)要求(0)に参加してください。
confirm(1) The join[confirm] packet is the master's
confirmation of the destination's request to
join the web. It will be unicast by the
master (and only the master) to the station
that sent the join[request].
接合してください。(1)を確認してください、[確認します]パケットはウェブを接合するという目的地の要求に関するマスターの確認です。 発信したのが、ステーションへのマスター(そして、マスターだけ)によるユニキャストである、接合してください[要求します]。
deny(2) A join[deny] packet indicates permission to
join the web was denied. It may only be
transmitted by the master and will be unicast
to the member that sent the join[request].
(2) Aが接合することを否定してください。[否定します]パケットは、ウェブを接合する許可が否定されたのを示します。 マスターによって伝えられるだけであるかもしれなく、発信したメンバーへのユニキャストになる、接合してください[要求します]。
quit(4) request(0) A quit[request] may be unicast to the master
by any member of the web at any time to
indicate the sending process wishes to
withdraw from the web. Any member may unicast
a quit to another member requesting that the
(4) 示すいつでもウェブのどんなメンバーによるマスターへのユニキャストもウェブから引き下がるという送付過程願望であったかもしれないならやめられた[要求します]要求(0)Aをやめてください。 どんなメンバーもそうするかもしれない、aがそれを要求する別のメンバーにやめたユニキャスト
Armstrong, Freier & Marzullo [Page 8] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[8ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
destination member quit the web due to
intolerable behavior. The master may
multicast a quit[request] requiring that the
entire web disband. The request will be
multicast at regular heartbeat intervals
until there are no responses to retention
requests.
目的地メンバーは堪え難い振舞いのためウェブをやめました。 マスターは全体のウェブが解散するのを必要とするaがやめた[要求します]マルチキャストがそうするかもしれません。 保有要求への応答が全くないまで、要求は一定の鼓動間隔で、マルチキャストになるでしょう。
confirm(1) The quit[confirm] packet is the indication
that a quit[request] has been observed and
appropriate local action has been taken.
Quit[confirm] are always unicast.
(1) 辞任を確認してください[確認します]。パケットはやめられた[要求します]aを観測して、適切な地方の行動を取ったという指示です。 いつもやめられているのは[確認します]、ユニキャストです。
token(5) request(0) A token[request] is a producing member
requesting a transmit token from the master.
Such packets are unicast to the master.
象徴(5)要求(0)A象徴[要求]はaがマスターから象徴を伝えるよう要求する生産しているメンバーです。 そのようなパケットはマスターへのユニキャストです。
confirm(1) The token[confirm] packet is sent by the
master to assign the transmit token to a
member that has requested it. token[confirm]
will be unicast to the member being granted
the token.
それを要求したメンバーに象徴を伝えてください。(1) 象徴[確認する]パケットが選任するマスターによって送られると確認してください、象徴[確認する]は象徴が与えられるメンバーへのユニキャストになるでしょう。
isMember(6) request(0) An isMember[request] is soliciting
verification that the target member is a
recognized member of the web. All forms of
the isMember packet are unicast to a specific
member.
isMember(6)は、(0) isMember[要求]が目標メンバーがそうである検証に請求して、aがメンバーを見分けたということであるようウェブを要求します。 isMemberパケットのすべてのフォームが特定のメンバーへのユニキャストです。
confirm(1) IsMember[confirm] packets are positive
responses to isMember[requests].
(1) IsMember[確認する]パケットがisMember[要求]への積極的な応答であると確認してください。
deny(2) If the member receiving the isMember[request]
cannot confirm the target's membership in the
web, it responds with a isMember[deny].
(2) isMember[要求する]を受け取るメンバーがウェブにおける目標の会員資格を確認できないなら、それがisMember[否定する]と共に応じることを否定してください。
2.2.3. Subchannel
2.2.3. サブチャネル
The fourth byte of the transport header contains the client's subchannel value. The default value of the subchannel field is zero. Semantics of the subchannel value are defined by the transport client and therefore are only applicable to packets of type data. All other packet types must have a subchannel value of zero.
輸送ヘッダーの4番目のバイトはクライアントのサブチャネル値を含んでいます。 サブチャネル分野のデフォルト値はゼロです。 サブチャネル価値の意味論は、輸送クライアントによって定義されて、したがって、単にタイプデータのパケットに適切です。 他のすべてのパケットタイプには、ゼロのサブチャネル値がなければなりません。
2.2.4. Source connection identifier
2.2.4. ソース接続識別子
The source connection identifier field is a 32 bit field containing a transmitting system unique value assigned at the time the transport
ソース接続識別子分野はユニークな値が当時、輸送を割り当てた伝えるシステムを含む32ビットの分野です。
Armstrong, Freier & Marzullo [Page 9] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[9ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
is created. The field is used in identifying the particular transport instantiation and is a component of the TSAP. Every packet transmitted by the transport must have this field set.
作成されます。 分野は、特定の輸送具体化を特定する際に使用されて、TSAPの部品です。 輸送で伝えられたあらゆるパケットで、この分野を設定しなければなりません。
2.2.5. Destination connection identifier
2.2.5. 目的地接続識別子
The destination connection identifier is the 32 bit identifier of the target transport. From the point of view of a process sending a packet, there are three types of destination connection identifiers. First, there is the unknown connection identifier (0x00000000). The unknown value is used only as the destination connection identifier in the join[request] packet.
目的地接続識別子は目標輸送に関する32ビットの識別子です。 パケットを送る過程の観点から、3つのタイプに関する目的地接続識別子は来ています。 まず最初に、未知の接続識別子(0×00000000)があります。 未知の値が単に目的地接続識別子として中で使用される、パケットを接合してください[要求します]。
Second, there is the multicast connection identifier gleaned from the join[confirm] message sent by the master. The multicast connection identifier is used in conjunction with the multicast NSAP to form the destination TSAP of all packets multicast to the entire web [2].
2番目に、接続識別子が落ち穂拾いであったマルチキャストがある、マスターによって送られたメッセージを接合してください[確認します]。 マルチキャスト接続識別子は、すべてのパケットマルチキャストの目的地TSAPを全体のウェブ[2]に形成するのにマルチキャストNSAPに関連して使用されます。
The last class of connection identifier is a unicast identifier and is used to form the destination TSAP when unicasting packets to individual members. Every member of the web has associated with it a unicast connection identifier that is used to form its own unicast TSAP.
個人会員にパケットをunicastingするとき、接続識別子の最後のクラスは、ユニキャスト識別子であり、目的地TSAPを形成するのに使用されます。 ウェブのすべてのメンバーがそれ自身のユニキャストTSAPを形成するのに使用されるユニキャスト接続識別子をそれに関連づけました。
2.2.6. Message acceptance
2.2.6. メッセージ承認
MTP ensures that all processes agree on which messages are accepted and in what order they are accepted. The master controls this aspect of the protocol by controlling allocation of transmit tokens and setting the status of messages. Once a token for a message has been assigned (see section 3.2.1) the master sets the status of that message according to the following rules [AFM91]:
MTPは、すべての過程がどのメッセージを受け入れるか、そして、どんなオーダーでそれらを受け入れるかに同意するのを確実にします。 マスターは、象徴を伝えて、メッセージの状態を設定する配分を制御することによって、プロトコルのこの局面を制御します。 メッセージをマスターに割り当ててあるので(セクション3.2.1を見ます)、以下の規則[AFM91]に従って、かつての象徴はそのメッセージの状態を設定します:
If the master has seen the entire message (i.e., has seen the
data[eom] and all intervening data packets), the status is accepted.
マスターが全体のメッセージ(すなわち、データ[eom]とすべての介入しているデータ・パケットを見た)を見たなら、状態を受け入れます。
If the master has not seen the entire message but believes the
message sender is still operational and connected to the master (as
determined by the master), the status is pending.
マスターが、全体のメッセージを見ていませんが、メッセージ送付者がマスターにまだ操作上であって接続されていると信じているなら(マスターによって決定されるように)、状態は未定です。
If the master has not seen the entire message and believes the
sender to have failed or partitioned away, the status is rejected.
マスターが、全体のメッセージを見ていなくて、失敗したか、または仕切った送付者が遠くにいると信じているなら、状態は拒絶されます。
Message status is carried in the message acceptance record (see Figure 2) of every packet, and processes learn the status of earlier messages by processing this information.
メッセージ状態はあらゆるパケットに関するメッセージ承認記録(図2を見る)で運ばれます、そして、過程はこの情報を処理することによって、以前のメッセージの状態を学びます。
The acceptance criteria is a multiple part record that carries the
合否基準は運ばれるa複数の部分記録です。
Armstrong, Freier & Marzullo [Page 10] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[10ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
rules of agreement to determine the message acceptance. The most significant 8 bits is a flag that, if not zero, indicates synchronization is required. The field may vary on a per message basis as directed by producing transport's client. The default is that no synchronization is required.
メッセージ承認を決定する協定の規則。 最も重要な8ビットはゼロでないなら同期が必要であることを示す旗です。 分野は指示されるとしての輸送のクライアントを生産するのによるメッセージ基礎あたりのaで異なるかもしれません。 デフォルトは同期が全く必要でないということです。
The second part of the record is a 12 element vector that represents the status of the last 12 messages transmitted into the web.
記録の第二部はウェブに送られた最後の12のメッセージの状態を表す12要素ベクトルです。
0 7 8 15 16 23 24 31
---------------------------------------------------------
| | |
| synchro | tri-state bitmask[12] |
---------------------------------------------------------
| message | packet sequence |
| sequence number | number |
---------------------------------------------------------
0 7 8 15 16 23 24 31 --------------------------------------------------------- | | | | シンクロ| 3州のビットマスク[12]| --------------------------------------------------------- | メッセージ| パケット系列| | 一連番号| 数| ---------------------------------------------------------
Figure 2. Message acceptance record
図2。 メッセージ承認記録
Each element of the array is two bits in length and may have one of three values: accepted(0), pending(1) or rejected(2). Initially, the bit mask is set to all zeros. When the token for message m is transmitted, the first (left-most) element of the vector represents the the state of message m - 1, the second element of the vector is the status of message m - 2, and so forth. Therefore the status of the last 12 messages are visible, the status of older messages are lost, logically by shifting the elements out of the vector. Only the master is permitted to set the status of messages. The master is not permitted to shift a status of pending beyond the end of the vector. If that situation arises, the master must instead not confirm any token[request] until the oldest message can be marked as either rejected or accepted.
アレイの各要素は、長さ2ビットであり、3つの値の1つを持っているかもしれません: (1)まで(0)を受け入れたか、または(2)を拒絶しました。 初めは、噛み付いているマスクはすべてのゼロに設定されます。 メッセージm象徴が伝えられるとき、ベクトルの最初(最もいなくなる)の要素はメッセージmの状態を表します--1、ベクトルの2番目の要素はメッセージmの状態です--2など。 したがって、最後の12のメッセージの状態が目に見える、より古いメッセージの状態は、ベクトルから要素を移動させることによって、論理的に失われています。 マスターだけがメッセージの状態を設定することが許可されています。 マスターはそうです。ベクトルの終わりを超えて未定の状態で状態を変更させるために、受入れられません。 その状況が起こるなら、マスターは代わりに、拒絶するか、または受け入れるように最も古いメッセージをマークできるまでどんな象徴[要求する]も確認してはいけません。
Message sequence numbers are 16 bit unsigned values. The field is initialized to zero by the master when the transport is initialized, and incremented by one after each token is granted. Only the master is permitted to change the value of the message sequence number. Once granted, that message sequence number is consumed and the state of the message must eventually become either accepted or rejected. No transmit tokens may be granted if the assignment of a message sequence number that would cause a value of pending to be shifted beyond the end of the status vector.
メッセージ通番は16ビットの無記名の値です。 各象徴を与えた後に、輸送を1つ初期化して、増加するとき、マスターは分野をゼロに初期化します。 マスターだけがメッセージ通番の値を変えるのが許容されています。 いったん与えると、そのメッセージ通番を消費します、そして、メッセージの状態は結局、受け入れるか、または拒絶するようにならなければなりません。 いいえは象徴を伝えます。状態ベクトルの終わりを超えたところまで移行して、それが未定の状態で値を引き起こすメッセージ通番の課題であるなら与えるかもしれません。
Packet sequence numbers are unsigned 16 bit numbers assigned by the producing process on a per message basis. Packet sequence numbers start at a value of zero for each new message and are incremented by one (consumed) for each data packet making up the message. Consumers
パケット一連番号は数がメッセージ基礎あたりのaで生産工程で割り当てた無記名の16ビットです。 パケット一連番号は、それぞれの新しいメッセージのためにゼロの値で始まって、メッセージを作る各データ・パケットのために1つ増加されます(消費されます)。 消費者
Armstrong, Freier & Marzullo [Page 11] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[11ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
detecting missing packet sequence numbers must send a nak[request] to the appropriate producer to recover the missed data.
なくなったパケット一連番号を検出すると、nak[要求する]は、逃されたデータを回復するために適切なプロデューサーに送られなければなりません。
Control packets always contain the message acceptance criteria with a synchronization flag set to zero (0x00), the highest message sequence number observed and a packet sequence number one greater than previously observed. Control packets do not consume any sequence numbers. Since control messages are not reliably delivered, the acceptance criteria should only be checked to see if they fall within the proper range of message numbers, relative to the current message number of the receiving station. The range of acceptable sequence numbers should be m-11 to m-13, inclusive, where m is the current message number.
コントロールパケットはいつも同期旗がある合否基準が(0×00)のゼロを合わせるように設定するメッセージを含んでいます、と最も高いメッセージ通番は観測しました、そして、以前によりすばらしいパケット一連番号ものは見ました。 コントロールパケットはどんな一連番号も消費しません。 コントロールメッセージが確かに送られないので、合否基準はそれらが適切な範囲のメッセージ番号の中で低下するかどうかを見るためにチェックされるだけであるべきです、受入れステーションの現在のメッセージ番号に比例して。 許容できる一連番号の範囲はmが現在のメッセージ番号である包括的な11対m-13であるべきですm-。
2.2.7. Heartbeat
2.2.7. 鼓動
Heartbeat is an unsigned 32 bit field that has the units of milliseconds. The value of heartbeat is shared by all members of the web. By definition at least one packet (either data, empty or quit from the master) will be multicast into the web within every heartbeat period.
鼓動はミリセカンドのユニットがある32ビットの無記名の分野です。 鼓動の値はウェブのすべてのメンバーによって共有されます。 定義上、少なくとも1つのパケット(マスターから空になるか、またはやめられたデータ)がいつも鼓動の期間中にウェブへのマルチキャストになるでしょう。
2.2.8. Window
2.2.8. 窓
The allocation window (or simply window) is a 16 bit unsigned field that indicates the maximum number of data packets that can be multicasted by a member in a single heartbeat. It is the sum of the retransmitted and new data packets.
配分ウィンドウ(または、単に窓)は単一の鼓動でメンバーによってmulticastedされることができるデータ・パケットの最大数を示す16ビットの無記名の分野です。 それは再送されて新しいデータ・パケットの合計です。
2.2.9. Retention
2.2.9. 保有
The retention field is a 16 bit unsigned value that is the number of heartbeats for which a producer must retain transmitted client data and state for the purpose of retransmission.
保有分野は、「再-トランスミッション」の目的のためのプロデューサーが伝えられたクライアントデータを保有しなければならない鼓動の数である16ビットの無記名の値と状態です。
2.3 Transport addresses
2.3 輸送アドレス
Associated with each transport are logically three transport service access points (TSAP), logically formed by the concatenation of a network service access point (NSAP) and a transport connection identifier. These TSAPs are the unknown TSAP, the web's multicast TSAP and each individual member's TSAP.
各輸送に関連しているのは、論理的に、3がネットワークサービスアクセスポイント(NSAP)と輸送接続識別子の連結で論理的に形成されたサービスアクセスポイント(TSAP)を輸送するということです。 これらのTSAPsは未知のTSAPと、ウェブのマルチキャストTSAPと各個人会員のTSAPです。
2.3.1. Unknown transport address
2.3.1. 未知の輸送アドレス
Stations that are just joining must use the multicast NSAP associated with the transport, but are not yet aware of either the web's multicast TSAP the master process' TSAP. Therefore, joining stations
ただ加わっている駅は、輸送に関連しているマルチキャストNSAPを使用しなければなりませんが、まだ過程のウェブのマルチキャストTSAPマスターTSAPを意識していません。 したがって、ステーションに加わること。
Armstrong, Freier & Marzullo [Page 12] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[12ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
fabricate a temporary TSAP (referred to as a unknown TSAP) by using a connection identifier reserved to mean unknown (0x00000000). The join[confirm] message will be sourced from the master's TSAP and will include the multicast transport connection identifier in the data field. Those values must be extracted from the join[confirm] and remembered by the joining process.
未知(0×00000000)を意味するために予約された接続識別子を使用することによって、一時的なTSAP(未知のTSAPと呼ばれる)を作ってください。 意志がマスターのTSAPから出典を明示されて、データ・フィールドにマルチキャスト輸送接続識別子を含むというメッセージを接合してください[確認します]。 それらの値を抽出しなければならない、接合してください、そして、[確認します]接合で覚えていられて、処理してください。
2.3.2. Web's multicast address
2.3.2. ウェブのマルチキャストアドレス
The multicast TSAP is formed by logically concatenating the multicast NSAP associated with the transport creation and the transport connection identifier returned in the data field of the join[confirm] packet. If more than one network is involved in the web, then the multicast transport address becomes a list, one for each network represented. This list is supplied in the data field of token[confirm] packets.
マルチキャストTSAPが輸送創造と輸送接続識別子に関連しているNSAPがデータ・フィールドで戻ったマルチキャストを論理的に連結することによって形成される、パケットを接合してください[確認します]。 各ネットワークあたりのあるものは、1つ以上のネットワークがウェブにかかわるならマルチキャスト輸送アドレスがリストになると表しました。 象徴[確認する]パケットのデータ・フィールドでこのリストを提供します。
The multicast TSAP is used as the target for all messages that are destined to the entire web, such as data and empty. The master's decision to abandon the transport (quit) is also sent to the multicast transport address.
マルチキャストTSAPはデータなどの全体のウェブに運命づけられていて、空になるすべてのメッセージのための目標として使用されます。 また、輸送(やめる)を捨てるというマスターの決定をマルチキャスト輸送アドレスに送ります。
2.3.3. Member addresses
2.3.3. メンバーアドレス
The member TSAP is formed by using the process' unicast NSAP concatenated with a locally generated unique connection identifier. That TSAP must be the source of every packet transmitted by the process, regardless of its destination, for the lifetime of the transport.
メンバーTSAPは、局所的に発生したユニークな接続識別子で連結された過程のユニキャストNSAPを使用することによって、形成されます。 そのTSAPは工程で伝えられたあらゆるパケットの源であるに違いありません、目的地にかかわらず、輸送の生涯。
Packets unicast to specific members must contain the appropriate TSAP. For producers and consumers this is not difficult. The only TSAPs of interest are the master and the station(s) currently transmitting data.
特定のメンバーへのパケットユニキャストは適切なTSAPを含まなければなりません。 生産者と消費者にとって、これは難しくはありません。 興味がある唯一のTSAPsが現在データを送るマスターとステーションです。
3. Protocol behavior
3. プロトコルの振舞い
This section defines the expectations of the protocol implementation. These expectations should not be considered guidelines or hints, but rather part the protocol.
このセクションはプロトコル実現への期待を定義します。 ガイドラインかヒントであるとこれらの期待を考えるべきではありませんが、むしろプロトコルを分けてください。
3.1 Establishing a transport
3.1 輸送を確立すること。
Before any rendezvous can be affected, a process must first acquire an NSAP that will be the service access point for the instantiation [3]. The process that first establishes at that NSAP is referred to as the master of the web. The decision as to what process acts as the master must be made a priori in order to guarantee unambiguous
どんなランデブーも影響を受けることができる前に、過程は最初に、具体化[3]のためにサービスアクセスポイントになるNSAPを獲得しなければなりません。 最初におまけに、NSAPを設立する過程はウェブのマスターと呼ばれます。 マスターを先験的にしなければならないときどんな過程が行動するかに関する決定、保証明白
Armstrong, Freier & Marzullo [Page 13] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[13ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
creation in the face of network partitions. The process should make a robust effort to verify that the NSAP being used is not already in service. It may do so by repeatedly sending join[requests] to the web's unknown TSAP. If there is no response to repeated transmissions the process may be relatively confident that the NSAP is not in use and proceed with the creation of the web. If not, the creation must be aborted and the situation reported to its client.
ネットワークパーティションに直面して創造。 過程は使用されるNSAPが既に使用中でないことを確かめるための体力を要している努力をするべきです。 したがって、それは、繰り返して発信することによって、[要求]をウェブの未知のTSAPに接合するかもしれません。 繰り返されたトランスミッションへの応答が全くなければ、過程は、NSAPが使用中でないと比較的確信していて、ウェブの創造を続けるかもしれません。 そうでなければ、創造を中止しなければなりませんでした、そして、状況はクライアントに報告しました。
3.1.1. Join request
3.1.1. 要求に参加してください。
Additional members may join the web at any time after the establishment of the master by the joining process sending a join[request] to the unknown TSAP. The joining process should have already assigned a unique connection identifier to its transport instantiation that will be used in the source TSAP of the join[request]. The join[request] must contain zeros in all of the acceptance fields. The heartbeat, window and retention parameters are filled in as requested by the transport provider's client. The data of the message must contain the type, class and quality of service parameters that the client has requested.
aを送る接合工程によるマスターの設立が未知のTSAPで加わった[要求します]後に追加メンバーはいつでも、ウェブに加わるかもしれません。 接合の過程が既にソースTSAPで使用される輸送具体化へのaユニークな接続識別子を割り当てるべきであった、接合してください[要求します]。 必須が承認分野のすべてにゼロを含んでいるという[要求]を接合してください。 鼓動、窓、および保有パラメタは要求された通り輸送プロバイダーのクライアントによって記入されます。 メッセージに関するデータはタイプ、クラス、およびクライアントが要求したサービスの質パラメタを含まなければなりません。
field class definition
分野クラス定義
membership class master(0) There can be only a single web
master, and that member has all
privileges of a producer class member
plus those acquitted only to the
master.
そこでの会員資格クラスマスター(0)は独身のウェブマスターであるにすぎないかもしれません、そして、そのメンバーはプロデューサーのクラスのメンバーとそれらのすべての特権をマスターだけに免罪させます。
producer(1) A process that has producer class
membership wishes to transmit data
into the web as well as consume.
データをウェブに送るというプロデューサークラス会員資格願望を良くするプロデューサー(1)Aの過程、消費します。
consumer(2) A consumer process is a read only
process. It will send naks in order
to reliably receive data but will
never ask for or be permitted to take
possession of a transmit token.
消費者が処理する消費者(2)は書き込み禁止の過程です。 それは、意志だけが決して求めないデータを確かに受け取るためにnaksを送るか、またはあるでしょう。aの所有物を取ることが許可されていて、象徴を伝えてください。
transport class reliable(0) Specifies a reliable transport, i.e.,
one that will generate and process
naks. The implication is that the
data will be reliably delivered or
the failure will be detected and
reported to the client.
輸送のクラス信頼できる(0)は信頼できる輸送、すなわち、naksを発生して、処理するものを指定します。 含意はデータを確かに送るか、失敗がクライアントに検出されて、報告されるということです。
unreliable(1) The transport supports best
輸送が最もよく支持する頼り無い(1)
Armstrong, Freier & Marzullo [Page 14] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[14ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
effort delivery. Such a transport may
still fail if the error rates are too
high, but tolerable loss or
corruption of data will be permitted
[4].
努力配送。 誤り率が高過ぎるなら、そのような輸送はまだ失敗しているかもしれませんが、[4]はデータの許容できる損失か不正に受入れられるでしょう。
transport type NxN(0) The transport will accept multiple
processes with producing capability.
輸送が複数であると受け入れる輸送タイプNxN(0)は生産能力で処理します。
1xN(1) A 1xN transport permits only a single
producer whose identity was
established a priori.
1xN輸送がアイデンティティが先験的に確立された独身のプロデューサーだけに可能にする1xN(1)。
The client's desire for minimum throughput (expressed in kilobytes per second) is the lowest value that will be accepted. That throughput is calculated using the heartbeat and window parameters of the transport, and the maximum data unit size, not by measuring actual traffic. Any member that suggests a combination of those parameters that result in an unacceptable throughput will be ignored or asked to withdraw from the web.
最小のスループット(1秒あたりのキロバイトで、言い表される)に関するクライアントの願望は受け入れられる中で最も低い値です。 そのスループットは輸送の鼓動と窓のパラメタ、および最大のデータ単位サイズを使用することで計算されます、どんな測定の実際の交通でも、そうしません。 容認できないスループットをもたらすそれらのパラメタの組み合わせを勧めるどんなメンバーも、ウェブから引き下がるように無視されるか、または頼まれるでしょう。
A joining client may also suggest a maximum data unit size. This field is expressed as a number of bytes that can be included in a data packet as client data.
また、接合クライアントは最大のデータ単位サイズを勧めるかもしれません。 この分野はクライアントデータとしてデータ・パケットに含むことができるバイト数として言い表されます。
If no response is received in a single heartbeat, the join[request] should be retransmitted using the same source TSAP so the master can detect the difference between a new process and a retransmission of a join[request].
単一の鼓動で応答を全く受けないなら接合する、マスターがaの「再-トランスミッション」が接合するニュープロセスとaの違い[要求する]を検出できるように、再送された使用が同じソースTSAPであったなら接合してください[要求します]。
Armstrong, Freier & Marzullo [Page 15] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[15ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
3.1.2. Join confirm/deny
3.1.2. 接合、確認するか、否定
Only the master of the web will respond to join[request]. The response may either permit the entry of the new process or deny it. The request to join may be denied because the new member is specifying service parameters that are in conflict with those established by the master. If the join is confirmed the join[confirm] will be unicast by the master with a data field that contains the web's current operating parameters. If those parameters are unacceptable to the joining process it may decide to withdraw from the web. Otherwise the parameters must be accepted as the current operating values.
ウェブのマスターだけが、接合する[要求する]ために応じるでしょう。 応答は、ニュープロセスのエントリーを可能にするか、またはそれを否定するかもしれません。 新しいメンバーがマスターによって設立されるそれらとの闘争中であることのサービスパラメタを指定しているので、接合するという要求は否定されるかもしれません。 接合、確認される、それが含むデータ・フィールドがあるマスターによるユニキャストがウェブの現在の運転パラメータであるつもりであったなら接合してください[確認します]。 それらのパラメタが接合の過程に容認できないなら、それは、ウェブから引き下がると決めるかもしれません。 さもなければ、現在の操作値としてパラメタを認めなければなりません。
0 7 8 15 16 23 24 31
---------------------------------------------------------- -----
| protocol | packet | type | client | |
| version | type | modifier | channel | |
---------------------------------------------------------- |
| | |
| source connection identifier | |
---------------------------------------------------------- |
| | |
| destination connection identifier |
---------------------------------------------------------- transport
| | header
| message acceptance criteria |
---------------------------------------------------------- |
| | |
| heartbeat | |
---------------------------------------------------------- |
| | | |
| window | retention | |
---------------------------------------------------------- -----
| member | transport | transport | | |
| class | class | type | reserved | |
----------------------------------------------------------
| minimum | maximum data | data
| throughput | unit size |
---------------------------------------------------------- |
| multicast connection | |
| identifier | |
---------------------------------------------------------- -----
0 7 8 15 16 23 24 31 ---------------------------------------------------------- ----- | プロトコル| パケット| タイプ| クライアント| | | バージョン| タイプ| 修飾語| チャンネル| | ---------------------------------------------------------- | | | | | ソース接続識別子| | ---------------------------------------------------------- | | | | | 目的地接続識別子| ---------------------------------------------------------- 輸送| | ヘッダー| メッセージ合否基準| ---------------------------------------------------------- | | | | | 鼓動| | ---------------------------------------------------------- | | | | | | 窓| 保有| | ---------------------------------------------------------- ----- | メンバー| 輸送| 輸送| | | | クラス| クラス| タイプ| 予約されます。| | ---------------------------------------------------------- | 最小限| 最大のデータ| データ| スループット| ユニットサイズ| ---------------------------------------------------------- | | マルチキャスト接続| | | 識別子| | ---------------------------------------------------------- -----
Figure 3. join packet
図3 パケットを接合してください。
The join[confirm] will also contain the multicast connection identifier. This must be used to form the TSAP that will be the destination for all multicast messages for the transport. The source
意志を接合してください、そして、[確認します]また、マルチキャスト接続識別子を含んでください。 輸送へのすべてのマルチキャストメッセージのために目的地になるTSAPを形成するのにこれを使用しなければなりません。 ソース
Armstrong, Freier & Marzullo [Page 16] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[16ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
of the join[confirm] message will be the master's TSAP and must be recorded by the member for later use.
マスターのものがTSAPであるつもりであったならメッセージに加わって[確認します]、メンバーは後の使用のために記録しなければなりません。
The master must be in possession of all the transmit tokens when it sends a join[confirm]. Requiring the master to have the transmit tokens insures that the joining member will enter the web and observe only complete messages. It also permits a notification of the master's client of the join so that application state may be automatically sent to the newly joining member. The newly joined member may be on a network not previously represented in the web's membership, thus requiring a new multicast TSAP be added to the existing list. The entire list will be conveyed in the data field of all subsequent token[confirm] messages (described later).
それが発信する象徴を伝えてください。マスターがすべての所有物にあるに違いない、aは接合します[確認します]。 象徴を伝えてください。マスターを必要とする、持っている接合メンバーがウェブに入って、完全なメッセージだけを観測するのを保障します。 また、マスターのクライアントのa通知を可能にする、自動的に新たに接合しているメンバーにアプリケーション状態を送ることができるように、接合してください。 新たに接合されたメンバーは以前にウェブの会員資格で代表されなかったネットワークの一員であるかもしれません、その結果、新しいマルチキャストTSAPを必要として、既存のリストに追加されてください。 全体のリストはすべてのその後の象徴[確認する]メッセージ(後で説明される)のデータ・フィールドで伝えられるでしょう。
3.2 Maintaining data consistency
3.2 データの一貫性を維持すること。
The transport is responsible for maintaining the consistency of the data submitted for delivery by producing clients. The actual client data, while representing the bulk of the information that flows through the web, is accompanied by significant amounts of protocol state information. In addition to the state information piggybacked with the client data, there is a minimum amount of protocol packets that are purely for use by the transport, invisible to the transport client.
輸送は配送のためにクライアントを生産することによって提出されたデータの一貫性を維持するのに原因となります。 実際のクライアントデータはウェブを通して流れる情報の大半を表している間、かなりの量のプロトコル州の情報によって伴われます。 クライアントデータで背負われた州の情報に加えて、輸送によって純粋な使用のためのものである最小の量のプロトコルパケットがあります、輸送クライアントにとって、目に見えません。
3.2.1. Transmit tokens
3.2.1. 象徴を伝えてください。
Before any process may transmit client data or state it must first possess a transmit token. It may acquire the token by transmitting a token[request] to the master. Requests should be unicast to the master's TSAP and should be retransmitted at intervals approximately equal to the heartbeat. Since it is the central source for a transmit token, the master may apply some fairness algorithms to the passing of permission to transmit. At a minimum the requests should be queued in a first in, first out order. Duplicate requests from a single member should be ignored, keeping instead the first unhonored request. When appropriate, the master will send a member with a request pending a token[confirm]. The data field of the response contains all the multicast TSAPs that are represented in the current web at that point in time.
どんな過程も、クライアントデータを伝えるか、または最初にaを所有しなければならないと述べるかもしれない前に、象徴を伝えてください。 それは、象徴[要求する]をマスターに伝えることによって、象徴を入手するかもしれません。 要求は、マスターのTSAPへのユニキャストであるべきであり、鼓動とほとんど等しい間隔で、再送されるべきです。 それがaのための主要なソースであるので、象徴を伝えてください、そして、マスターはいくつかの公正アルゴリズムを伝わる許可の通過に適用してもよいです。 最小限では、要求は最初に、オーダーから最初のコネで列に並ばせられるべきです。 代わりに最初の「非-光栄に思」われた要求を保って、独身のメンバーからの写し要求は無視されるべきです。 適切であるときに、マスターは象徴[確認する]まで要求と共にメンバーを送るでしょう。 応答のデータ・フィールドは時間内にその時現在のウェブで表されるすべてのマルチキャストTSAPsを含んでいます。
If the master detects no data or heartbeat messages being transmitted into the web it will assume the token is lost, presumably because the member holding the token has failed or has become partitioned away from the master. In such cases, the master may attempt to confirm the state of the process (perhaps by sending isMember[request]). If the member does not respond it is removed from the active members of the web, the message is marked as rejected, the token is assumed by the
マスターが、どんなデータも鼓動メッセージもウェブに送られないのを検出すると、象徴が無くなると仮定するでしょう、象徴を持っているメンバーがおそらく失敗したか、またはマスターから遠くで仕切られるようになったので。 そのような場合、マスターは、過程(恐らくisMember[要求する]を送るのによる)の状態を確認するのを試みるかもしれません。 メッセージが拒絶されるように著しい、メンバーが応じないなら、ウェブの活動的なメンバーからそれを取り除いて、象徴を想定します。
Armstrong, Freier & Marzullo [Page 17] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[17ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
master.
習得します。
Figure 4 shows a timing diagram of a token pass. Increasing time is towards the bottom of the figure. In this figure, process A has a token, and process B requests a token when there are no free tokens.
図4は象徴パスのタイムチャートを示しています。 増加する時間は図の下部に向かっています。 この図では、過程Aは象徴を持っています、そして、どんな無料の象徴もないとき、過程Bは象徴を要求します。
A master B
"A" multicasts data | | "B" requests
|\ | | transmit token
| \ | /|
| \ | / |
| \ | / |
"A" multicasts data | \ | / | "B" retransmits
w/eom set |\ \| / | token request
| \ \V /|
| \ |\ / |
| \ | V / |
| \ | / |
| \| / |
| \V |
| |\ |
| | V |
| |\ | Master assigns
| | \ | token to "B"
| | \ |
| | \ |
| | \ |
| | V|
| | |
| | /| "B" multicasts
| | / | data
| | / |
| | / |
| | / |
| |/ |
| / |
| /| |
| V | |
| | |
AマスターB「A」マルチキャストデータ| | 「B」要求|\ | | トークンを伝えてください。| \ | /| | \ | / | | \ | / | マルチキャストデータ| \ | / | eomがセットした状態で、「B」は再送されます。|\ \| / | トークン要求| \\対/| | \ |\ / | | \ | V/| | \ | / | | \| / | | \V| | |\ | | | V| | |\ | マスター案配| | \ | 「B」へのトークン| | \ | | | \ | | | \ | | | V| | | | | | /| 「B」マルチキャスト| | / | データ| | / | | | / | | | / | | |/ | | / | | /| | | V| | | | |
Figure 4. Acquiring the token
図4。 トークンを取得します。
Token packets, like other control packets, do not consume sequence numbers. Hence, the master must be able to use another mechanism to determine whether multiple token[request] from a single member are actually requests for a separate token, or are a retransmission of a token[request]. To carry out this obligation, the master and the members must have an implicit understanding of each other's state.
他のコントロールパケットのように、トークンパケットは一連番号を消費しません。 したがって、マスターは、独身のメンバーからの複数のトークン[要求する]が別々のトークンを求める実際に要求である、またはトークン[要求する]の「再-トランスミッション」であるかを決定するのに別のメカニズムを使用できなければなりません。 この義務、マスター、およびメンバーを運び出すのにおいて、互いの状態の暗黙の理解がなければなりません。
Armstrong, Freier & Marzullo [Page 18] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[18ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
0 7 8 15 16 23 24 31
---------------------------------------------------------- -----
| protocol | packet | type | client | |
| version | type | modifier | channel | |
---------------------------------------------------------- |
| | |
| source connection identifier | |
---------------------------------------------------------- |
| | |
| destination connection identifier |
---------------------------------------------------------- transport
| | header
| message acceptance criteria |
---------------------------------------------------------- |
| | |
| heartbeat | |
---------------------------------------------------------- |
| | | |
| window | retention | |
---------------------------------------------------------- -----
| | |
| | |
| TSAPs of all networks |
| represented in the web | data
| membership |
| | |
| | |
---------------------------------------------------------- -----
0 7 8 15 16 23 24 31 ---------------------------------------------------------- ----- | プロトコル| パケット| タイプ| クライアント| | | バージョン| タイプ| 修飾語| チャンネル| | ---------------------------------------------------------- | | | | | ソース接続識別子| | ---------------------------------------------------------- | | | | | 目的地接続識別子| ---------------------------------------------------------- 輸送| | ヘッダー| メッセージ合否基準| ---------------------------------------------------------- | | | | | 鼓動| | ---------------------------------------------------------- | | | | | | 窓| 保有| | ---------------------------------------------------------- ----- | | | | | | | すべてのネットワークのTSAPs| | ウェブでは、表されます。| データ| 会員資格| | | | | | | ---------------------------------------------------------- -----
Figure 5. token packet
図5トークンパケット
Assume that the token, as viewed by the master, has three states:
マスターによって見られるトークンが3つの州を持っていると仮定してください:
idle The token is not currently assigned. Specifically the
message number that it defines is not represented in the
current message acceptance vector.
怠けてください。割り当てられて、現在、トークンはそうではありません。 明確にそれが定義するメッセージ番号は現在のメッセージ承認ベクトルで表されません。
pending The token has been assigned by the master via a
token[confirm] packet, but the master has not yet seen
any data packets to indicate that the from the producing
member received the notification.
トークンまでそれを示すためには割り当てられて、しかし、トークン[確認する]パケットを通したマスター、マスターがまだ少しのデータ・パケットも見ていないということであった、生産から、メンバーは通知を受け取りました。
busy The token has been assigned and the master has seen data
packets carrying the assigned message number. The message
comprised by those packets is still represented in the
message acceptance vector.
忙しさ、トークンを割り当ててあって、マスターは、データ・パケットが割り当てられたメッセージ番号を運ぶのを見ました。 それらのパケットによって包括されたメッセージはメッセージ承認ベクトルでまだ表されています。
Furthermore, a token that is not idle also has associated with its
その上、活動していなくないトークンも交際した、それ
Armstrong, Freier & Marzullo [Page 19] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[19ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
state the TSAP of the process that owns (or owned) the token.
トークンを所有している(または、所有されています)プロセスのTSAPを述べてください。
Based on this state, the master will respond to any process that has a token in pending state with a reassignment of that token. This is based on the assumption that the original token[confirm] was not received by the requesting process. The only other possibility is that the process did receive the token and transmitted data packets using that token, but the master did not see them. But data messages are by design multi-packet messages, padded with empty packets if necessary. The possibility of the master missing all of the packets of a message is considered less than the possibility of the requesting process missing a single token[confirm] packet.
この状態に基づいて、マスターはそのトークンの再割当てと共に未定の状態にトークンを持っているどんなプロセスにも応じるでしょう。 これはオリジナルのトークン[確認する]が要求プロセスによって受け取られなかったという仮定に基づいています。 他の唯一の可能性はプロセスがトークンを受けて、そのトークンを使用することでデータ・パケットを伝えましたが、マスターがそれらを見なかったということです。 しかし、データメッセージが必要なら、空のパケットで水増しされたデザインマルチパケットメッセージであります。 マスターがメッセージのパケットのすべてを逃す可能性はただ一つのトークン[確認する]パケットを逃す要求プロセスの可能性ほど考えられません。
The process requesting tokens must consider the actions of the master and what prompted them. In most cases the assumptions made by the master will be correct. However, there are two ambiguous situations. There is the situation that the master is most directly addressing, not knowing whether the requesting process has failed to observe the token[confirm] or the master has failed to see data packets transmitted by the producing process. There is also the possibility that the requesting process timed out too quickly and the retransmission of the token[request] passed the token[confirm] in the night. In any case the producing process may find itself in possession of a token for which it has no need. These can be dismissed by sending an empty[cancel] packet.
トークンを要求するプロセスはマスターとそれらをうながしたことに関する動作を考えなければなりません。 多くの場合、マスターによってされた仮定は正しくなるでしょう。 しかしながら、2つの漠然とした状況があります。 マスターが最も直接扱っている状況があります、要求プロセスがトークン[確認する]を観測していないか、またはマスターが、データ・パケットが生産プロセスによって伝えられるのを見ていないかを知らないで。 また、要求プロセスが外であまりにすぐに調節されて、トークン[要求する]の「再-トランスミッション」が夜トークン[確認する]を通過した可能性があります。 気付くと生産プロセスがそれが必要性を全く持っていないトークンの所有物にいるかもしれないどんな場合でも。 空の[キャンセル]パケットを送ることによって、これらを棄却できます。
Another possibility is that the requesting process has actually made use of the assigned token and is requesting another token. Unless the master has observed data using the token, the master will still consider the token pending. Therefore, a process that receives a duplicate token[confirm] should interpret it as a nak and retransmit any data packets previously sent using the token's message sequence number.
別の可能性は要求プロセスが実際に割り当てられたトークンを利用して、別のトークンを要求しているということです。 マスターに測定値がトークンを使用することでないと、それでも、マスターは、トークンが未定であると考えるでしょう。 したがって、写しトークン[確認する]を受けるプロセスは、nakとしてそれを解釈して、トークンのメッセージ通番が以前に使用させられたどんなデータ・パケットも再送するはずです。
3.2.2. Data transmission
3.2.2. データ伝送
Data is provided by the transport client in the form of uninterpreted bytes. The bytes are encapsulated in packets immediately following the protocol's fixed overhead fields. The packet may have any number of data bytes between zero and the maximum number of bytes of a network protocol packet minus the network overhead and the fixed transport overhead. Every packet that consumes a sequence number must contain either client data or client state transitions such as the end of message indicator or a subchannel transition.
データは非解釈されたバイトの形の輸送クライアントによって提供されます。 すぐにプロトコルの固定費野原に続いて、バイトはパケットでカプセル化されます。 パケットには、ネットワークオーバーヘッドと固定輸送オーバーヘッドを引いてゼロとネットワーク・プロトコルパケットのバイトの最大数の間のいろいろなデータ・バイトがあるかもしれません。 一連番号を消費するあらゆるパケットがメッセージインディケータかサブチャネル変遷の終わりなどのクライアントデータか属国変遷のどちらかを含まなければなりません。
Packets are transmitted in bursts of packets called windows. The protocol guarantees that no more than the current value of window data packets will be transmitted by a single process during a
パケットは窓と呼ばれるパケットの炸裂で伝えられます。 プロトコルはウィンドウデータ・パケットの現行価値がaの間、単一のプロセスによって伝えられるほどそれを保証しません。
Armstrong, Freier & Marzullo [Page 20] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[20ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
heartbeat. Every packet transmitted always contains the latest heartbeat, window and retention information. If full packets are unavailable [5], empty[dally] messages should be transmitted instead. The only packets that will be transmitted containing less than maximum capacity will be data[eom] or those containing client subchannel transitions.
鼓動。 伝えられたあらゆるパケットがいつも最新の鼓動、窓、および保有情報を含んでいます。 完全なパケットが入手できない[5]であるなら、[ぶらぶらつぶします]空のメッセージは代わりに送られるべきです。 最大能力以下を含んでいて、伝えられる唯一のパケットが、データ[eom]かクライアントサブチャネル変遷を含むものになるでしょう。
Armstrong, Freier & Marzullo [Page 21] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[21ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
----- | |
| |\ |
| | \ |
|\ \ |
heartbeat | \ \ |
|\ \ \ |
| | \ \ V| data(n)
| | \ \ |
----- | \ V| data(n+1)
|\ \ |
| \ V| data(n+w-1) w/eow
|\ \ |
| \ \ |
|\ \ \ |
| \ \ V| data(n+w)
| \ \ |
----- | \ V| data(n+w+1)
|\ \ |
| \ V| data(n+2w-1) w/eow
w = window = 3 | \ |
r = retention = 2 | \ |
| \ |
| V| empty(n+2w)
| |
----- | |
|\ |
| \ |
| \ |
| \ |
| \ |
| V| data(n+2w) w/eom
| | Packets n..n+w-1 are released,
----- | | token is surrendered.
| |
| |
| |
| |
| |
| |
| |
----- | | Packets n+w..n+2w-1 are released.
----- | | | |\ | | | \ | |\ \ | 鼓動| \ \ | |\ \ \ | | | \\V| データ(n)| | \ \ | ----- | \V| データ(n+1)|\ \ | | \V| eowがあるデータ(n+w-1)|\ \ | | \ \ | |\ \ \ | | \\V| データ(n+w)| \ \ | ----- | \V| データ(n+w+1)|\ \ | | \V| eow w=窓=3があるデータ(n+2w-1)| \ | r=保有=2| \ | | \ | | V| 空の(n+2w)| | ----- | | |\ | | \ | | \ | | \ | | \ | | V| eomがあるデータ(n+2w)| | パケットn.。n+w-1はリリースされます。----- | | トークンを明け渡します。 | | | | | | | | | | | | | | ----- | | パケットn+w.。n+2w-1はリリースされます。
Figure 6. Normal data transmission
図6。 正常なデータ伝送
Figure 6 shows a timing diagram of a process transmitting into a web (without any complicating naks). Increasing time is towards the bottom of the figure. The transmitting process is obligated to
図6は、プロセスのタイムチャートがウェブ(いずれもnaksを複雑にすることのない)に伝わるのを示します。 増加する時間は図の下部に向かっています。 伝えるプロセスは義務付けられます。
Armstrong, Freier & Marzullo [Page 22] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[22ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
retransmit requested packets for at least retention heartbeat intervals after their first transmission.
彼らの最初のトランスミッションの後に少なくとも保有鼓動間隔の間、要求されたパケットを再送してください。
0 7 8 15 16 23 24 31
---------------------------------------------------------- -----
| protocol | packet | type | client | |
| version | type | modifier | channel | |
---------------------------------------------------------- |
| | |
| source connection identifier | |
---------------------------------------------------------- |
| | |
| destination connection identifier |
---------------------------------------------------------- transport
| | header
| message acceptance criteria |
---------------------------------------------------------- |
| | |
| heartbeat | |
---------------------------------------------------------- |
| | | |
| window | retention | |
---------------------------------------------------------- -----
| | |
| uninterpreted data |
| | data
| |
| | |
---------------------------------------------------------- -----
0 7 8 15 16 23 24 31 ---------------------------------------------------------- ----- | プロトコル| パケット| タイプ| クライアント| | | バージョン| タイプ| 修飾語| チャンネル| | ---------------------------------------------------------- | | | | | ソース接続識別子| | ---------------------------------------------------------- | | | | | 目的地接続識別子| ---------------------------------------------------------- 輸送| | ヘッダー| メッセージ合否基準| ---------------------------------------------------------- | | | | | 鼓動| | ---------------------------------------------------------- | | | | | | 窓| 保有| | ---------------------------------------------------------- ----- | | | | データを非解釈しました。| | | データ| | | | | ---------------------------------------------------------- -----
Figure 7. data packet
図7 データ・パケット
3.2.3. Empty packets
3.2.3. 空のパケット
An empty packet is a control packet multicast into the web at regular intervals by a producer possessing a transmit token when no client data is available. Empty packets are sent to maintain synchronization and to advertise the maximum sequence number of the producer. It provides the opportunity for consuming processes to detect and request retransmission of missed data as well as identifying the owner of a transmit token.
空のパケットによるどんなクライアントデータも利用可能でないときに、一定の間隔を置いてaを所有しているプロデューサーによるウェブへのコントロールパケットマルチキャストがトークンを伝えるということです。 同期を維持して、プロデューサーの最大の一連番号の広告を出すために空のパケットを送ります。 それは検出するプロセスとaの所有者を特定することと同様に逃されたデータの「再-トランスミッション」がトークンを伝えるという要求を消費するのに機会を与えます。
Armstrong, Freier & Marzullo [Page 23] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[23ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
0 7 8 15 16 23 24 31
---------------------------------------------------------- -----
| protocol | packet | type | client | |
| version | type | modifier | channel | |
---------------------------------------------------------- |
| | |
| source connection identifier | |
---------------------------------------------------------- |
| | |
| destination connection identifier |
---------------------------------------------------------- transport
| | header
| message acceptance criteria |
---------------------------------------------------------- |
| | |
| heartbeat | |
---------------------------------------------------------- |
| | | |
| window | retention | |
---------------------------------------------------------- -----
0 7 8 15 16 23 24 31 ---------------------------------------------------------- ----- | プロトコル| パケット| タイプ| クライアント| | | バージョン| タイプ| 修飾語| チャンネル| | ---------------------------------------------------------- | | | | | ソース接続識別子| | ---------------------------------------------------------- | | | | | 目的地接続識別子| ---------------------------------------------------------- 輸送| | ヘッダー| メッセージ合否基準| ---------------------------------------------------------- | | | | | 鼓動| | ---------------------------------------------------------- | | | | | | 窓| 保有| | ---------------------------------------------------------- -----
Figure 8. empty packet
エイト環空のパケット
There are two situations where the empty[dally] packet is used. The first is when there is insufficient data for a full packet presented by the client during a heartbeat. Partial packets should not be transmitted unless there is a client transition to be conveyed, yet something must be transmitted during a heartbeat or the master may think the process owning a transmit token has failed. Empty[dally] is used instead of a data packet until the client provides additional data to fill a packet or indicates a state transition such as an end of message or subchannel transition.
2つの状況が[ぶらぶらつぶします]空のパケットが使用されているところにあります。 1番目は鼓動の間にクライアントによって提示された完全なパケットのための不十分なデータがある時です。 運ばれるためにクライアント変遷がない場合、部分的なパケットを伝えるべきではありません、しかし、何かによる鼓動かマスターがaを所有していると伝わる過程であると考えるかもしれないaの間、伝えられて、象徴が失敗したということでなければなりません。 空になってください[ふざけてください]。データ・パケットの代わりに、クライアントがパケットをいっぱいにするために追加データを提供するか、またはメッセージかサブチャネル変遷の終わりなどの状態遷移を示すまで、使用されます。
The second situation where empty[dally] is used is after the transmission of short messages. Each message should consist of multiple packets in order to enhance the possibility that consumers will observe at least one packet of a message and therefore be able to identify the producer. The transport parameter retention has approximately the correct properties for that insurance. Therefore, a message must consist of at least retention packets. If the client data does not require that many packets, empty[dally] packets must be appended. A process that has no transmittable data and is in possession of a transmit token must send an empty[cancel]. Transmissions of empty[cancel] packets pass the ownership of the transmit token back to the master. When the master observes the control packet, it will mark the referenced to message as rejected so that other consumers do not believe the message lost and attempt to recover.
状況が空であるところに[ぶらぶらつぶします]ある秒に、短いメッセージの伝達の後に使用されているのは、そうです。 各メッセージは、消費者がメッセージの少なくとも1つのパケットを観察して、したがって、プロデューサーを特定できる可能性を高めるために複数のパケットから成るべきです。 輸送パラメタ保有には、その保険のための正しいおよそ特性があります。 したがって、メッセージは少なくとも保有パケットから成らなければなりません。 クライアントデータがそんなに多くのパケットを必要としないなら、[ぶらぶらつぶします]空のパケットを追加しなければなりません。 「移-ミット-可能」データを全く持たないで、aの所有物で象徴を伝えることである過程は空の[キャンセル]を送らなければなりません。 空の[キャンセル]パケットのトランスミッションが所有権を通過する、象徴をマスターに伝えて戻してください。 マスターがコントロールパケットを観察するとき、それは、他の消費者が、メッセージが失われたと信じないように拒絶されるようにメッセージに参照箇所をマークして、回復するのを試みるでしょう。
Armstrong, Freier & Marzullo [Page 24] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[24ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
During periods of no activity (i.e., after all messages have been either accepted or rejected and there are no outstanding transmit tokens) the master may enter hibernation mode by transmitting empty[hibernate] packets. In that mode the master will increase the value of the transport parameter heartbeat in order to reduce network traffic. Such packets are used to indicate that the packet's heartbeat field should not be used for resource computation by those processes that observe it.
活動がない(すなわち、すべてのメッセージがことになったそこで受け入れるか、または拒絶しているのが、いいえという未払いの後に象徴を伝える)期間、マスターは、空[冬眠する]のパケットを伝えることによって、冬眠のモードを入れるかもしれません。 そのモードで、マスターは、ネットワークトラフィックを減少させるために輸送パラメタ鼓動の値を増加させるでしょう。 そのようなパケットは、パケットの鼓動分野がリソース計算にそれを観測するそれらの工程で使用されるべきでないのを示すのに使用されます。
Armstrong, Freier & Marzullo [Page 25] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[25ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
3.2.4. Missed data
3.2.4. 逃されたデータ
The most common method of detecting data loss will be the reception of a data or a heartbeat message that has a sequence number greater than expected from that producer. The second most common method will be a message fragment (missing the end of message) and seeing no more data or empty packets from the producer of the fragment for more than a single heartbeat. In any case the consumer process directs a negative acknowledgment (nak) to the producer of the incomplete message. The data field of the nak message contains a list of ascending sequence number pairs the consumer needs to recover the missed data.
データの損失を検出する最も一般的な方法はデータか鼓動メッセージのレセプションになるでしょう一連番号をそのプロデューサーから予想されるよりすばらしくする。 2番目に一般的な方法は、単一の鼓動以上で断片のプロデューサーからどんなより多くのデータも空のパケットもメッセージ断片(メッセージの終わりをなくす)と見ないことのようになるだろうこと。 どのような場合でも、消費者の過程は否定応答(nak)を不完全なメッセージのプロデューサーに向けます。 nakメッセージのデータ・フィールドは消費者が逃されたデータを回復する必要がある昇順数の組のリストを含んでいます。
0 7 8 15 16 23 24 31
---------------------------------------------------------- -----
| protocol | packet | type | client | |
| version | type | modifier | channel | |
---------------------------------------------------------- |
| | |
| source connection identifier | |
---------------------------------------------------------- |
| | |
| destination connection identifier |
---------------------------------------------------------- transport
| | header
| message acceptance criteria |
---------------------------------------------------------- |
| | |
| heartbeat | |
---------------------------------------------------------- |
| | | |
| window | retention | |
---------------------------------------------------------- -----
| | | |
| message sequence (low) | packet sequence (low) |
---------------------------------------------------------- data
| | |
| message sequence (high) | packet sequence (high) | |
---------------------------------------------------------- -----
0 7 8 15 16 23 24 31 ---------------------------------------------------------- ----- | プロトコル| パケット| タイプ| クライアント| | | バージョン| タイプ| 修飾語| チャンネル| | ---------------------------------------------------------- | | | | | ソース接続識別子| | ---------------------------------------------------------- | | | | | 目的地接続識別子| ---------------------------------------------------------- 輸送| | ヘッダー| メッセージ合否基準| ---------------------------------------------------------- | | | | | 鼓動| | ---------------------------------------------------------- | | | | | | 窓| 保有| | ---------------------------------------------------------- ----- | | | | | メッセージ系列(低い)| パケット系列(低い)| ---------------------------------------------------------- データ| | | | メッセージ系列(高い)| パケット系列(高い)| | ---------------------------------------------------------- -----
Figure 9. nak packet
図9nakパケット
3.2.5. Retrying operations
3.2.5. 操作を再試行します。
Operations must be retried in order to assure that a single packet loss does not cause transport failure. In general the right numbers to do that with exist in the transport. The proper interval between retries is the transport's time constant or heartbeat. The proper
単一のパケット損失が輸送失敗を引き起こさないことを保証するために操作を再試行しなければなりません。 一般に、それをする正しい数は輸送で存在しています。 再試行の適切な間隔は、輸送の時定数か鼓動です。 適切
Armstrong, Freier & Marzullo [Page 26] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[26ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
number of retries is retention.
再試行の数は保有です。
Operations that are retriable (and represented by their respective message types) are join, nak, token, isMember and quit. Another application for the heartbeat and retention is when transmitting empty messages. Empty[dally] messages are transmitted any time data is not available but the data[eom] has not yet been sent. Any process not observing data or empty for more than retention heartbeat intervals will assume to have failed or partitioned away and the transport will be abandoned.
「再-公判に付せられ」な(そして、彼らのそれぞれのメッセージタイプが表されます)操作は、nakに象徴、isMemberを接合して、やめられます。 空のメッセージを送るとき、鼓動と保有の別の利用はあります。 [ぶらぶらつぶします]空のメッセージは伝えられて、どんな時間データも得ることができませんが、データ[eom]がまだ送られないということです。 間隔が仮定する保有鼓動以上が遠くに失敗するか、または仕切ったように、観察しているデータでないか空でないどんな過程と輸送も捨てられるでしょう。
3.2.6. Retransmission
3.2.6. Retransmission
If the producer receives a nak[request] from a consumer process requesting the retransmission of a packet that is no longer available, the producer must send a nak[deny] to the source of the request. If that puts the consumer in a failed state, the consumer will initiate the withdrawal from the web. If a producer receives a nak[request] from a consumer requesting the retransmission of one or more packets, those packets will be multicast to the entire web [6]. All will contain the original client information (such as subchannel and end of message state) and message and packet sequence number. However, the retransmitted packets must contain updated protocol parameter information (heartbeat, window and retention). Retransmitted packets are subject to the same constraints regarding heartbeat and window as original transmissions. Therefore the producer's retransmissions consume a portion of the allocation window allowing less new data to be transmitted in a single heartbeat. Retransmitted packets have priority over (i.e., should be transmitted before) new data packets.
プロデューサーがもう利用可能でないパケットの「再-トランスミッション」を要求する消費者の過程からnak[要求する]を受け取るなら、プロデューサーはnak[否定する]を要求の源に送らなければなりません。 それが破綻国家に消費者を入れると、消費者はウェブから退出を開始するでしょう。 プロデューサーが1つ以上のパケットの「再-トランスミッション」を要求する消費者からnak[要求する]を受け取ると、それらのパケットは全体のウェブ[6]へのマルチキャストになるでしょう。 すべてがオリジナルのクライアント情報(メッセージ状態のサブチャネルや端などの)、メッセージ、およびパケット一連番号を含むでしょう。 しかしながら、再送されたパケットはアップデートされたプロトコルパラメタ情報(鼓動、窓、および保有)を含まなければなりません。 再送されたパケットはオリジナルのトランスミッションとして鼓動と窓に関して同じ規制を受けることがあります。 したがって、プロデューサーの「再-トランスミッション」は新しいデータが単一の鼓動で送られるのをそれほど許容しない配分ウィンドウの一部を消費します。 再送されたパケットには、(すなわち、以前、伝えられるべきです)新しいデータ・パケットより優先権があります。
Armstrong, Freier & Marzullo [Page 27] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[27ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
----- | | retransmission count = rx=0
| |\ |
| | \ |
| |\ \ |
| | \ \ |
| |\ \ \ |
| | \ \ V| data(n)
| | \ \ |
| \ *| data(n+1)
heartbeat | \ |
| V| data(n+w-1-rx) w/eow rx=0
| | |
| | /| nak(n') of n+1
| | / |
| | / |
| | / |
| | / |
| |V |
----- | |
|\ |
| \ |
|\ \ |
| \ \ |
|\ \ \ |
w = window = 3 | \ \ *| retransmission(n+1) rx=1
r = retention = 1 | \ \ |
| \ V| data(n+w)
| \ |
| V| data(n+2w-1-rx) w/eow rx=1
| |
| /| nak(n') of n+1
| / |
----- | / |
|\ / |
| / |
|V \ |
|\ \ |
| \ \ |
|\ \ V| data(n+2w-rx) rx=1
| \ \ | Packets n..n+w-1-0 can be released.
| \ \ |
| \ V| nak deny(n+1) rx=2
| \ |
| V| data(n+3w-1-rx) w/eom rx=2
| |
----- | | Packets n+w..n+2w-1-1 are released.
----- | | 「再-トランスミッション」カウント=rx=0| |\ | | | \ | | |\ \ | | | \ \ | | |\ \ \ | | | \\V| データ(n)| | \ \ | | \ *| データ(n+1)鼓動| \ | | V| eow rx=0があるデータ(n+w-1-rx)| | | | | /| 'n+1のnak(n')| | / | | | / | | | / | | | / | | |V| ----- | | |\ | | \ | |\ \ | | \ \ | |\ \ \ | w=窓=3| \ \ *| 「再-トランスミッション」(n+1)rx=1r=保有=1| \ \ | | \V| データ(n+w)| \ | | V| eow rx=1があるデータ(n+2w-1-rx)| | | /| 'n+1のnak(n')| / | ----- | / | |\ / | | / | |V\| |\ \ | | \ \ | |\\V| データ(n+2w-rx)rx=1| \ \ | パケットn.。n+w-1-0をリリースできます。 | \ \ | | \V| nakはrx=2を否定します(n+1)。| \ | | V| eom rx=2があるデータ(n+3w-1-rx)| | ----- | | パケットn+w.。n+2w-1-1はリリースされます。
Figure 10. naks and retransmission
図10 naksと「再-トランスミッション」
Armstrong, Freier & Marzullo [Page 28] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[28ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
3.2.7. Duplicate suppression
3.2.7. 抑圧をコピーしてください。
The consumer must be prepared to ignore duplicate packets received. They will invariably be the result of the producer's retransmission in response to another consumer's nak.
消費者はパケットが受け取った写しを無視する用意ができていなければなりません。 それらは不変的に別の消費者のnakに対応したプロデューサーの「再-トランスミッション」の結果になるでしょう。
3.2.8. Banishment
3.2.8. 追放
If at any time a process detects another in violation of the protocol it may ask the offending process to withdraw from the web by unicasting to it a quit[request] that has the target field set to the value of the offender's TSAP. Any member that exhibits a detectable and recoverable protocol violation and still responds willingly to the quit[request] will be noted as having truly correct social behavior.
過程がいつでもそれが、怒っている過程がウェブからそれにunicastingすることによって引き下がるように頼むかもしれないプロトコルを違反して別のものを検出するなら、犯罪者のTSAPの値に目標分野を設定するaはやめました[要求します]。 検出可能で回復可能なプロトコル違反を示して、まだ辞任に喜んで応じている[要求します]どんなメンバーも本当に正しい社会的な振舞いを持っているとして注意されるでしょう。
0 7 8 15 16 23 24 31
---------------------------------------------------------- -----
| protocol | packet | type | client | |
| version | type | modifier | channel | |
---------------------------------------------------------- |
| | |
| source connection identifier | |
---------------------------------------------------------- |
| | |
| destination connection identifier |
---------------------------------------------------------- transport
| | header
| message acceptance criteria |
---------------------------------------------------------- |
| | |
| heartbeat | |
---------------------------------------------------------- |
| | | |
| window | retention | |
---------------------------------------------------------- -----
| |
| target TSAP |
| |
----------------------------------------------------------
0 7 8 15 16 23 24 31 ---------------------------------------------------------- ----- | プロトコル| パケット| タイプ| クライアント| | | バージョン| タイプ| 修飾語| チャンネル| | ---------------------------------------------------------- | | | | | ソース接続識別子| | ---------------------------------------------------------- | | | | | 目的地接続識別子| ---------------------------------------------------------- 輸送| | ヘッダー| メッセージ合否基準| ---------------------------------------------------------- | | | | | 鼓動| | ---------------------------------------------------------- | | | | | | 窓| 保有| | ---------------------------------------------------------- ----- | | | 目標TSAP| | | ----------------------------------------------------------
Figure 11. quit packet
図11 パケットをやめてください。
3.3 Terminating the transport
3.3 輸送を終えること。
Transport termination is an advisory process that may be initiated by any member of the web. No process should intentionally quit the web while it has retransmittable data buffered. Stations should make
輸送終了はウェブのどんなメンバーによっても着手されるかもしれない顧問過程です。 どんな過程も故意にそれでretransmittableデータをバッファリングしている間、ウェブをやめるべきではありません。 駅は利かせるべきです。
Armstrong, Freier & Marzullo [Page 29] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[29ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
every reasonable attempt advise the master of their intentions to withdraw, as their departure may collapse the topology of the web and eliminate the need to carry multicast messages across network boundaries.
あらゆる合理的な試みが引き下がるという彼らの意志をマスターに知らせます、彼らの出発がウェブのトポロジーを潰して、ネットワーク限界の向こう側にマルチキャストメッセージを伝える必要性を排除するとき。
3.3.1. Voluntary quits
3.3.1. 自発的である、五分五分
Voluntary quit[requests] are unicast to the master's TSAP. When the master receives a quit from a member of the web, it responds with a quit[confirm] packet. At that time the member will be formally removed from the web. The request should be retransmitted at heartbeat intervals until the confirmation is received from the master or as many times as the web's value of retention.
自発的である、やめられているのは[要求]、マスターのTSAPへのユニキャストです。 マスターがウェブのメンバーからやめられたaを受けるとき、aがやめられている状態で、それは[確認します]パケットを反応させます。 その時、ウェブからメンバーを正式に免職するでしょう。 要求はマスターから確認を受け取るまでの鼓動間隔か同じくらい何回もウェブの保有の値として再送されるべきです。
3.3.2. Master quit
3.3.2. マスターはやめました。
If the master initiates the transport termination it effects all members of the web. The master will retain all transmit tokens and refuse to assign them. Once the tokens are acquired, the master will multicast a quit[request] to the entire web. That request should be acknowledged by every active member. When the master receives no confirmations for retention transmissions, it may assume every member has terminated its transport and then may follow suit.
マスターが輸送終了を開始するなら、それはウェブのすべてのメンバーに作用します。 意志が保有するマスターは、象徴をすべて伝えて、それらを割り当てるのを拒否します。 象徴がいったん後天的になると、マスターはaが全体のウェブにやめた[要求します]マルチキャストが後天的でしょう。 その要求はすべての活動的なメンバーによって承諾されるべきです。 マスターが保有送信のための確認を全く受け取らないとき、それは、すべてのメンバーが輸送を終えて、次に、先例に倣うかもしれないと仮定するかもしれません。
3.3.3. Banishment
3.3.3. 追放
If the master receives any message other than a join[request] from a member that it does not recognize, it should transmit a quit[request] with that process as a target. This covers cases where the consumer did not see the termination reply and retransmitted its original quit request, as well as unannounced and rejected consumers.
マスターが何かaを除いたメッセージを受け取るなら、メンバーからの目標としてその過程でやめられた[要求します]aを伝えるべきであると認めないという[要求]を接合してください。 これは消費者が終了回答を見ないで、再送されて、オリジナルが要求をやめたケースをカバーしています、公言なしの、そして、拒絶された消費者と同様に。
3.4 Transport parameters
3.4 輸送パラメタ
The following section provides guidelines and rationale for selecting reasonable transport quality of service parameters. It also describes some of the reasoning behind the ranges of values presented.
以下のセクションは妥当な輸送サービスの質パラメタを選択するのにガイドラインと原理を提供します。 また、それは後ろでの値の範囲が提示した何らかの推理について説明します。
3.4.1. Quality of service
3.4.1. サービスの質
Active members of the web may suggest changes in the transport's quality of service parameters during the lifetime of the transport. Producers in general adjust the transport's parameters to encourage a higher level of throughput. Since consumers are responsible for certifying reliable delivery, it is expected that they will provide the force encouraging more reliability and stability. Both are trying to optimize the quality of service. The negotiation that took place when members joined the web included the clients' desires with
ウェブの活動的なメンバーは輸送の生涯輸送のサービスパラメタの品質における変化を勧めるかもしれません。 一般に、プロデューサーは、より高いレベルに関するスループットを奨励するように輸送のパラメタを調整します。 消費者は信頼できる配信を公認するのに責任があるので、彼らが、より多くの信頼性と安定性を奨励しながら力を供給すると予想されます。 両方がサービスの質を最適化しようとしています。 それがメンバーが加わったときウェブがクライアントの願望を含んだ場所を取った交渉
Armstrong, Freier & Marzullo [Page 30] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[30ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
regards to the worst case behavior that will be tolerated. If a member cannot maintain the negotiated lower bound, it may asked to withdraw from the web. That process will be sent a unicast message (quit[request]) indicating that it should retire. There are essentially three parameters maintained by the transport that reflect the client's quality of service requirements: heartbeat, window and retention. These three parameters can be adapted by the transport to reflect the capability of the members, the type of application being supported and the network topology. When members join the web, they suggest values for the quality of service parameters to the master. If the parameters are acceptable, the master will respond with the web's current operating values. During the lifetime of the web, it is expected that the parameters be modified by its members, though they may never result in a quality of service less than the lower bounds established by the joining procedure. Producers may try to improve performance by reducing the heartbeat interval and increasing the window size. This will have the effect of increasing the resources committed to the transport at any time. In order to keep the resources under control, the producer may also reduce the retention.
最悪への尊敬は許容される振舞いをケースに入れます。 メンバーが交渉された下界を維持できないなら、ウェブから引き下がるように頼まれて、それは維持します。 それが退職するべきであるのを示すユニキャストメッセージ(やめます[要求する])をその過程に送るでしょう。 本質的には、クライアントのサービスの質要件を反映する輸送で維持された3つのパラメタがあります: 鼓動、窓、および保有。 メンバーの能力、支持されるアプリケーションのタイプ、およびネットワーク形態を反映するために輸送でこれらの3つのパラメタを適合させることができます。 メンバーがウェブに加わるとき、彼らはサービスの質パラメタのために値をマスターに示します。 パラメタが許容できると、マスターはウェブの現在の操作値で応じるでしょう。 ウェブの生涯、パラメタがメンバーによって変更されると予想されます、彼らは接合手順で確立された下界よりサービスの質を決してもたらさないかもしれませんが。 プロデューサーは鼓動間隔を短縮して、ウィンドウサイズを増加させるのによる性能を向上させようとするかもしれません。 これで、いつでも、リソースを増加させるという効果を輸送に心がけるでしょう。 また、リソースを抑えるために、プロデューサーは保有を抑えるかもしれません。
Consumers must rely on their clients to consume the data occupying the resources of the transport. To do so the consumer transport implementation must monitor the level of committed resources to insure that it does not exceed its capabilities. Since MTP is a NAK based protocol, the consumer is required to tell the producer if a change in parameters is required. The new information must be delivered to the producer(s) before the consumer's resource situation becomes critical in order to avoid missing data.
消費者は、輸送に関するリソースを占領するデータを消費するために彼らのクライアントに頼らなければなりません。 そう消費者輸送実現をするのは、能力を超えていないのを保障するために遂行されたリソースのレベルをモニターしなければなりません。 MTPがNAKのベースのプロトコルであるので、消費者は、パラメタにおける変化が必要であるかどうかプロデューサーに言わなければなりません。 消費者のリソース状況が欠測値を避けるために批判的になる前に新情報をプロデューサーに送らなければなりません。
For more stable operation, consumers would try to extend the heartbeat interval and reduce the window. To a certain degree, they could also attempt to reduce the value of retention in order to reduce the amount of resources required to support the transport. However, that requires a more stringent real-time capability.
より安定した操作のために、消費者は、鼓動間隔を延ばして、窓を減少させようとするでしょう。 また、ある程度、彼らは、輸送を支持するのに必要であるリソースの量を減少させるために保有の値を減少させるのを試みるかもしれません。 しかしながら、それは、より厳しいリアルタイムの能力を必要とします。
3.4.2. Selecting parameter values
3.4.2. パラメタ値を選択します。
The value of heartbeat is approximately the transport time constant. Assuming that the transport can be modelled as a closed loop system function, reaction to feedback into the transport should settle out in three time constants. In a transport that is constrained to a single network, the dominant cause of processing delay of the transport will most likely be page fault resolution time.
鼓動の値は輸送およそ時定数です。 クローズドループシステム機能として輸送をモデル化できると仮定する場合、輸送へのフィードバックへの反応は3つの時定数で安定するべきです。 ただ一つのネットワークに抑制される輸送では、輸送の処理遅れの主因はたぶんページフォールト時間分解能です。
For example, using a one MIP processor on a ethernet and an industry standard disk, the worst case page fault resolution requiring two seeks (one to write out a dirty page, another to swap in the new page) and an average seek time of 40 milliseconds, page fault
例えば、イーサネットの1台のMIPプロセッサと業界基準ディスクを使用して、2を必要とする最悪の場合ページフォールト決議は(汚いページ、新しいページでスワップする別のものを書き上げる1)と40ミリセカンドの平均したシーク時間を求めます、ページフォールト
Armstrong, Freier & Marzullo [Page 31] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[31ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
resolution should be less than 80 milliseconds. Allowing for some additional overhead and scheduling delays, two times the worst case page fault resolution time would appear to be the minimum suitable transport time constant one could expect. So,
解決は80ミリセカンド未満であるべきです。 何らかの追加オーバーヘッドを考慮して、遅れの計画をして、最悪の場合ページフォールト時間分解能の2回はものが予想できた最小の適当な輸送時定数であるように見えるでしょう。 そのように
Heartbeat (minimum) = 160 - 200 milliseconds.
160--200鼓動(最小の)=ミリセカンド。
The transmit time for a full (ethernet) packet is approximately 1.2 milliseconds. Processing time should be less than 3 milliseconds (ignoring possible overlapped processing). Assuming disk access (with no faulting) is equivalent, and the total time per packet is the sum of the parts, or 8.4 milliseconds. Therefore, the theoretical maximum value would be approximately 17 packets per heartbeat. The transport should be capable of approximately 120 packets per second, or 19.2 packets per heartbeat.
パケットが満(イーサネット)のためのおよそ1.2ミリセカンドである時を伝えてください。 処理時間は3ミリセカンド未満(可能な重ね合わせられた処理を無視して)であるべきである。 1パケットあたりの合計時は、ディスクアクセス(とがめのない)を仮定するのが同等であり、部分の合計、または8.4ミリセカンドです。 したがって、1鼓動あたり理論上の最大値はおよそ17のパケットでしょう。 輸送は1秒あたりおよそ120のパケット、または1鼓動あたり19.2のパケットができるべきです。
Window (maximum) = 17 - 20 packets per heartbeat.
窓(最大)は1鼓動あたり17--20のパケットと等しいです。
The (theoretical) throughput with these parameters in effect is 180 kilobytes per second.
これらのパラメタが有効の(理論上)のスループットは1秒あたり180キロバイトです。
Reducing retention may introduce instability because the consumers will have less opportunity to react to missing data. Data can be missed for a variety of reasons. If constrained to the local net the data lost due to data link corruption should be in the neighborhood of one packet in every 50,000 (bit error rate of approximately 10-9). Telephony links (between routers, for instance) exhibit similar characteristics. Several orders of magnitude more packets are lost at receiving processes, including packet switch routers, than over the physical links. The losses are usually a result of congestion and resource starvation at lower layers due to the processing of (nearly) back to back packets. The incidental packet loss of this type is virtually unavoidable. One can only require that a receiving process be capable of receiving some number of back to back packets successfully, and that number must be at least greater then the value of window. And beyond that the probability of success can be made as close to unity as required by providing the receiver the opportunity to observe the data multiple times.
保有を抑えると、消費者には欠測値に反応するより少ない機会があるので、不安定性は導入されるかもしれません。 さまざまな理由でデータを逃すことができます。 ローカルのネットに抑制されるなら、データ・リンク不正のため失われたデータがあらゆる5万(およそ10-9のビット誤り率)のうちの1つのパケットの近所にあるべきです。 電話リンク(例えばルータの間で)は同様の特性を示します。 パケット交換機ルータを含んでいて、より多くのパケットが受けるところで無くならせる数桁は物理的なリンクより処理されます。 通常、損失はパケットを支持する(ほとんど)後部の処理による下層における混雑とリソース飢餓の結果です。 このタイプの付帯的なパケット損失は実際には避けられません。 人は受信の過程が首尾よく何らかの数の背中合わせのパケットを受けることができて、数がそしてときに少なくとも大きくなければならないのを必要とすることができるだけです。窓の値。 そして、それを超えて、必要に応じて統一の同じくらい近くで複数の回データを観測する機会を受信機に供給することによって、成功の確率を作ることができます。
The receiving process must detect packet loss. The simplest method is to notice gaps in the received message/packet sequence numbers. Such detection should be done after receiving an end of window or other state transition indication. As such, the naks cannot be transmitted, let alone received, until the following heartbeat. In order to not have any single packet loss cause transport failure, the naks should have the opportunity to be transmitted at least twice.
受信の過程はパケット損失を検出しなければなりません。 最も簡単な方法は容認されたメッセージ/パケット一連番号におけるギャップに気付くことです。 窓か他の状態遷移指示の終わりを得た後に、そのような検出をするべきです。 そういうものとして、以下の鼓動まで受け取って、naksを伝えることができません。 少しのただ一つのパケット損失原因輸送失敗も持たないように、naksには少なくとも二度伝えられるべき機会があるはずです。
When the loss is detected, the nak must be transmitted and should be
損失が検出されるとき、nakは伝えなければならなくて、あるはずです。
Armstrong, Freier & Marzullo [Page 32] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[32ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
received at the producing process in less than two heartbeats after the data it references was transmitted. Again, it is the detection time that dominates, not the transmission of the nak.
生産の過程では、それが参照をつけるデータが送られた後に2回未満の鼓動で受け取られています。 一方、nakのトランスミッションではなく、支配される検出時間です。
Retention (minimum) = 3.
保有(最小の)=3。
The resources committed to a producing transport using the above assumptions are buffers sufficient for 80 packets of 1500 bytes each. Each buffer will be committed for 600 - 800 milliseconds.
上の仮定を使用することで生産輸送に心がけるリソースはそれぞれ1500バイトの80のパケットに十分なバッファです。 各バッファは600--800ミリセカンドと同じくらい遂行されるでしょう。
Transports that span multiple networks have unique problems. One such problem is that if a router drops a packet, all the processes on the remote network may attempt to send a nak[request] at the same time. That is not likely to enhance the router's quality of service. Furthermore, it is obvious that any one nak[request] will suffice to prompt the producer to retransmit the desired packet. To reduce the number of nak[requests] in this situation, the following scheme might be employed.
複数のネットワークにかかる輸送がユニークな問題を持っています。そのような問題の1つはルータがパケットを落とすなら、リモートネットワークのすべての過程が、同時にnak[要求する]を送るのを試みるかもしれないということです。 それはルータのサービスの質を高めそうにはありません。 その上、どんなnak[要求する]もプロデューサーが必要なパケットを再送するようにうながすために十分であるのは、明白です。 この状況における、nak[要求]の数を減少させるために、以下の計画は使われるかもしれません。
First, extend the value of retention to a minimum value of N. Then use a randomizing function that returns a value between zero and N - 2, choose how many heartbeat intervals to dally before sending the nak[request], thus spreading out the transmissions over time. In order for the method to be meaningful, the minimum value of retention must be adjusted.
最初に、保有の値をN.の最小値まで広げてください。ThenはゼロとN--2の間に値を返すランダム化機能を使用します、nak[要求する]を送る前にいくつの鼓動間隔をぶらぶらつぶすかを選んで、その結果、時間がたつにつれて、トランスミッションを広げます。 重要になる方法の注文では、保有の最小値を調整しなければなりません。
Retention (minimum) = 5 (for internet cases)
保有(最小の)=5(インターネットケースのための)
3.4.3. Caching member information
3.4.3. メンバー情報をキャッシュします。
In order to reduce transport member interaction and to enhance performance, a certain amount of caching should be employed by producing members. These caches may be filled by gleaning information from reliable sources such as multicast data or, when all else fails, from responses solicited from the web's master by use of the isMember[request]. IsMember[request] requests are unicast to a member that is believed to have an accurate state of the web, at least to the degree that it can answer the question posed. The destination of such a message is usually the master. But in cases where a process (such as the master) wants to verify that a process believes itself to be valid, it can assign the target TSAP and the destination to be the same. It is assumed that every process can verify itself.
輸送メンバー相互作用を減少させて、性能を高めるために、ある量のキャッシュがメンバーを生産することによって、使われるべきです。 これらのキャッシュがマルチキャストデータなどの信頼すべき筋からの落ち穂拾い情報によっていっぱいにされるかもしれませんか、またはすべてほかのいつが失敗するか、isMember[要求する]の使用でウェブのマスターから請求された応答から。 IsMember[要求する]要求はウェブの正確な状態を持っていると信じられているメンバーへのユニキャストです、少なくとも提出された質問に答えることができるという度合いに。 通常、そのようなメッセージの目的地はマスターです。 しかし、過程(マスターなどの)が、過程が、それ自体が有効であると信じていることを確かめたがっている場合では、それは、同じになるように目標TSAPと目的地を割り当てることができます。 あらゆる過程がそれ自体について確かめることができると思われます。
If the member receiving the isMember[request] can confirm the target's active membership status in the web, it responds with a unicast isMember[confirm]. The data field contains the credibility value of the confirmation, that is the time (in milliseconds) since the information was confirmed from a reliable source.
isMember[要求する]を受け取るメンバーがウェブにおける目標のアクティブな会員資格状態を裏付けることができるなら、それはユニキャストisMember[確認する]と共に応じます。 データ・フィールドはすなわち、確認の値、情報が信頼すべき筋から確認されて以来の時間(ミリセカンドによる)、真実性を含んでいます。
Armstrong, Freier & Marzullo [Page 33] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[33ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
Caches are risky as the information stored in them can become stale. Consequently, with only a few exceptions, the entries should be aged, and when sufficiently old, discarded. Ideally they may be renewed by the same gleanable sources alluded to in the previous paragraph. If not, they are simply discarded and refilled when needed.
それらに格納された情報が聞き古したであるなることができるので、キャッシュは危険です。 ほんのいくつかの例外で、その結果、エントリー老いるべきであり、いつが、十分古く、捨てられるか。 理想的に、それらは前のパラグラフで暗示された同じ収集可能ソースによって更新されるかもしれません。 そうでなければ、単に捨てられて、必要であると、それらは、詰め替えられます。
Web membership may be gleaned from any packet that does not have a value of unknown as the destination connection identifier. A producing transport may extract the TSAP from such packets and either create or refresh local caches. Then, if in the process of transmitting and NAK is received from one of the members whose identity is cached, no explicit request will be needed to verify the source's membership.
ウェブ会員資格は目的地接続識別子として未知の値を持っていないどんなパケットからも収集されるかもしれません。 生産輸送は、ローカルなキャッシュをそのようなパケットからTSAPを抽出して、作成するか、またはリフレッシュするかもしれません。 そして、受け取られたメンバーの一人からのアイデンティティがキャッシュされる伝えるのとNAKの途中にどんな明白な要求も、ソースの会員資格について確かめるのに必要でないでしょう。
The explicit source of membership information is the master. Information can be requested by using the isMember message. Information gathered in that manner should be treated the same as gleaned information with respect to aging.
会員資格情報の明白な源はマスターです。 isMemberメッセージを使用することによって、情報を要求できます。 そんなふうに集められた情報は年をとるのに関して同じように収集された情報として扱われるべきです。
The aging is a function of the transport's time constant, or heartbeat, and the retention. Information about a producing member must be cached at least as long as that producer has incomplete messages. It may be cached longer. The namespace for both sequence numbers and connection identifiers is intentionally long to insure that reuse of those namespaces will not likely collide.
年をとるのは、輸送の時定数の関数か、鼓動と、保有です。 そのプロデューサーには不完全なメッセージがあるのと少なくとも同じくらい長い間、生産しているメンバーに関する情報をキャッシュしなければなりません。 それは、より長い間、キャッシュされるかもしれません。 一連番号と接続識別子の両方のための名前空間は、それらの名前空間の再利用がおそらく衝突しないのを保障するために故意に長いです。
A. Appendix: MTP as an Internet Protocol transport
A。 付録: インターネットプロトコル輸送としてのMTP
MTP is a transport layer protocol, designed to be layered on top of a number of different network layer protocols. Such a protocol must provide certain facilities that MTP expects. In particular, the underlying network level protocol must provide "ports" or "sockets" to facilitate addressing of processes within a machine, and a mechanism for multicast addressing of datagrams. These two addressing facilities are also used to formulate the NSAP for MTP on IP.
MTPは多くの異なったネットワーク層プロトコルの上で層にされるように設計されたトランスポート層プロトコルです。 そのようなプロトコルはMTPが予想するある施設を提供しなければなりません。 特に、基本的なネットワークレベルプロトコルは、マシンの中の過程のアドレシング、およびデータグラムのマルチキャストアドレシングのためのメカニズムを容易にするために「ポート」か「ソケット」を提供しなければなりません。また、施設を記述するこれらの2もMTPのためにIPでNSAPを定式化するのにおいて使用されています。
A.1 Internet Protocol multicast addressing
A.1インターネットプロトコルマルチキャストアドレシング
MTP on Internet Protocol uses the Internet Protocol multicast mechanisms defined in RFC 1112, "Host Extensions for IP Multicasting". MTP requires "Level 2" conformance described in that paper, for hosts which need to both send and receive multicast packets, both on the local net and on an internet. MTP on Internet Protocol uses the permanent host group address 224.0.1.9.
インターネットプロトコルのMTPはRFC1112で定義されたインターネットプロトコルマルチキャストメカニズム、「IPマルチキャスティングのためのホスト拡大」を使用します。 MTPは「2インチの平らな順応は、ホストのためのその紙でどれがともにマルチキャストパケットを送って、受ける必要であるかを説明しました、ローカルのネットの上と、そして、インターネットの上の両方」を必要とします。 インターネットプロトコルのMTPは永久的なホストグループアドレス224.0.1.9を使用します。
Armstrong, Freier & Marzullo [Page 34] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[34ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
A.2 Encapsulation
A.2カプセル化
The Internet Protocol does not provide a port mechanism - ports are defined at the transport level instead. In order to encapsulate MTP packet within Internet Protocol packets, a simple convergence or "bridge" protocol must be defined to run on top of Internet Protocol, which will provide MTP with the mechanism needed to deliver packets to the proper processes. We will call this protocol the "MTP/Internet Protocol Bridge Protocol", or just "Bridge". The protocol header is encapsulated the Internet Protocol data - the protocol field of the Internet Protocol packet carries the value indicating this packet is an MTP packet (92 decimal). The MTP packet itself is encapsulated in the Bridge data. Figure A.1 shows the positions of the fields within the MTP packet while table A.1 defines the contents of those fields.
インターネットプロトコルはポートメカニズムを提供しません--ポートは代わりに輸送レベルで定義されます。 インターネットプロトコルパケットの中でMTPパケットをカプセルに入れって、インターネットプロトコルの上を走るために簡単な集合か「橋」プロトコルを定義しなければなりません。プロトコルは適切な過程にパケットを届けるのが必要であるメカニズムをMTPに提供するでしょう。 私たちは、このプロトコルを「MTP/インターネットプロトコル橋のプロトコル」、またはまさしく「橋」と呼ぶつもりです。 プロトコルヘッダーはカプセルに入れられます。インターネットプロトコルデータ--このパケットがMTPパケット(92小数)であることを示しながら、インターネットプロトコルパケットのプロトコル分野は値を運びます。 MTPパケット自体はBridgeデータでカプセルに入れられます。 テーブルA.1はそれらの分野のコンテンツを定義しますが、図A.1はMTPパケットの中に分野の位置を示しています。
A.3 Fields of the bridge protocol
橋のプロトコルのA.3分野
0 7 8 15 16 23 24 31
----------------------------------------------------------
| | |
| destination port | source port |
----------------------------------------------------------
| | |
| length | checksum |
----------------------------------------------------------
| |
| client data |
----------------------------------------------------------
0 7 8 15 16 23 24 31 ---------------------------------------------------------- | | | | 仕向港| ソース港| ---------------------------------------------------------- | | | | 長さ| チェックサム| ---------------------------------------------------------- | | | クライアントデータ| ----------------------------------------------------------
Figure A.1 MTP bridge protocol header fields
図A.1 MTP橋のプロトコルヘッダーフィールド
destination port The port to which the packet is destined or sinked.
目的地はパケットが運命づけられているか、またはsinkedされるポートを移植します。
source port The port from which the packet originates or is sourced.
ソースは出典を明示されていた状態でパケットが由来するか、または来ているポートを移植します。
length The length in octets of the bridged packet, including
header and all data (the MTP packet). The minimum value
in this field is 8, the maximum is 65535. The length
does not include any padding bytes that were used to
compute the checksum. Note that though this field allows
for very long packets, most networks have significantly
shorter maximum frame sizes - the allowable and optimal
packet size must be determined by means beyond the scope
of this specification.
長さはヘッダーとすべてのデータ(MTPパケット)を含む橋を架けられたパケットの八重奏で長さです。 この分野の最小値が8である、最大は65535です。 長さはチェックサムを計算するのに使用されたどんな詰め物バイトも含んでいません。 この分野が非常に長いパケットを考慮しますが、ほとんどのネットワークにはかなり短い最大のフレーム・サイズがあることに注意してください--この仕様の範囲を超えた手段で許容できて最適のパケットサイズを決定しなければなりません。
checksum The 16 bit one's compliment of the one's compliment sum
of the entire bridge protocol header and data, padded
チェックサム、人のものが賞賛する16ビット、全体の橋の1つの賛辞合計は、ヘッダーとデータについて議定書の中で述べて、そっと歩きました。
Armstrong, Freier & Marzullo [Page 35] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[35ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
with a zero octet (if necessary) to make multiple 16 bit
quanities. A computed checksum of all zeros should be
changed to all ones. The checksum field is optional -
all zeros in the field indicate that checksums are not in
use.
ゼロで、(必要なら、)複数の16を作る八重奏はquanitiesに噛み付きました。 すべてのゼロの計算されたチェックサムはすべてのものに変わるべきです。 チェックサム分野は任意です--その分野のすべてのゼロが、チェックサムが使用中でないことを示します。
data The data field is the field that carries the actual
transport data. A single MTP packet will be carried the
data field of each bridge packet.
データがさばくデータは実際の輸送データを運ぶ分野です。 単一のMTPパケットによる運ばれて、それぞれのデータ・フィールドがパケットに橋を架けるということでしょう。
A.4 Relationship to other Internet Protocol Transports
他のインターネットプロトコルTransportsとのA.4関係
The astute reader might note that the MTP/Bridge Protocol looks much like the User Datagram Protocol (UDP). UDP itself was not used because the protocol field in the Internet Protocol packet should reflect the fact that the higher level protocol of interest is MTP.
抜け目のない読者は、MTP/橋のプロトコルがユーザー・データグラム・プロトコル(UDP)に非常に似ていることに注意するかもしれません。 インターネットプロトコルパケットのプロトコル分野が興味があるより高い平らなプロトコルがMTPであるという事実を反映するべきであるので、UDP自身は使用されませんでした。
References
参照
AFM91 Armstrong, S., A. Freier and K. Marzullo, "MTP: An Atomic
Multicast Transport Protocol", Xerox Webster Research Center
technical report X9100359, March 1991.
AFM91アームストロング、S.、A.フライアとK.Marzullo、「MTP:」 「Atomic Multicast Transportプロトコル」、ゼロックスウェブスターResearchセンター技術報告書X9100359、1991年3月。
Bog83 Boggs, D., "Internet Broadcasting", Xerox PARC technical
report CSL-83-3, October 1983.
Bog83ボッグズ、D.、「インターネット放送」、ゼロックスPARC技術報告書CSL-83-3、1983年10月。
BSTM79 Boggs, D., J. Shoch, E. Taft, and R. Metcalfe, "Pup: An
Internetwork Architecture", IEEE Transactions on
Communications, COM-28(4), pages 612-624. April 1980.
BSTM79ボッグズ、D.、J.Shoch、E.タフト、およびR.メトカルフェ、「産んでください」 「Internetwork Architecture」、Communications、COM-28(4)、612-624ページのIEEE Transactions。 1980年4月。
DIX82 Digital Equipment Corp., Intel Corp., Xerox Corp., "The
Ethernet, a Local Area Network: Data Link and Physical Layer
Specifications", September 1982.
DIX82ディジタル・イクイップメント社、インテル社、ゼロックス社、「イーサネット、ローカル・エリア・ネットワーク:」 1982年9月に「データ・リンクと身体検査は仕様を層にします」。
CLZ87 Clark, D., M. Lambert, and L. Zhang, "NETBLT: A high
throughput transport protocol", In Proceedings of ACM SIGCOMM
'87 Workshop, pages 353-359, 1987.
CLZ87クラーク、D.、M.ランバート、およびL.チャン、「NETBLT:」 「高生産性トランスポート・プロトコル」、ACM SIGCOMM87年Workshop、353-359、1987ページのIn Proceedings
CM87 Chang J., and M. Maxemchuck. "Atomic broadcast", ACM
Transactions on Computer Systems, 2(3):251-273, August 1987.
CM87チャンJ.、およびM.Maxemchuck。 「原子放送」、コンピュータシステムズ、2(3)の上のACM Transactions: 251-273と、1987年8月。
Cri88 Cristian, F., "Reaching agreement on processor group
membership in synchronous distributed systems", In
Proceedings of the 18th International Conference on Fault-
Tolerant Computing. IEEE TOCS, 1988.
F. Cri88クリスチャン、「同期分散システムにおけるプロセッサグループ会員資格で合意に達する」Faultの許容性があるComputingの上の第18国際コンファレンスのIn Proceedings。 IEEEトックス、1988。
Dee89 Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
Stanford University, August 1989.
Dee89デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、RFC1112、スタンフォード大学、1989年8月。
Armstrong, Freier & Marzullo [Page 36] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[36ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
Fre84 Freier, A., "Compatability and interoperability", Open letter
to XNS Interest Group, Xerox Systems Developement Division,
December 13, 1984.
Fre84フライアと、A.と、「Compatabilityと相互運用性」(XNS Interest Groupへのオープン手紙)はSystems Developement事業部、1984年12月13日をコピーします。
JB89 Joseph T., and K. Birman, "Reliable Broadcast Protocols",
pages 294-318, ACM Press, New York, 1989.
JB89ジョゼフT.、およびK.バーマン、「信頼できる放送プロトコル」、294-318ページ、ACM Press、ニューヨーク1989。
Pos81 Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", RFC 793, DARPA, September
1981.
Pos81ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」RFC793、DARPA、1981年9月。
Xer81 Xerox Corp., "Internet Transport Protocols", Xerox System
Integration Standard 028112, Stamford, Connecticut. December
1981.
Xer81ゼロックス社、「インターネットトランスポート・プロトコル」、ゼロックスシステムインテグレーション規格028112、スタンフォード、コネチカット。 1981年12月。
Footnotes
脚注
[1] The network layer is not specified by MTP. One of the goals is to specify a transport that can be implemented with equal functionality on many network architectures.
[1] ネットワーク層はMTPによって指定されません。 目標の1つは多くのネットワークアーキテクチャに関する等しい機能性で実装することができる輸送を指定することです。
[2] There's only one such multicast connection identifier per web. If there are multiple processes on the same machine participating in a web, the transport must descriminate between those processes by using the connnection identifier.
[2] そのような接続識別子の1ウェブあたりマルチキャスト1つしかありません。 ウェブに参加する同じマシンの上に複数のプロセスがあれば、輸送はconnnection識別子を使用するのによるそれらのプロセスの間のdescriminateがなければなりません。
[3] Determining the network service access point (NSAP) for a given instantiation of a web is not addressed by this protocol. This document may define some policy, but the actual means are left for other mechanisms.
[3] ウェブの与えられた具体化のために、ネットワークサービスアクセスポイント(NSAP)を決定するのはこのプロトコルによって扱われません。 このドキュメントは何らかの方針を定義するかもしれませんが、実際の手段は他のメカニズムに残されます。
[4] Best effort delivery is also known as highly reliable delivery. It is somewhat unique that the qualifying adjective highly weakens the definition of reliable in this context.
[4] また、ベストエフォート型配送は高信頼性配送として知られています。 資格を得る形容詞がこのような関係においては信頼できることの定義を非常に弱めるのは、いくらかユニークです。
[5] The resource being flow controlled is packets carrying client data. Consequently, full data units provide the greatest efficiency.
[5] 流れであることが制御したリソースはクライアントデータを運ぶパケットです。 その結果、完全なデータ単位は最大級の効率を提供します。
[6] There seems to be an opportunity to suppress retransmissions to networks that were not represented in the set of naks received.
[6] 受け取られたnaksのセットで代表されなかったネットワークに「再-トランスミッション」を抑圧する機会はあるように思えます。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Armstrong, Freier & Marzullo [Page 37] RFC 1301 Multicast Transport Protocol February 1992
アームストロング、フライア、およびMarzullo[37ページ]RFC1301マルチキャストは1992年2月にプロトコルを輸送します。
Authors' Addresses
作者のアドレス
Susan M. Armstrong Xerox Webster Research Center 800 Phillips Rd. MS 128-27E Webster, NY 14580
スーザンM.アームストロングゼロックスウェブスターリサーチセンター800フィリップス通り MS128-27Eウェブスター、ニューヨーク 14580
Phone: (716) 422-6437 EMail: armstrong@wrc.xerox.com
以下に電話をしてください。 (716) 422-6437 メールしてください: armstrong@wrc.xerox.com
Alan O. Freier Apple Computer, Inc. 20525 Mariani Ave. MS 3-PK Cupertino, CA 95014
アランO.フライアアップル・コンピューターInc.20525マリアニAve。 MS3-PKカルパチーノ、カリフォルニア 95014
Phone: (408) 974-9196 EMail: freier@apple.com
以下に電話をしてください。 (408) 974-9196 メールしてください: freier@apple.com
Keith A. Marzullo Cornell University Department of Computer Science Upson Hall Ithaca, NY 14853-7501
キース・A.Marzulloコーネル大学コンピュータサイエンス学部Upson Hallイタケー、ニューヨーク14853-7501
Phone: (607) 255-9188 EMail: marzullo@cs.cornell.edu
以下に電話をしてください。 (607) 255-9188 メールしてください: marzullo@cs.cornell.edu
Keith Marzullo is supported in part by the Defense Advanced
Research Projects Agency (DoD) under NASA Ames grant number NAG
2-593, Contract N00140-87-C-8904. The views, opinions and
findings contained in this report are those of the authors and
should not be construed as an official Department of Defense
position, policy, or decision.
キースMarzulloはNASAエームズ認可番号NAG2-593(Contract N00140 87C8904)の下で国防高等研究計画庁(DoD)によって一部サポートされます。 このレポートに含まれた視点、意見、および調査結果を、作者のものであり、公式の国防総省位置、方針、または決定に理解するべきではありません。
Armstrong, Freier & Marzullo [Page 38]
アームストロング、フライア、およびMarzullo[38ページ]
一覧
スポンサーリンク
