RFC938 日本語訳
0938 Internet Reliable Transaction Protocol functional and interfacespecification. T. Miller. February 1985. (Format: TXT=39478 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Trudy Miller
Request for Comments: 938 ACC
February 1985
コメントを求めるワーキンググループルーディミラーRequestをネットワークでつないでください: 938 ACC1985年2月
Internet Reliable Transaction Protocol
Functional and Interface Specification
インターネットの信頼できるトランザクションプロトコル機能的、そして、インタフェース仕様
STATUS OF THIS MEMO
このメモの状態
This RFC is being distributed to members of the DARPA research community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the DARPA community, they may be interesting to a number of researchers and implementors. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このRFCは、それに含まれた提案への彼らの反応に請求するためにDARPA研究団体のメンバーに分配されています。 議論した問題が直接DARPA共同体の研究課題に関連していないかもしれない間、多くの研究者と作成者にとって、それらはおもしろいかもしれません。 このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。 このメモの分配は無制限です。
ABSTRACT
要約
The Internet Reliable Transaction Protocol (IRTP) is a transport level host to host protocol designed for an internet environment. It provides reliable, sequenced delivery of packets of data between hosts and multiplexes/demultiplexes streams of packets from/to user processes representing ports. It is simple to implement, with a minimum of connection management, at the possible expense of efficiency.
インターネットReliable Transactionプロトコル(IRTP)はレベルがインターネット環境のために設計されたホストプロトコルに主催する輸送です。 それは/からポートを表すユーザ・プロセスまでパケットのホストとマルチプレックス/「反-マルチプレックス」の流れの間にデータの信頼できて、配列されたパケットの配信を提供します。 最小接続と共に効率の可能な費用で管理を実装するのは簡単です。
Miller [Page i]
ミラー[ページi]
RFC 938 February 1985 Internet Reliable Transaction Protocol
RFC938の1985年2月のインターネットの信頼できるトランザクションプロトコル
TABLE OF CONTENTS
目次
INTRODUCTION
序論
1.1 Purpose ......................................... 1
1.2 Underlying Mechanisms ........................... 1
1.3 Relationship to Other Protocols ................. 2
1.1目的… 1 1.2 メカニズムの基礎となります… 1 他のプロトコルとの1.3関係… 2
IRTP HEADERS
IRTPヘッダー
2.1 Header Format ................................... 3
2.2 Packet Type ..................................... 3
2.3 Port Number ..................................... 3
2.4 Sequence Number ................................. 4
2.5 Length .......................................... 4
2.6 Checksum ........................................ 4
2.1 ヘッダー形式… 3 2.2 パケットタイプ… 3 2.3 数を移植してください… 3 2.4一連番号… 4 2.5の長さ… 4 2.6チェックサム… 4
INTERFACES
インタフェース
3.1 User Services Provided By IRTP .................. 5
3.2 IP Services Expected by IRTP .................... 5
3.1 IRTPによって提供されたユーザサービス… 5 3.2 IRTPによって予想されたIPサービス… 5
MODEL OF OPERATION
操作のモデル
4.1 State Variables ................................. 6
4.2 IRTP Initialization ............................. 7
4.3 Host-to-Host Synchronization .................... 7
4.3.1 Response to SYNCH Packets ..................... 7
4.3.2 Response to SYNCH ACK Packet .................. 8
4.4 Transmitting Data ............................... 8
4.4.1 Receiving Data From Using Processes ........... 8
4.4.2 Packet Retransmission ......................... 10
4.5 Receiving Data .................................. 10
4.5.1 Receive and Acknowledgment Windows ............ 11
4.5.2 Invalid Packets ............................... 12
4.5.3 Sequence Numbers Within Acknowledge Window .... 12
4.5.4 Sequence Numbers Within the Receive Window .... 12
4.5.5 Forwarding Data to Using Processes ............ 13
4.1 変数を述べてください… 6 4.2 IRTP初期設定… 7 4.3 ホストからホストとの同期… 7 4.3 同時性パケットへの.1応答… 7 4.3 同時性ACKパケットへの.2応答… 8 4.4 データを送ります… 8 4.4 .1 使用からデータを受け取るのは処理されます… 8 4.4 .2 パケットRetransmission… 10 4.5 データを受け取ります… 10 .1が受け取る4.5と承認Windows… 11 4.5 .2の無効のパケット… 12 4.5 .3の一連番号が中で窓を承認します… 12 4.5 .4の一連番号、中、窓を受けてください… 12 4.5 .5 データを使用に転送するのは処理されます… 13
IMPLEMENTATION ISSUES
導入問題
5.1 Retransmission Strategies ....................... 14
5.2 Pinging ......................................... 14
5.3 Deleting Connection Tables ...................... 16
5.1 Retransmission戦略… 14 5.2 確認します… 14 5.3 接続テーブルを削除します… 16
Miller [Page ii]
ミラー[ページii]
RFC 938 February 1985 Internet Reliable Transaction Protocol
RFC938の1985年2月のインターネットの信頼できるトランザクションプロトコル
LIST OF FIGURES
数字のリスト
Figure 1-1 Relationship of IRTP to Other Protocols . 2
Figure 2-1 IRTP Header Format ...................... 3
Figure 4-1 SYNCH Packet Format ..................... 8
Figure 4-2 SYNCH ACK Packet Format ................. 8
Figure 4-3 DATA Packet Format ...................... 9
Figure 4-4 DATA ACK Packet Format .................. 11
Figure 4-5 PORT NAK Packet Format .................. 11
図1-1 他のプロトコル. 2図2-1IRTPヘッダー形式へのIRTPの関係… 3は4-1 同時性パケット・フォーマットについて計算します… 8は4-2 同時性ACKパケット・フォーマットについて計算します… 8は4-3 データ・パケット形式について計算します… 9は4-4 データACKパケット・フォーマットについて計算します… 11 図4-5はNAKパケット・フォーマットを移植します… 11
ABBREVIATIONS
略語
ICMP Internet Control Message Protocol
IP Internet Protocol
IRTP Internet Reliable Transaction Protocol
RDP Reliable Data Protocol
TCP Transmission Control Protocol
UDP User Datagram Protocol
信頼できるICMPの確実な資料プロトコルTCP通信制御プロトコルUDPインターネット・コントロール・メッセージ・プロトコルIPインターネットプロトコルIRTPインターネットトランザクションプロトコルRDPユーザー・データグラム・プロトコル
Miller [Page iii]
ミラー[ページiii]
RFC 938 February 1985 Internet Reliable Transaction Protocol
RFC938の1985年2月のインターネットの信頼できるトランザクションプロトコル
CHAPTER 1 - INTRODUCTION
第1章--序論
The Internet Reliable Transaction Protocol (IRTP) is a full duplex, transaction oriented, host to host protocol which provides reliable sequenced delivery of packets of data, called transaction packets.
インターネットReliable Transactionプロトコル(IRTP)は全二重です、トランザクション指向しています、データの信頼できる配列されたパケットの配信を提供するプロトコルをホスティングするホスト、呼ばれたトランザクションパケット。
Note: throughout this document the terms host and internet address are used interchangeably.
以下に注意してください。 このドキュメント中では、用語ホストとインターネットアドレスは互換性を持って使用されます。
1.1 Purpose
1.1 目的
The IRTP was designed for an environment in which one host will
have to maintain reliable communication with many other hosts. It
is assumed that there is a (relatively) sporadic flow of
information with each destination host, however information flow
may be initiated at any time at either end of the connection. The
nature of the information is in the form of transactions, i.e.
small, self contained messages. There may be times at which one
host will want to communicate essentially the same information to
all of its known destinations as rapidly as possible.
IRTPはホストが多くの他のホストとの信頼できるコミュニケーションを維持しなければならない環境のために設計されました。 aがあると思われる、(比較的、)、各あて先ホストがいる情報の過疎の流れ、しかしながら、情報流動は接続のどちらの終わりにもいつでも、起こされるかもしれません。 情報の本質がトランザクションの形にありました、すなわち、小さく、自己はメッセージを含みました。 ホストが早急に本質的には同じ情報を知られている目的地のすべてに伝えたくなる回があるかもしれません。
In effect, the IRTP defines a constant underlying connection
between two hosts. This connection is not established and broken
down, rather it can be resynchronized with minimal loss of data
whenever one of the hosts has been rebooted.
事実上、IRTPは2人のホストの間の一定の基本的な接続を定義します。 この接続を、確立されて、破壊しないで、ホストのひとりがリブートされたときはいつも、最小量のデータの喪失でむしろそれを再連動させることができます。
Due to the lack of connection management, it is desirable that all
IRTP processes keep static information about all possible remote
hosts. However, the IRTP has been designed such that minimal state
information needs to be associated with each host to host pair,
thereby allowing one host to communicate with many remote hosts.
接続管理の不足のために、すべてのIRTPプロセスがすべての可能なリモートホストの静的な情報を保つのは、望ましいです。 しかしながら、IRTPは接待する各ホストに関連している最小量の州の情報の必要性が対にされるように、設計されています、その結果、1人のホストが多くのリモートホストとコミュニケートするのを許容します。
The IRTP is more complex than UDP in that it provides reliable,
sequenced delivery of packets, but it is less complex than TCP in
that sequencing is done on a packet by packet (rather than
character stream) basis, and there is only one connection defined
between any two internet addresses (that is, it is not a process
to process protocol.)
それはパケットでパケット(キャラクタストリームよりむしろ)基礎でその配列におけるTCPをするほど複雑ではありません、そして、信頼できて、配列されたパケットの配信を提供するので、IRTPはUDPより複雑ですが、どんな2つのインターネットアドレスの間でも定義された1つの接続しかありません。(すなわち、それはプロトコルを処理するプロセスではありません。)
1.2 Underlying Mechanisms
1.2 基本的なメカニズム
The IRTP uses retransmission and acknowledgments to guarantee
delivery. Checksums are used to guarantee data integrity and to
protect against misrouting. There is a host to host
synchronization mechanism and packet sequencing to provide
duplicate detection and ordered delivery to the user process. A
simple mechanism allows IRTP to multiplex and demultiplex streams
IRTPは、荷渡しを保証するのに「再-トランスミッション」と承認を使用します。 チェックサムは、データ保全を保証して、misroutingから守るのに使用されます。 写し検出と命令された配送をユーザ・プロセスに提供するために同期メカニズムとパケット順序制御を主催するために、ホストがいます。 IRTPは簡単なメカニズムで多重送信できます、そして、「反-マルチプレックス」は流れます。
Miller [Page 1]
ミラー[1ページ]
RFC 938 February 1985 Internet Reliable Transaction Protocol
RFC938の1985年2月のインターネットの信頼できるトランザクションプロトコル
of transaction packets being exchanged between multiple IRTP users
on this host and statically paired IRTP users on the same remote
host.
トランザクションパケットでは、複数のIRTPユーザの間でこのホスト的に静的に交換するのは同じリモートホストとIRTPユーザを対にしました。
1.3 Relationship to Other Protocols
1.3 他のプロトコルとの関係
The IRTP is designed for use in a potentially lossy internet
environment. It requires that IP be under it. The IP protocol
number of IRTP is 28.
IRTPはaにおける使用のために設計されています。潜在的に損失性インターネット環境。 それは、それの下にIPがあるのを必要とします。 IRTPのIPプロトコル番号は28です。
Conversely, IRTP provides a reliable transport protocol for one or
more user processes. User processes must have well-known IRTP
port numbers, and can communicate only with matching processes
with the same port number. (Note that the term port refers to a
higher level protocol. IRTP connections exists between two hosts,
not between a host/port and another host/port.)
逆に、IRTPは信頼できるトランスポート・プロトコルを1つ以上のユーザ・プロセスに提供します。 ユーザ・プロセスは、よく知られるIRTPポートナンバーを持たなければならなくて、同じポートナンバーと共にマッチング過程だけで交信できます。 (移植という用語が、より高い平らなプロトコルを示すことに注意してください。 IRTP接続はホスト/ポートと別のホスト/ポートの間に存在しているのではなく、2人のホストの間に存在しています。)
These relationships are depicted below.
これらの関係は以下に表現されます。
+--------+ +--------+ +-----------+
| port a |....| port x | | TCP users | Application Level
+--------+ +--------+ +-----------+
| | | ... |
+--------------+ +-----------+
| IRTP | | TCP | Host Level
+--------------+ +-----------+
| |
+--------------------------------------+
| Internet Protocol and ICMP | Internet Level
+--------------------------------------+
|
+--------------------------------------+
| Local Network Protocol | Network Level
+--------------------------------------+
+--------+ +--------+ +-----------+ | aを移植してください。|....| ポートx| | TCPユーザ| アプリケーションレベル+--------+ +--------+ +-----------+ | | | ... | +--------------+ +-----------+ | IRTP| | TCP| ホストレベル+--------------+ +-----------+ | | +--------------------------------------+ | インターネットプロトコルとICMP| インターネットレベル+--------------------------------------+ | +--------------------------------------+ | 企業内情報通信網プロトコル| ネットワークレベル+--------------------------------------+
Figure 1-1. Relationship of IRTP to Other Protocols
図1-1。 他のプロトコルへのIRTPの関係
Miller [Page 2]
ミラー[2ページ]
RFC 938 February 1985 Internet Reliable Transaction Protocol
RFC938の1985年2月のインターネットの信頼できるトランザクションプロトコル
CHAPTER 2 - IRTP HEADERS
第2章--IRTPヘッダー
2.1 Header Format
2.1 ヘッダー形式
Each IRTP packet is preceded by an eight byte header depicted
below. The individual fields are described in the following
sections.
それぞれのIRTPパケットは以下に表現された8バイトのヘッダーによって先行されています。 個々の分野は以下のセクションで説明されます。
0 7 8 15 16 31
+--------+--------+--------+--------+
| packet | port | sequence |
| type | number | number |
+--------+--------+--------+--------+
| length | checksum |
| | |
+-----------------+-----------------+
| |
| optional data octets |
+ . . . . . . . . . . . . . . . . . |
0 7 8 15 16 31 +--------+--------+--------+--------+ | パケット| ポート| 系列| | タイプ| 数| 数| +--------+--------+--------+--------+ | 長さ| チェックサム| | | | +-----------------+-----------------+ | | | 任意のデータ八重奏| + . . . . . . . . . . . . . . . . . |
Figure 2-1. IRTP Header Format
図2-1。 IRTPヘッダー形式
2.2 Packet Type
2.2 パケットタイプ
Five packet types are defined by the IRTP. These are:
5つのパケットタイプがIRTPによって定義されます。 これらは以下の通りです。
packet type numeric code
パケットタイプ数字コード
SYNCH 0
SYNCH ACK 1
DATA 2
DATA ACK 3
PORT NAK 4
同時性0同時性ACK1データ2データACK3ポートNAK4
The use of individual packet types is discussed in MODEL OF
OPERATION.
MODEL OF OPERATIONで独特のパケットタイプの使用について議論します。
2.3 Port Number
2.3 ポートナンバー
This field is used for the multiplexing and demultiplexing of
packets from multiple user processes across a single IRTP
connection. Processes which desire to use IRTP must claim port
numbers. A port number represents a higher level protocol, and
data to/from this port may be exchanged only with a process which
has claimed the same port number at a remote host. A process can
claim multiple port numbers, however, only one process may claim
an individual port number. All port numbers are well-known.
この分野はパケットのマルチプレクシングと逆多重化に単独のIRTP接続の向こう側に複数のユーザ・プロセスから使用されます。 IRTPが使用へのそれの願望を要求しなければならないプロセスは数を移植します。 ポートナンバーは、より高い平らなプロトコルを表します、そして、単にリモートホストで同じポートナンバーを要求したプロセスでこのポートからの/へのデータを交換するかもしれません。 プロセスは複数のポートナンバーを要求できて、しかしながら、1つのプロセスだけが個々のポートナンバーを要求するかもしれません。 すべてのポートナンバーが周知のことです。
Miller [Page 3]
ミラー[3ページ]
RFC 938 February 1985 Internet Reliable Transaction Protocol
RFC938の1985年2月のインターネットの信頼できるトランザクションプロトコル
2.4 Sequence Number
2.4 一連番号
For each communicating pair of hosts, there are two sequence
numbers defined, which are the send sequence numbers for the two
ends. Sequence numbers are treated as unsigned 16 bit integers.
Each time a new transaction packet is sent, the sender increases
the sequence number by one. Initial sequence numbers are
established when the connection is resynchronized (see Section
4.3.)
ホストのそれぞれの交信組のために、定義された2つの一連番号があって、どれがあるか、2つの終わりの間、一連番号を送ってください。 一連番号は16ビットの未署名の整数として扱われます。 送付者は新しいトランザクションパケットを送るたびに一連番号を1つ増強します。 接続が再連動するとき、初期シーケンス番号は確立しています。(セクション4.3を見てください。)
2.5 Length
2.5 長さ
The length is the number of octets in this transaction packet,
including the header and the data. (This means that the minimum
value of the length is 8.)
長さはヘッダーとデータを含むこのトランザクションパケットの八重奏の数です。 (これは、長さの最小値が8であることを意味します。)
2.6 Checksum
2.6 チェックサム
The checksum is the 16-bit one's complement of the one's
complement sum of the IRTP header and the transaction packet data
(padded with an octet of zero if necessary to make an even number
of octets.)
チェックサムはIRTPヘッダーの1の補数合計とトランザクションパケットデータの16ビットの1の補数です。(ゼロの八重奏で水増しされて、必要なら、八重奏の偶数を作ります。)
Miller [Page 4]
ミラー[4ページ]
RFC 938 February 1985 Internet Reliable Transaction Protocol
RFC938の1985年2月のインターネットの信頼できるトランザクションプロトコル
CHAPTER 3 - INTERFACES
第3章--インタフェース
3.1 User Services Provided by IRTP
3.1 IRTPによって提供されたユーザサービス
The exact interface to the TRTP from the using processes is
implementation dependent, however, IRTP should provide the
following services to the using processes.
使用プロセスからのTRTPへの正確なインタフェースが実装に依存している、しかしながら、IRTPは使用プロセスに対する以下のサービスを提供するはずです。
o user processes must be able to claim a port number
o ユーザ・プロセスはポートナンバーを要求できなければなりません。
o users must be able to request that data be sent to a
particular port at an internet address (the port must be one
which the user has claimed)
o ユーザは、データがインターネット住所の指定港に送られるよう要求できなければなりません。(ポートはユーザが要求したものであるに違いありません)
o users must be able to request transaction data from a
particular port at any (unspecified) remote internet address
(the port must be one which the user has claimed)
o ユーザはどんな(不特定)のリモートインターネット住所の指定港からも変更用データを要求できなければなりません。(ポートはユーザが要求したものであるに違いありません)
o if a port is determined to be unreachable at a particular
destination, the using process which has claimed that port
should be notified
o ポートが特定の目的地で手が届かないと決心しているなら、そのポートを要求した使用プロセスは通知されるべきです。
In addition to these minimal data transfer services, a particular
implementation may want to have a mechanism by which a
"supervisory" (that is, port independent) module can define
dynamically the remote internet addresses which are legal targets
for host to host communication by this IRTP module. This
mechanism might be internal or external to the IRTP module itself.
これらの最小量のデータ転送サービスに加えて、特定の実装は「管理(すなわち、独立者を移植する)」のモジュールがこのIRTPモジュールでホストのための法的な目標であるリモートインターネットアドレスをダイナミックにホストコミュニケーションと定義できるメカニズムを必要とするかもしれません。 このメカニズムは、IRTPモジュール自体に内部である、または外部であるかもしれません。
3.2 IP Services Expected by IRTP
3.2 IRTPによって予想されたIPサービス
IRTP expects a standard interface to IP through which it can send
and receive transaction packets as IP datagrams. In addition, if
possible, it is desirable that IP or ICMP notify IRTP in the event
that a remote internet address is unreachable.
IRTPはそれがIPデータグラムとしてトランザクションパケットを送って、受けることができるIPに標準インターフェースを予想します。できれば、さらに、リモートインターネットアドレスが手が届かない場合IPかICMPがIRTPに通知するのは、望ましいです。
If the IP implementation (including ICMP) is able to notify IRTP
of source quench conditions, individual IRTP implementations may
be able to perform some dynamic adjustment of transmission
characteristics.
IP実装(ICMPを含んでいる)がソース焼き入れ状態についてIRTPに通知できるなら、個々のIRTP実装はトランスミッションの特性の何らかの動態的調整を実行できるかもしれません。
Miller [Page 5]
ミラー[5ページ]
RFC 938 February 1985 Internet Reliable Transaction Protocol
RFC938の1985年2月のインターネットの信頼できるトランザクションプロトコル
CHAPTER 4 - MODEL OF OPERATION
第4章--操作のモデル
The basic operation of IRTP is as follows. The first time two hosts communicate (or the first time after both have simultaneously failed,) synchronization is established using constant initial sequence numbers (there is a sequence number for each direction of transmission). The TCP "quiet time" is used following reboots to insure that this will not cause inaccurate acknowledgment processing by one side or the other.
IRTPの基本的な操作は以下の通りです。 2人のホストが同期を伝える(または、1両方が同時に失敗した後に回目)1回目は、一定の初期シーケンス番号を使用することで確立されます(トランスミッションの各方向への一連番号があります)。 これが半面かもう片方で不正確な承認処理を引き起こさないのを保障するためにリブートに続いて、TCP「静かな時間」は使用されています。
Once synchronization has been achieved data may be passed in both directions. Each transaction packet has a 16 bit sequence number. Sequence numbers increase monotonically as new packets are generated. The receipt of each sequence number must be acknowledged, either implicitly or explicitly. At most 8 unacknowledged packets may be outstanding in one direction. This number (called MAXPACK) is fixed for all IRTP modules. Unacknowledged packets must be periodically retransmitted. Sequence numbers are also used for duplicate detection by receiving IRTP modules.
同期がいったん達成されると、データは両方の方向に通過されるかもしれません。 それぞれのトランザクションパケットには、16ビットの一連番号があります。 新しいパケットが発生しているのに従って、一連番号は単調に増加します。 それとなくか明らかにそれぞれの一連番号の領収書を受け取ったことを知らせなければなりません。 8つの不承認のパケットが一方向に高々、傑出しているかもしれません。 この数(MAXPACKと呼ばれる)はすべてのIRTPモジュールのために固定されています。 定期的に不承認のパケットを再送しなければなりません。 また、一連番号は、写し検出にIRTPモジュールを受けることによって、使用されます。
If synchronization is lost due to the failure of one of the communicating hosts, after a reboot that host requests the remote host to communicate sequence number information, and data transfer continues.
同期が交信しているホストのひとりの失敗のため失われているなら、リブートの後にそのホストは、一連番号情報を伝えるようリモートホストに要求します、そして、データ転送は続きます。
4.1 State Variables
4.1 州の変数
Each IRTP is associated with a single internet address. The
synchronization mechanism of the IRTP depends on the requirement
that each IRTP module knows the internet addresses of all modules
with which it will communicate. For each remote internet address,
an IRTP module must maintain the following information (called the
connection table):
それぞれのIRTPはただ一つのインターネットアドレスに関連しています。 IRTPの同期メカニズムはそれぞれのIRTPモジュールがそれが交信するすべてのモジュールのインターネットアドレスを知っているという要件によります。 それぞれのリモートインターネットアドレスのために、IRTPモジュールは以下の情報(接続テーブルと呼ばれる)を保守しなければなりません:
rem_addr (32 bit remote internet address)
conn_state (8 bit connection state)
snd_nxt (16 bit send sequence number)
rcv_nxt (16 bit expected next receive sequence number)
snd_una (16 bit first unacknowledged sequence number)
レム_addr(32ビットのリモートインターネットアドレス)コン_州(8ビットの接続状態)のsnd_nxt(噛み付かれた16は一連番号を送る)rcv_nxt(噛み付かれた16は、次に、一連番号を受けるように予想した)snd_una(16ビットの最初の不承認の一連番号)
In addition to maintaining the connection tables defined above, it
is required that every IRTP module have some mechanism which
generates "retransmission events" such that SYNCH packets are
periodically retransmitted for any connection in synch_wait state
(see Section 4.3), and the appropriate DATA packet is periodically
retransmitted for any connection in data_transfer state (see
Section 4.4.2). It is implementation dependent whether this
上で定義された接続テーブルを維持することに加えてあらゆるIRTPモジュールには「「再-トランスミッション」イベント」を生成する何らかのメカニズムがあるのが必要であるので、SYNCHパケットはどんな接続の同調している_待ち状態のためにも定期的に再送されます、そして、(セクション4.3を見てください)適切なDATAパケットはデータ_転送状態でのどんな接続のためにも定期的に再送されます(セクション4.4.2を見てください)。 それが実装に依存している、これ
Miller [Page 6]
ミラー[6ページ]
RFC 938 February 1985 Internet Reliable Transaction Protocol
RFC938の1985年2月のインターネットの信頼できるトランザクションプロトコル
mechanism is connection dependent, or a uniform mechanism for all
connections, so it has not been made part of the connection state
table. See Chapter 5 for more discussion.
メカニズムが接続に依存していてすべての接続のための一定のメカニズムであるので、それは接続ステートテーブルの人工部分ではありません。 より多くの議論に関して第5章を参照してください。
4.2 IRTP Initialization
4.2 IRTP初期設定
Whenever a remote internet address becomes known by an IRTP
process, a 2 minute "quiet time" as described in the TCP
specification must be observed before accepting any incoming
packets or user requests. This is to insure that no old IRTP
packets are still in the network. In addition, a connection table
is initialized as follows:
リモートインターネットアドレスがIRTPプロセスで知られるようになるときはいつも、どんな入って来るパケットやユーザ要求も受け入れる前に、TCP仕様で説明される2分「静かな時間」を観測しなければなりません。 これは、まだネットワークにはどんな古いIRTPパケットもないのを保障するためのものです。 さらに、接続テーブルは以下の通り初期化されます:
rem_addr = known internet address
conn_state = 0 = out-of-synch
snd_nxt = 0
rcv_nxt = 0
snd_una = 0
知られているレム_addr=インターネットはsnd_nxt=0rcv_nxt=0snd_una=0を_が同時性の外で0=と等しいと述べるコンに扱います。
Strictly speaking, the IRTP specification does not allow
connection tables to be dynamically deleted and recreated,
however, if this happens the above procedure must be repeated.
See Chapter 5 for more discussion.
厳密に言うと、IRTP仕様は、接続テーブルがダイナミックに削除されて、再作成されるのを許容しないで、これが起こるなら、しかしながら、上の手順を繰り返さなければなりません。 より多くの議論に関して第5章を参照してください。
4.3 Host-to-Host Synchronization
4.3 ホストからホストとの同期
An IRTP module must initiate synchronization whenever it receives
a DATA packet or a user request referencing an internet address
whose connection state is out-of-synch. Typically, this will
happen only the first time that internet address is active
following the reinitialization of the IRTP module. A SYNCH packet
as shown below is transmitted. Having sent this packet, the host
enters connection state synch_wait (conn_state = 1). In this
state, any incoming DATA, DATA ACK or PORT NAK packets are
ignored. The SYNCH packet itself must be retransmitted
periodically until synchronization has been achieved.
接続状態が同時性の外のことであるインターネットアドレスに参照をつけるDATAパケットかユーザ要求を受け取るときはいつも、IRTPモジュールは同期を開始しなければなりません。 通常、これはIRTPモジュールの再初期化に続いて、インターネットアドレスがアクティブであることの1回目だけに起こるでしょう。 SYNCHパケットは以下に示すように伝えられます。 このパケットを送ったので、ホストは接続州の同時性_待ち(コン_州の=1)に入ります。 この状態、どんな入って来るDATAでも、DATA ACKかPORT NAKパケットが無視されます。 同期が達成されるまで、SYNCHパケット自体を定期的に再送しなければなりません。
4.3.1 Response to SYNCH Packets -
4.3.1 同時性パケットへの応答、-
Whenever a SYNCH packet is received, the recipient, regardless
of current connection state, is required to to return a SYNCH
ACK packet as shown below. At this point the recipient enters
data_transfer state (conn_state = 2).
受け取られていて、受取人がSYNCHパケットがそうであるときはいつも、現在の接続状態にかかわらず必要です。以下に示すようにSYNCH ACKパケットを返すために。 ここに、受取人はデータ_転送状態(コン_州の=2)に入ります。
Miller [Page 7]
ミラー[7ページ]
RFC 938 February 1985 Internet Reliable Transaction Protocol
RFC938の1985年2月のインターネットの信頼できるトランザクションプロトコル
4.3.2 Response to SYNCH ACK Packet -
4.3.2 同時性ACKパケットへの応答、-
On receipt of a SYNCH ACK packet, the behavior of the recipient
depends on its state. If the recipient is in synch_wait state
the recipient sets rcv_nxt to the sequence number value, sets
snd_nxt and snd_una to the value in the two-octet data field,
and enters data_transfer state (conn_state = 2). Otherwise,
the packet is ignored.
SYNCH ACKパケットを受け取り次第、受取人の振舞いは状態に依存します。 受取人が同調している_待ち状態であるなら、受取人は、rcv_nxtを一連番号値に設定して、snd_nxtとsnd_unaを2八重奏のデータ・フィールドの値に設定して、データ_転送状態(コン_州の=2)に入れます。 さもなければ、パケットは無視されます。
0 7 8 15 16 31
+--------+--------+--------+--------+
|00000000|00000000|00000000 00000000|
+--------+--------+--------+--------+
| 8 | checksum |
+-----------------+-----------------+
0 7 8 15 16 31 +--------+--------+--------+--------+ |00000000|00000000|00000000 00000000| +--------+--------+--------+--------+ | 8 | チェックサム| +-----------------+-----------------+
Figure 4-1. SYNCH Packet Format
図4-1。 同時性パケット・フォーマット
0 7 8 15 16 31
+--------+--------+--------+--------+
|00000001| unused | snd_una |
+--------+--------+--------+--------+
| 10 | checksum |
+-----------------+-----------------+
| rcv_nxt |
+-----------------+
0 7 8 15 16 31 +--------+--------+--------+--------+ |00000001| 未使用| snd_una| +--------+--------+--------+--------+ | 10 | チェックサム| +-----------------+-----------------+ | rcv_nxt| +-----------------+
Figure 4-2. SYNCH ACK Packet Format
図4-2。 同時性ACKパケット・フォーマット
4.4 Transmitting Data
4.4 データを送ること。
Once in data_transfer state DATA, DATA ACK and PORT NAK packets
are used to achieve communication between IRTP processes, subject
to the constraint that no more than MAXPACK unacknowledged packets
may be transmitted on a connection at any time. Note that all
arithmetic operations and comparisons on sequence numbers
described in this chapter are to be done modulo 2 to the 16.
_データの一度、転送州のDATA、DATA ACK、およびPORT NAKパケットは、MAXPACKの不承認のパケットがいつでも接続の上に伝えられるだけであるかもしれないという規制を条件としてIRTPプロセスのコミュニケーションを達成するのに使用されます。 本章で説明された一連番号におけるすべての四則演算と比較が法2を16にすることであることに注意してください。
4.4.1 Receiving Data From Using Processes -
4.4.1 プロセスを使用するのからデータを受け取る、-
User processes may request IRTP to send packets of at most 512
user data octets to a remote internet address and IRTP port.
When such a request is received, the behavior of the IRTP
depends on the state of the connection with the remote host and
on implementation dependent considerations. If the connection
ユーザ・プロセスは、高々512の利用者データ八重奏のパケットをリモートインターネットアドレスとIRTPポートに送るようIRTPに要求するかもしれません。 そのような要求が受信されているとき、IRTPの動きはリモートホストとの接続の状態と、そして、実装に依存する問題に依存します。 接続です。
Miller [Page 8]
ミラー[8ページ]
RFC 938 February 1985 Internet Reliable Transaction Protocol
RFC938の1985年2月のインターネットの信頼できるトランザクションプロトコル
between this IRTP module and the remote host is not in
data_transfer state, that state must be achieved (see Section
4.3) before acting on the user request.
このIRTPモジュールとリモートホストの間では、状態はデータ_転送中でなく、ユーザ要求に影響する前に、その状態を獲得しなければなりません(セクション4.3を見ます)。
Once the connection is in data_transfer state, the behavior of
the IRTP module in reaction to a write request from a user is
implementation dependent. The simplest IRTP implementations
will not accept write requests when MAXPACK unacknowledged
packets have been sent to the remote connection and will
provide interested users a mechanism by which they can be
notified when the connection is no longer in this state, which
is called flow controlled. Such implementations are called
blocking IRTP implementations. These implementations check, on
receipt of a write request, to see if the value of snd_nxt is
less than snd_una+MAXPACK. If it is, IRTP prepends a DATA
packet header as shown below, and transmits the packet. The
value of snd_nxt is then incremented by one. In addition, the
packet must be retained in a retransmission queue until it is
acknowledged.
一度、接続がデータ_転送状態(中のaへの反応が実装に依存しているとユーザからの要求に書くIRTPモジュールの振舞い)にあります。 接続がもうどんなこの状態にもないとき、MAXPACKの不承認のパケットがリモート接続に送られて、彼らに通知できるメカニズムを関心があるユーザに提供するとき、実装が受け入れない中で最も簡単なIRTPは要求を書いて、どれが流れと呼ばれるか制御されました。 そのような実装はIRTP実装を妨げると呼ばれます。 aを受け取り次第実装チェックは、これらが、_nxtがsndの値であるならsnd_una+MAXPACK見るためには、以下であるよう要求すると書きます。 それはそうであり、IRTP prependsはDATAパケットのヘッダーです。パケットを下で目立って、伝えるので。 そして、snd_nxtの値は1つ増加されます。 さらに、それが承認されるまで、再送キューでパケットを保有しなければなりません。
0 7 8 15 16 31
+--------+--------+--------+--------+
|00000010|port num| snd_nxt |
+--------+--------+--------+--------+
| length | checksum |
+-----------------+-----------------+
| data octet(s) |
+ . . . . . . . . . . . . . . . . . +
0 7 8 15 16 31 +--------+--------+--------+--------+ |00000010|ポートnum| snd_nxt| +--------+--------+--------+--------+ | 長さ| チェックサム| +-----------------+-----------------+ | データ八重奏| + . . . . . . . . . . . . . . . . . +
Figure 4-3. DATA Packet Format
図4-3。 データ・パケット形式
Other implementations may allow (some number of) write requests
to be accepted even when the connection is flow controlled.
These implementations, called non-blocking IRTP
implementations, must maintain, in addition to the
retransmission queue for each connection, a queue of accepted
but not yet transmitted packets, in order of request. This is
called the pretransmission queue for the connection.
他の実装が許容するかもしれない、(何らかの数、)、制御されていた状態で接続であるなら同等であると受け入れているのが、流れであるということであるという要求を書いてください。 非ブロッキングIRTP実装と呼ばれるこれらの実装は各接続のための再送キューに加えて受け入れていますが、まだ伝えなかったパケットの待ち行列を維持しなければなりません、要求の順に。 これは接続のために「前-トランスミッション」待ち行列と呼ばれます。
When a non-blocking implementation receives a write request, if
the connection is not flow controlled, it behaves exactly as a
blocking IRTP. Otherwise, it prepends a DATA packet header
without a sequence number to the data, and appends the packet
to the pretransmission queue. Note that in this case, snd_nxt
is not incremented. The value of snd_nxt is incremented only
when a packet is transmitted for the first time.
非ブロッキング実装がaを受けたら要求を書いてください、接続が制御された流れでないならそれはちょうどブロッキングIRTPとして反応します。 さもなければ、それは、一連番号なしでDATAパケットのヘッダーをデータにprependsして、「前-トランスミッション」待ち行列にパケットを追加します。 この場合snd_nxtが増加されていないことに注意してください。 パケットが初めて伝えられるときだけ、snd_nxtの値は増加されています。
Miller [Page 9]
ミラー[9ページ]
RFC 938 February 1985 Internet Reliable Transaction Protocol
RFC938の1985年2月のインターネットの信頼できるトランザクションプロトコル
4.4.2 Packet Retransmission -
4.4.2 パケットRetransmission、-
The IRTP protocol requires that the transaction packet with
sequence number snd_una be periodically retransmitted as long
as there are any unacknowledged, but previously transmitted,
packets (that is, as long as the value of snd_una is not equal
to that of snd_nxt.)
IRTPプロトコルは、いくつかの認められない、しかし、以前に伝えられたパケットがある限り、一連番号snd_unaがあるトランザクションパケットが定期的に再送されるのを必要とします。(すなわち、snd_unaの値がsnd_nxtのものと等しくない限り。)
The value of snd_una increases over time due to the receipt of
DATA ACK or PORT NAK packets from a remote host (see Sections
4.5.3 and 4.5.4 below). When either of these packet types is
received, if the incoming sequence number in that packet is
greater than the current value of snd_una, the value of snd_una
is set to the incoming sequence number in that packet. Any
DATA packets with sequence number less than the new snd_una
which were queued for retransmission are released.
snd_unaの値がDATA ACKの領収書による時間かリモートホストからのPORT NAKパケットを上回る、(セクション4.5 .3と4.5を見てください、.4未満) そのパケットの入って来る一連番号がsnd_unaの現行価値より大きいならこれらのパケットタイプのどちらかが受け取られているとき、snd_unaの値はそのパケットの入って来る一連番号に設定されます。 一連番号が「再-トランスミッション」のために列に並ばせられた新しいsnd_unaより少ないどんなDATAパケットも放出されます。
(If this is a non-blocking IRTP implementation, for each DATA
packet which is thus released from the retransmission queue,
the earliest buffered packet may be transmitted from the
pretransmission queue, as long as the pretransmission queue is
non-empty. Prior to transmitting the packet, the current value
of snd_nxt is put in the sequence number field of the header.
The value of snd_nxt is then incremented by one.)
(これが非ブロッキングIRTP実装であるなら、再送キューからこのようにして放出されるそれぞれのDATAパケットに関して最も早いバッファリングされたパケットは「前-トランスミッション」待ち行列から伝えられるかもしれません、「前-トランスミッション」待ち行列が非空である限り。 パケットを伝える前に、snd_nxtの現行価値はヘッダーの一連番号分野に置かれます。 そして、snd_nxtの値は1つ増加されます。)
Finally, if the acknowledgment is a PORT NAK, the user process
with the nacked port number should be notified that the remote
port is not there.
最終的に、nackedポートナンバーがあるユーザ・プロセスは承認がPORT NAKであるなら、遠く離れたポートがそこにないように通知されるべきです。
It is also to be desired, though it is not required, that IRTP
modules have some mechanism to decide that a remote host is not
responding in order to notify user processes that this host is
apparently unreachable.
それは必要ではありませんが、また、IRTPモジュールには決めるリモートホストがこのホストが明らかに手が届かないようにユーザ・プロセスに通知するために反応させていない何らかのメカニズムがあることが望まれることになっています。
4.5 Receiving Data
4.5 データを受け取ること。
When an IRTP module in data_transfer state receives a DATA packet,
its behavior depends on the port number, sequence number and
implementation dependent space considerations.
データ_転送状態のIRTPモジュールがDATAパケットを受けるとき、振舞いはポートナンバー(一連番号と実装に依存するスペース問題)に依存します。
DATA ACK and PORT NAK packets are used to acknowledge the receipt
of DATA packets. Both of these acknowledgment packets acknowledge
the receipt of all sequence numbers up to, but not including, the
sequence number in their headers. Note that this value is denoted
"rcv_nxt" in the figures below. This number is the value of
rcv_nxt at the source of the acknowledgment packet when the
acknowledgment was generated.
DATA ACKとPORT NAKパケットは、DATAパケットの領収書を受け取ったことを知らせるのに使用されます。 包含、彼らのヘッダーの一連番号ではなく、承認パケットがすべての一連番号の領収書を受け取ったことを知らせるこれらの両方。 この値が以下の数字の指示された「rcv_nxt」であると述べてください。 承認が生成されたとき、この数は確認応答パケットの源のrcv_nxtの値です。
Miller [Page 10]
ミラー[10ページ]
RFC 938 February 1985 Internet Reliable Transaction Protocol
RFC938の1985年2月のインターネットの信頼できるトランザクションプロトコル
0 7 8 15 16 31
+--------+--------+--------+--------+
|00000011|port num| rcv_nxt |
+--------+--------+--------+--------+
| 8 | checksum |
+-----------------+-----------------+
0 7 8 15 16 31 +--------+--------+--------+--------+ |00000011|ポートnum| rcv_nxt| +--------+--------+--------+--------+ | 8 | チェックサム| +-----------------+-----------------+
Figure 4-4. DATA ACK Packet Format
図4-4。 データACKパケット・フォーマット
0 7 8 15 16 31
+--------+--------+--------+--------+
|00000100|port num| rcv_nxt |
+--------+--------+--------+--------+
| 8 | checksum |
+-----------------+-----------------+
0 7 8 15 16 31 +--------+--------+--------+--------+ |00000100|ポートnum| rcv_nxt| +--------+--------+--------+--------+ | 8 | チェックサム| +-----------------+-----------------+
Figure 4-5. PORT NAK Packet Format
図4-5。 ポートNAKパケット・フォーマット
It is not required that a receiving IRTP implementation return an
acknowledgment packet for every incoming DATA packet, nor is it
required that the acknowledged sequence number be that in the most
recently received packet. The exact circumstances under which
DATA ACK and PORT NAK packets are sent are detailed below. The
net effect is that every sequence number is acknowledged, a sender
can force reacknowledgment if an ACK is lost, all acknowledgments
are cumulative, and no out of order acknowledgments are permitted.
受信IRTP実装があらゆる入って来るDATAパケットのために確認応答パケットを返すのが必要ではありません、または、承認された一連番号が大部分では、パケットが最近受信されていたということであることが必要ですか? DATA ACKとPORT NAKパケットが送られる正確な事情は以下で詳細です。 ネットの効果はあらゆる一連番号が承認されて、ACKが無くなるなら送付者が再承認を強制できて、すべての承認が累積していて、どんな不適切な承認も受入れられないということです。
4.5.1 Receive and Acknowledgment Windows -
4.5.1 受信してください、承認Windows、-
Each IRTP module has two windows associated with the receive
side of a connection. For convenience in the following
discussion these are given names. The sequence number window
それぞれのIRTPモジュールで2つの窓を交際させる、接続の側面を受け取ってください。 以下の議論における便宜のために、これらは名です。 一連番号ウィンドウ
rcv_nxt-MAXPACK =< sequence number < rcv_nxt
rcv_nxt-MAXPACKは<一連番号<rcv_nxtと等しいです。
is called the acknowledge window. All sequence numbers within
this window represent packets which have previously been acked
or nacked, however, the ack or nack may have been lost in the
network.
呼ばれる、窓を承認してください。 この窓の中のすべての一連番号が以前にackedされるか、またはnackedされたパケットを表して、しかしながら、ackかnackがネットワークでなくされたかもしれません。
The sequence number window
一連番号ウィンドウ
rcv_nxt =< sequence number < rcv_nxt+MYRCV =< rcv_nxt+MAXPACK
<一連番号<rcv_nxt+MYRCV rcv_nxt==<rcv_nxt+MAXPACK
is called the receive window. All sequence numbers within this
window represent legal packets which may be in transit,
assuming that the remote host has received acks for all packets
呼ばれる、窓を受けてください。 この窓の中のすべての一連番号がトランジット中であるかもしれない法的なパケットを表します、リモートホストがすべてのパケットのためにacksを受け取ったと仮定して
Miller [Page 11]
ミラー[11ページ]
RFC 938 February 1985 Internet Reliable Transaction Protocol
RFC938の1985年2月のインターネットの信頼できるトランザクションプロトコル
in the acknowledge window. The value of MYRCV depends on the
implementation of the IRTP. In the simplest case this number
will be one, effectively meaning that the IRTP will ignore any
incoming packets not in the acknowledge window or not equal to
rcv_nxt. If the IRTP has enough memory to buffer some incoming
out-of-order packets, MYRCV can be set to some number =<
MAXPACK and a more complex algorithm can be used to compute
rcv_nxt, thereby achieving potentially greater efficiency.
Note that in the latter case, these packets are not
acknowledged until their sequence number is less than rcv_nxt,
thereby insuring that acknowledgments are always cumulative.
(See 4.5.4 below.)
中、窓を承認してください。 MYRCVの値はIRTPの実装に依存します。 最も簡単な場合では、この数は1になるでしょう、事実上、IRTPが中ではなくどんな入って来るパケットも無視することを意味してrcv_nxtに同輩ではなく、窓を承認してください。 IRTPにいくつかの入って来る故障しているパケットをバッファリングできるくらいの記憶力があるなら、MYRCVは<何らかの数=MAXPACKに用意ができることができます、そして、rcv_nxtを計算するのにより複雑なアルゴリズムは使用できます、その結果、潜在的により大きい効率を達成します。 これらのパケットが、後者の場合では、それらの一連番号がrcv_nxtより少なくなるまで認められないで、その結果、承認がいつも累積しているのを保障していることに注意してください。 (4.5に.4未満を見てください。)
4.5.2 Invalid Packets -
4.5.2 無効のパケット、-
When an IRTP receives a DATA packet, it first checks the
sequence number in the received packet. If the sequence number
is not within the acknowledge or receive window, the packet is
discarded. Similarly, if the computed checksum does not match
that in the header, the packet is discarded. No further action
is taken.
IRTPがDATAパケットを受けるとき、それは最初に、容認されたパケットで一連番号をチェックします。 一連番号が中にない、窓を承認するか、または受けてください、そして、パケットは捨てられます。 同様に、計算されたチェックサムがヘッダーでそれに合っていないなら、パケットは捨てられます。 さらなる行動を全く取りません。
4.5.3 Sequence Numbers Within Acknowledge Window -
4.5.3 一連番号が中で窓を承認する、-
When an IRTP receives an incoming DATA packet whose sequence
number is within the acknowledge window, if the port specified
in the incoming DATA packet is known to this IRTP, a DATA ACK
packet is returned. Otherwise, a PORT NAK is returned.
IRTPが一連番号が中にある入って来るDATAパケットを受ける、窓を承認してください、入って来るDATAパケットで指定されたポートがこのIRTPにおいて知られているならDATA ACKパケットを返します。 さもなければ、PORT NAKを返します。
In both cases, the value put in the sequence number field of
the acknowlegement packet is the current value of rcv_nxt at
the IRTP module which is acknowledging the DATA packet. The
DATA packet itself is discarded.
どちらの場合も、acknowlegementパケットの一連番号分野に置かれた値はDATAパケットを承認しているIRTPモジュールにおけるrcv_nxtの現行価値です。 DATAパケット自体は捨てられます。
(Note that the PORT NAK acknowledges reception of all packet
numbers up to rcv_nxt. It NAKs the port number, not the
sequence number.)
(PORT NAKがrcv_nxtまでのすべてのパケット番号のレセプションを承認することに注意してください。 それ、一連番号ではなく、ポートが付番するNAKs。)
4.5.4 Sequence Numbers Within the Receive Window -
4.5.4 一連番号、中、窓を受けてください、-
If the received sequence number is within the receive window,
rcv_nxt is recomputed. How this is done is implementation
dependent. If MYRCV is one, then rcv_nxt is simply
incremented. Otherwise, rcv_nxt is set to the lowest sequence
number such that all data packets with sequence numbers less
容認された一連番号が中にある、窓を受けてください、そして、rcv_nxtは再計算されます。 これがどう完了しているかは、実装に依存しています。 MYRCVが1歳であるなら、rcv_nxtは単に増加されます。 さもなければ、rcv_がnxtに最も低い一連番号にそのようなものを設定することである、それ、一連番号が、より少ないすべてのデータ・パケット
Miller [Page 12]
ミラー[12ページ]
RFC 938 February 1985 Internet Reliable Transaction Protocol
RFC938の1985年2月のインターネットの信頼できるトランザクションプロトコル
than this number have been received and are buffered at the
receiving IRTP, or have been delivered to their destination
port.
この数は、受け取られて、受信IRTPでバッファリングされるか、またはそれらの仕向港に提供されました。
Once rcv_nxt has been recomputed, a DATA ACK or PORT NAK is
returned, depending on whether the port number is known or not
known. The value placed in the sequence number field is the
newly computed value for rcv_nxt.
いったんrcv_nxtを再計算すると、DATA ACKかPORT NAKを返します、ポートナンバーが知られているか、または知られていないかによって。 一連番号分野に置かれた値はrcv_nxtのための新たに計算された値です。
4.5.5 Forwarding Data to Using Processes -
4.5.5 プロセスを使用するのにデータを転送する、-
Whenever an incoming DATA packet has been acknowledged (either
implicitly or explicitly) its header can be stripped off and it
can be queued for delivery to the user process which has
claimed its port number. If the IRTP implementation allows
MYRCV to be greater than one, care must be taken that data
which was originally received out of order is forwarded to its
intended recipient in order of original sequence number.
入って来るDATAパケットが承認された(それとなくか明らかに)ときはいつも、ヘッダーを全部はぎ取ることができます、そして、配送のためにポートナンバーを要求したユーザ・プロセスへそれを列に並ばせることができます。 IRTP実装がMYRCVを許容するなら、元の一連番号の順に1以上、注意しなければならないということになるように元々故障していた状態で受け取られたそのデータを意図している受取人に転送します。
Miller [Page 13]
ミラー[13ページ]
RFC 938 February 1985 Internet Reliable Transaction Protocol
RFC938の1985年2月のインターネットの信頼できるトランザクションプロトコル
CHAPTER 5 - IMPLEMENTATION ISSUES
第5章--導入問題
The preceding chapter was left intentionally vague in certain ways. In particular, no explicit description of the use of a timer or timers within an IRTP module was given, nor was there a description of how timer events should relate to "retransmission events". This was done to separate the syntactic and operational requirements of the protocol from the performance characteristics of its implementation.
先の章は故意にある方法であいまいなままにされました。 特に、IRTPモジュールの中のタイマかタイマの使用のどんな明白な記述も与えませんでした、そして、タイマイベントがどう「「再-トランスミッション」イベント」に関連するべきであるかに関する記述がありませんでした。 実装の性能の特性とプロトコルの構文の、そして、操作上の要件を切り離すためにこれをしました。
It is believed that the protocol is robust. That is, any implementation which strictly conforms to Chapter 4 should provide reliable synchronization of two hosts and reliable sequenced transfer of transaction data between them. However, different ways of defining the notion of a retransmission event can have potentially significant impact on the performance of the protocol in terms of throughput and in terms of the load it places on the network. It is up to the implementor to take into account overall requirements of the network environment and the intended use of the protocol, if possible, to optimize overall characteristics of the implementation. Several such issues will be discussed in this chapter.
プロトコルが強健であると信じられています。 厳密に第4章に従うすなわちどんな実装も2人のホストの信頼できる同期と変更用データの信頼できる配列された転送を彼らの間に供給するべきです。 しかしながら、「再-トランスミッション」イベントの概念を定義する異なった方法はスループットとそれがネットワークに置く負荷に関して潜在的に重要な影響をプロトコルの性能に与えることができます。 ネットワーク環境の総合的な要件とプロトコルの意図している使用を考慮に入れるのは、作成者次第です、できれば実装の総合的な特性を最適化するために。 本章でそのようないくつかの問題について議論するでしょう。
5.1 Retransmission Strategies
5.1 Retransmission戦略
The IRTP requires that a timer mechanism exists to somehow trigger
retransmissions and requires that the packet with sequence number
snd_una be the one retransmitted. It is not required that
retransmission be performed on every timer event, though this is
one "retransmission strategy". A possible alternative strategy is
to perform a retransmission on a timer event only if no ACKs have
been received since the last event.
IRTPは、タイマメカニズムがどうにか「再-トランスミッション」の引き金となるように存在するのが必要であり、一連番号snd_unaがあるパケットが再送されたものであることを必要とします。 これは1「「再-トランスミッション」戦略」ですが、「再-トランスミッション」があらゆるタイマイベントに実行されるのが必要ではありません。 可能な代替の戦略は最後のイベント以来ACKsを全く受け取っていない場合にだけタイマイベントに「再-トランスミッション」を実行することです。
Additionally, the interval of the timer can affect the performance
of the strategies, as can the value of MYRCV and the lossiness of
the network environment.
さらに、タイマの間隔は戦略の性能に影響できます、MYRCVの値とネットワーク環境のlossinessであることができることのように。
It is not within the scope of this document to recommend a
retransmission strategy, only to point out that different
strategies have different consequences. It might be desirable to
allow using processes to "specify" a strategy when a port is
claimed in order to tailor the service of the protocol to the
needs of a particular application.
「再-トランスミッション」戦略を推薦して、単に指摘するこのドキュメントの範囲の中では、異なった戦略は異なった結果を持っていません。 ポートが特定用途の必要性に対するプロトコルのサービスを合わせるために要求されるとき、戦略を「指定すること」にプロセスを使用するのを許容するのは望ましいかもしれません。
5.2 Pinging
5.2 ノッキング
It is important to make explicit that IRTP modules ping by
definition. That is, as long as a remote internet address is
明白に作るために、IRTPモジュールが定義上確認するのは、重要です。 リモートインターネットアドレスは同じくらい長いのですが、それはそうです。
Miller [Page 14]
ミラー[14ページ]
RFC 938 February 1985 Internet Reliable Transaction Protocol
RFC938の1985年2月のインターネットの信頼できるトランザクションプロトコル
known, and is in use (that is, either synchronization or data
transfer is being attempted), the protocol requires "periodic
retransmission" of packets. Note that this is true even if the
IRTP module has determined that the remote address is currently
unreachable.
知られていて、コネは使用(すなわち、同期かデータ転送のどちらかが試みられる)、プロトコルです。「周期的な「再-トランスミッション」」にパケットを要求します。 IRTPモジュールが、リモートアドレスが現在手が届かないことを決定したとしてもこれが本当であることに注意してください。
It is suggested that this situation can be made more sensible by
adding two fields to the connection table. These are:
接続テーブルに2つの分野を加えることによってこの状況をより分別があるようにすることができることが提案されます。 これらは以下の通りです。
num_retries (number of times current packet has been sent)
time_out (current retransmission timeout)
num_は外で時間_を再試行します(回数の現在のパケットを送りました)。(現在の再送タイムアウト)
These fields are to be used as follows. It is assumed that there
is some default initial value for time_out called DEFTIME, some
(relatively long) value for time_out called PINGTIME and some
value MAX_TRIES. The exact values of these constants are
implementation dependent. The value of DEFTIME may also be
retransmission strategy dependent.
これらの分野は以下の通り使用されることです。 そこでは、或るもの(比較的長い)が、_時間の出ている呼ばれたPINGTIMEのときに何らかのデフォルトが_時間の出ている呼ばれたDEFTIMEのための初期の値であることを評価して、或るものがマックス_TRIESを評価すると思われます。 これらの定数の正確な値は実装に依存しています。 また、DEFTIMEの値も「再-トランスミッション」戦略に依存しているかもしれません。
At the time that a connection table is initialized, num_retries is
set to zero, and time_out is set to DEFTIME. Whenever a
retransmission event occurs (this will either be a retransmission
of a SYNCH packet or of the packet with sequence number snd_una),
num_retries is incremented by one unless it is equal to MAX_TRIES.
If a destination is determined to be unreachable, either via an
ICMP message or a Destination Host Dead message, num_retries is
set to MAX_TRIES. Whenever num_retries transitions to MAX_TRIES,
either by being incremented or as above, the destination is is
presumed unreachable and user processes are notified. At this
point, time_out is set to PINGTIME, the state of the connection
does not change and retransmissions occur at PINGTIME intervals
until the destination becomes reachable.
接続テーブルが初期化される時に、_が再試行するnumはゼロに用意ができています、そして、時間_アウトはDEFTIMEに設定されます。 「再-トランスミッション」イベントが起こる(これは一連番号snd_unaをもってSYNCHパケットかパケットの「再-トランスミッション」になるでしょう)ときはいつも、それがマックス_TRIESと等しくない場合、_が再試行するnumは1つ増加されます。 目的地が手が届かないと決心しているなら、ICMPメッセージかDestination Host Deadメッセージで、_が再試行するnumはマックス_TRIESに用意ができています。 マックス_TRIESに移行して、存在によって増加されるか、または目的地が上にあって_が再試行するnumが手が届かないと推定されて、ユーザ・プロセスが通知されるときはいつも。 ここに、時間_アウトはPINGTIMEに設定されます、そして、接続の状態は変化しません、そして、PINGTIME間隔を置いて、目的地が届くようになるまで、「再-トランスミッション」は現れます。
Conversely, whenever a SYNCH_ACK is received (in synch_wait
state), or an (implicit or explicit) acknowledgment of sequence
number snd_una is received (in data transfer state), time_out is
set to DEFTIME and num_retries is reset to zero. If time_out was
already set to PINGTIME, user processes are notified that the
destination is now reachable.
逆に、SYNCH_ACKが受け取られているか(同調している_待ち状態)、または一連番号snd_unaの(暗黙か明白)の承認が受け取られている(データ転送状態の)ときはいつも、_DEFTIMEへのセットが外にあって、num_が再試行される時はゼロにリセットされます。 時間_アウトが既にそうであったなら、PINGTIMEにセットしてください、そして、ユーザ・プロセスは目的地に現在届いているように通知されます。
The effect of this system is obvious. The implementation still
pings as required, but at presumably very infrequent intervals.
Alternative solutions, which might place the decision to ping on
using processes, are considered undesirable because
このシステムの効果は明白です。 必要に応じてまだ確認していますが、実装はおそらく非常に珍しい間隔で、そうします。 代替のソリューション(プロセスを使用するとき確認するという決定を置くかもしれない)は望ましくないと考えられます。
o IRTP itself becomes more complicated in terms of states of
the connection table
o IRTP自身は接続テーブルの州で、より複雑になります。
Miller [Page 15]
ミラー[15ページ]
RFC 938 February 1985 Internet Reliable Transaction Protocol
RFC938の1985年2月のインターネットの信頼できるトランザクションプロトコル
o the user interface becomes both more complicated and more
rigid
o ユーザーインタフェースは、より複雑で、かつより堅くなります。
o such solutions might be deadlock prone in some instances
o そのようなソリューションはいくつかのインスタンスにおいて傾向がある行き詰まりであるかもしれません。
o it seems appropriate that the host to host protocol should
be the place to determine destination reachability, if the
overall application requires that such information be known
(as it does in the environments intended for IRTP.)
o プロトコルをホスティングするホストが目的地の可到達性を決定する場所であるべきであることは適切に見えます、全面散布が、そのような情報が知られているのを必要とするなら(IRTPのために意図する環境でするように。)
5.3 Deleting Connection Tables
5.3 接続テーブルを削除すること。
The protocol as defined does not allow connection tables to be
deleted (or for a connection state to transition to out_of_synch
from any other state). It might be appropriate to delete a
connection table if it is known that the destination internet
address is no longer one which this host wants to communicate
with. (The only danger there is that if the destination does not
know this, it could ping this host forever.) It is dangerous to
delete a connection table or to go into out_of_synch state to
avoid pinging when a destination does not appear to be there. Two
hosts with the same such strategy could potentially deadlock and
fail to resynchronize.
定義されるとしてのプロトコルは、接続テーブルが削除されるのを(または_いかなる他の状態からの同時性の出ている_への変遷への接続状態にも)許容しません。 それが知られているなら、送付先インターネットアドレスがもうこのホストがコミュニケートしたがっているものでないことは接続テーブルを削除するのが適切であるかもしれません。 (目的地がこれを知らないなら、いつまでもこのホストを確認するかもしれないという唯一の危険があります。) 接続テーブルを削除するか、または目的地がそこにあるように見えないと確認するのを避けるために_同時性状態の出ている_に入るのが危険です。 同じそのような戦略をもっている2人のホストは、潜在的に行き詰まって、再連動できませんでした。
AUTHOR'S ADDRESS
作者のアドレス
Trudy Miller Advanced Computer Communications 720 Santa Barbara Street Santa Barbara, CA 93101 (805) 963-9431
ルーディ・ミラーは(805) 963-9431にコンピュータコミュニケーション720サンタバーバラ・通りサンタバーバラ、カリフォルニア 93101を進めました。
Miller [Page 16]
ミラー[16ページ]
一覧
スポンサーリンク
