RFC916 日本語訳
0916 Reliable Asynchronous Transfer Protocol (RATP). G.G. Finn. October 1984. (Format: TXT=110737 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Finn
Request for Comments: 916 ISI
October 1984
コメントを求めるワーキンググループG.フィンランド人要求をネットワークでつないでください: 916 ISI1984年10月
RELIABLE ASYNCHRONOUS TRANSFER PROTOCOL (RATP)
信頼できる非同期な転送プロトコル(RATP)
Status of This Memo
このメモの状態
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は改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。 このメモの分配は無制限です。
This paper proposes and specifies a protocol which allows two programs to reliably communicate over a communication link. It ensures that the data entering one end of the link if received arrives at the other end intact and unaltered. The protocol, named RATP, is designed to operate over a full duplex point-to-point connection. It contains some features which tailor it to the RS-232 links now in common use.
この論文は、2つのプログラムが通信リンクの上で確かに伝えるプロトコルを、提案して、指定します。 それは、受け取るならリンクの片端に入るデータが他の終わりの完全で非変更に到着するのを確実にします。 RATPというプロトコルは、全二重二地点間接続の上で作動するように設計されています。 それは現在共用のRS-232リンクにそれを仕立てるいくつかの特徴を含んでいます。
Introduction
序論
We are witnessing today an explosive growth in the small or personal computer market. Such inexpensive computers are not normally connected to a computer network. They are most likely stand-alone devices. But virtually all of them have an RS-232 interface. They also usually have a modem. This allows them to communicate over the telephone with any other similarly equipped computer.
私たちは今日、小さいか個人的なコンピュータ市場での爆発的成長を目撃しています。 通常、そのような安価なコンピュータはコンピュータネットワークに接続されません。 それらはたぶんスタンドアロンのデバイスです。 しかし、彼らのほとんどすべてには、RS-232インタフェースがあります。 また、通常、彼らはモデムを持っています。 これで、彼らは電話の上でいかなる他の同様に備えられているコンピュータでも交信できます。
The telephone system is a pervasive network, but one of the characteristics of the telephone system is the unpredictable quality of the circuit. The standard telephone circuit is designed for voice communication and not data communication. Voice communication tolerates a much higher degree of 'noise' than does a data circuit, so a voice circuit is tolerant of a much higher level of noise than is a data circuit. Thus it is not uncommon for a byte of data transferred over a telephone circuit to have noise inserted. For the same reason it is also not uncommon to have spurious data bytes added to the data stream.
電話は普及しているネットワークですが、電話の特性の1つは回路の意外性です。 標準の電話回線はデータ通信ではなく、声のコミュニケーションのために設計されています。 声のコミュニケーションがデータ回線よりはるかに高度合いの'雑音'を許容するので、声の回路はデータ回線よりはるかに高いレベルの雑音において許容性があります。 したがって、電話回線の上に移された1バイトのデータには、雑音を挿入させるのは珍しくはありません。 また、同じ理由からそれも、偽りのデータ・バイトをデータ・ストリームに加えさせるために珍しくはありません。
The need for a method of reliably transferring data over an RS-232 point-to-point link has become severe. As the number of powerful personal computers grows, the need for them to communicate with one another grows as well. The new markets and new services that these computers will eventually allow their users to access will rely heavily upon the telephone system. Services like electronic mail, electronic banking, ordering merchandise from home with a personal computer, etc. As the information revolution proceeds data itself will become a commodity. All require accuracy of the data sent or received.
RS-232ポイントツーポイント接続の上にデータを確かに移すメソッドの必要性は厳しくなりました。 また、強力なパーソナルコンピュータの数が成長するのに従って、彼らがお互いにコミュニケートする必要性は成長します。 彼らのユーザが結局これらのコンピュータからアクセスできる新しい市場と新種業務は大いに電話を当てにされるでしょう。 電子メール、エレクトロニックバンキング、パーソナルコンピュータでホームから商品を注文するのなどようなサービス 情報革命が続くのに従って、データ自体は商品になるでしょう。 すべてが送るか、または受け取るデータの精度を必要とします。
Finn [Page 1]
フィンランド人[1ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
1. Philosopy of Design
1. デザインのPhilosopy
Many tradeoffs were made in designing this protocol. Decisions were made by above all ensuring reliability and then by favoring simplicity of implementation. It is hoped that this protocol is simple enough to be implemented not only by small computers but also by stand alone devices incorporating microcomputers which accept commands over RS-232 lines. Sophisticated but unnecessary features such as dynamic window management [TCP 81] were left out for simplicity's sake. Having several packets outstanding at a time was eliminated for the same reason, and data queued to send when a connection is closed remotely is discarded. This eliminates two states from the protocol implementation.
多くの見返りがこのプロトコルを設計する際に作られました。 何よりも信頼性を確実にして、そして、実装の簡単さを支持することによって、決定をしました。 このプロトコルが小さいコンピュータによって実装されるだけではなく、RS-232系列の上にコマンドを受け入れるマイクロコンピュータを組み込むスタンドアロンデバイスによっても実装されるほど簡単であることが望まれています。 ダイナミックなウィンドウ管理[TCP81]などの洗練されましたが、不要な特徴は簡単さのために省かれました。 一度に未払いのいくつかのパケットを持っているのは同じ理由から排除されました、そして、接続が離れて閉店するとき、発信するために列に並ばせられたデータは捨てられます。 これはプロトコル実装から2つの州を排除します。
The reader may ask why define this protocol at all, there are after all already RS-232 transport protocols in use. This is true but some lack one or more features vitally important or are too complex. See Appendix II for a brief survey.
読者はなぜ全くこのプロトコルを定義してください、使用中のRS-232トランスポート・プロトコルが結局既にあるかを尋ねるかもしれません。 これが本当ですが、或るものは、きわめて重要な状態で1つ以上の特徴を欠いているか、または複雑過ぎます。 概略調査に関してAppendix IIを見てください。
- A protocol which can only transfer data in one direction is
unable to use a single RS-232 link for a full-duplex connection.
As such it cannot act as a bridge between most computer
networks. Also it is not capable of supporting any applications
requiring the two-way exchange of data. In particular it is not
a platform suitable for the creation of most higher level
applications. Unidirectional flow of data is sufficient for a
weak implementation of file transfer but insufficient for remote
terminal service, transaction oriented processing, etc.
- データを一方向に移すことができるだけであるプロトコルは全二重接続に単一のRS-232リンクを使用できません。 そういうものとして、それはほとんどのコンピュータネットワークの間のブリッジとして機能できません。 また、それはデータの双方からの交流を必要とする少しのアプリケーションもサポートすることができません。 それは特に、ほとんどの、より高い平らなアプリケーションの作成に適したプラットホームではありません。 データの単方向の流動がファイル転送の弱い実装に十分ですが、遠隔端末サービスに、不十分である、トランザクションは処理などを適応させました。
- Some of the existing RS-232 transport protocols allow the use of
only fixed size packets or do not allow the receiver to place a
limit on the sender's packets. Where that block size is too
large for the receiving end concentrator, that concentrator is
likely to immediately invoke flow control. This results in many
dropped and damaged packets. The receiver must be able to
inform the sender at connection initiation what is the maximum
packet size it is prepared to receive.
- 既存のRS-232トランスポート・プロトコルのいくつかが、固定サイズパケットだけの使用を許すか、または受信機が送付者のパケットに限度を設けるのを許容しません。 犠牲者の集中装置には、そのブロック・サイズがあまりに大きいところでは、その集中装置はすぐに、フロー制御を呼び出しそうです。 これは多くの下げられて破損しているパケットをもたらします。 受信機は、何がそれが受けるように準備される最大のパケットサイズであるかを接続開始の送付者に知らせることができなければなりません。
- Some protocols have a number of features which may or may not be
implemented at each site. Examples are, several checksumming
algorithms, differing data transmission restrictions, sometimes
8-bit data, sometimes restricted ASCII subsets, etc. The
resulting requirement that all sites implement all the various
features is rarely met.
- いくつかのプロトコルには、各サイトで実装されるかもしれない多くの特徴があります。 例は数個がアルゴリズムをchecksummingする異なったデータ伝送制限、時々8ビットのデータ、時々制限されたASCII部分集合ですなど。 すべてのサイトがすべての様々な特徴を実装するという結果として起こる必要条件はめったに満たされません。
Finally, the size of this document may be imposing. The document attempts to fully specify the behavior of the protocol. A careful
最終的に、このドキュメントのサイズはでしゃばっているかもしれません。 ドキュメントは、プロトコルの振舞いを完全に指定するのを試みます。 A慎重です。
Finn [Page 2]
フィンランド人[2ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
exposition of the protocol's behavior under all circumstances is necessary to answer any questions an implementor might have, to make it possible to verify the protocol, etc. This size of this specification should not be taken as an indication of the difficulty of implementing it.
プロトコルの振舞いの博覧会が、プロトコルについて確かめるのを可能にするように作成者が持っているどんな質問にも答えるのなどにあらゆる情勢のもとで必要です。 それを実装するという困難のしるしとしてこの仕様のこのサイズをみなすべきではありません。
1.1. The Host Environment
1.1. ホスト環境
This protocol is designed to operate on any point-to-point
communication link capable of transmitting and receiving data. It
is not necessary that the link be asynchronous. Because neither
end of a connection has control over when the other decides to
transmit, the link should be full duplex. It is expected that in
the vast majority of circumstances an asynchronous full-duplex
RS-232 link will be used.
このプロトコルは、データを送って、受け取ることができるどんな二地点間通信リンクも作動させるように設計されています。 リンクが非同期であることは必要ではありません。 もう片方が、伝わると決めるとき、接続のどちらの終わりもコントロールを家に迎えないので、リンクは全二重であるべきです。 かなりの大多数の事情では、非同期な全二重RS-232リンクが使用されると予想されます。
In practice this protocol could reside anywhere from the RS-232
driver software on a microcomputer in a concentrator all the way
to the user software level. Ideally it properly resides inside
the host operating system or concentrator. It should be an option
associated with communication link which is selectable by the user
program. If reliable data transmission were of great importance
then the software would choose the option. Once the option were
chosen the initial connection handshaking would begin.
実際には、このプロトコルはどこでも集中装置のマイクロコンピュータの上のRS-232ドライバソフトウェアからいっぱいにユーザソフトウェアレベルまであることができました。 理想的に、それはホスト・オペレーティング・システムか集中装置の中に適切に住んでいます。 ユーザ・プログラムで選択可能であるのは、通信リンクに関連しているオプションであるべきです。 確実な資料送信がかなり重要であるなら、ソフトウェアはオプションを選ぶでしょうに。 一度、オプションはハンドシェイクが始める初期の接続に選ばれました。
There are many cases where this protocol will not reside in a host
operating system (initially this will always be so). In addition
there are many pieces of stand-alone equipment which accept
commands over an RS-232 link. A plotter is such an example. To
have a several hour plot ruined by noise on an unreliable data
line is an all too often occurrence. The sending and receiving
sides of the protocol should be as simple as possible allowing
applications software and stand alone devices to utilize the
protocol with little penalty of time or space.
多くのケースがこのプロトコルがホスト・オペレーティング・システムにない(したがって、初めは、いつもこれはそうでしょう)ところにあります。 さらに、RS-232リンクの上にコマンドを受け入れるスタンドアロンの設備の多くの断片があります。 陰謀者はそのような例です。 頼り無いデータラインで雑音によって台無しにされた陰謀がaを数個の時間持つためには、そうである、あまりにも頻繁の発生。 アプリケーションソフトウェアとスタンドアロンデバイスが時間かスペースの小さい刑罰があるプロトコルを利用するのを許容するのにおいてプロトコル送受信側はできるだけ簡単であるべきです。
1.2. Relation to Other Protocols
1.2. 他のプロトコルとの関係
The "layering" concept has become the accepted way of designing
communications protocols. Because this protocol will operate in a
point-to-point environment it comprises both the datagram and
reliable connection layers. No multi-network capability is
implied. Where a link using this protocol bridges differing
networks it is expected that other protocols like TCP will have
their packets fragmented and encapsulated inside the packets of
this protocol.
「レイヤリング」概念は通信規約を設計する受け入れられた方法になりました。 このプロトコルが二地点間環境で作動するので、それはデータグラムと信頼できる接続層の両方を包括します。 マルチネットワーク能力は全く含意されません。 このプロトコルを使用するリンクが異なったネットワークをブリッジするところでは、TCPのような他のプロトコルがそれらのパケットがこのプロトコルのパケットの中で断片化されて、カプセルに入れられるのをさせると予想されます。
Finn [Page 3]
フィンランド人[3ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
2. Packet Specification
2. パケット仕様
RATP transmits data over a full-duplex communication link. Data may be transmitted in both directions over the link. A stream of data is communicated by being broken up into 8-bit pieces called octets. These octets are serially accumulated to form a packet. The packet is the unit of data communicated over the link. The protocol virtually guarantees that the data transmitted at one end, if received, arrives unaltered and intact at the other end.
RATPは全二重通信リンクの上にデータを送ります。 データはリンクの上の両方の方向に送られるかもしれません。 データのストリームは、壊れていることによって、八重奏と呼ばれる8ビットの断片に上がっている伝えられます。 これらの八重奏は、順次、パケットを形成するために蓄積されます。 パケットはリンクの上に伝えられたデータのユニットです。 プロトコルは、実際には受け取るなら片端で送るデータがもう一方の端に非変更されていて完全な状態で到着するのを保証します。
Within an octet all eight bits contain data. All eight bits must be preserved by the link interface and associated device driver. In many operating systems this is ensured by placing the connection into RAW or BINARY data mode. During normal operation packets are transmitted and acknowledged one at a time over the link in each direction. Each packet is composed of a HEADER followed by a DATA portion. The DATA portion may be empty.
八重奏の中では、すべての8ビットがデータを含んでいます。 リンクインタフェースと関連デバイスドライバですべての8ビットを保存しなければなりません。多くのオペレーティングシステムでは、これは、RAWかBINARYデータモードに接続を置くことによって、確実にされます。 通常の操作の間、パケットは、一度に一つ、リンクの上に各方向に伝えられて、承認されます。 各パケットはDATA部分があとに続いたHEADERで構成されます。 DATA部分は空であるかもしれません。
NOTE: There are some older operating systems and devices which do
not permit 8-bit communication over an RS-232 link. Most of these
allow restricted 7-bit communication. RATP can automatically
detect this situation during connection initiation and utilizes a
special packing strategy when full 8-bit communication is not
possible. This is entirely transparent to any client software.
See Appendix I for a discussion of this case.
以下に注意してください。 RS-232リンクの上に8ビットのコミュニケーションを可能にしないいくつかの、より古いオペレーティングシステムとデバイスがあります。 これらの大部分は制限された7ビットのコミュニケーションを許容します。 RATPは接続開始の間、自動的にこの状況を検出できて、完全な8ビットのコミュニケーションが可能でないときに、特別なパッキング戦略を利用します。 これはどんなクライアントソフトウェアにも完全に透明です。 本件の議論に関してAppendix Iを見てください。
Finn [Page 4]
フィンランド人[4ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
2.1. Header Format
2.1. ヘッダー形式
Byte No.
バイトNo.
+-------------------------------+
| |
1 | Synch Leader | Hex 01
| |
+-------------------------------+
| S | A | F | R | S | A | E | S |
2 | Y | C | I | S | N | N | O | O | Control
| N | K | N | T | | | R | |
+-------------------------------+
| |
3 | Data length (0-255) |
| |
+-------------------------------+
| |
4 | Header Checksum |
| |
+-------------------------------+
+-------------------------------+ | | 1 | 同時性リーダー| 十六進法01| | +-------------------------------+ | S| A| F| R| S| A| E| S| 2 | Y| C| I| S| N| N| O| O| コントロール| N| K| N| T| | | R| | +-------------------------------+ | | 3 | データの長さ(0-255)| | | +-------------------------------+ | | 4 | ヘッダーチェックサム| | | +-------------------------------+
Header Portion of a Packet
パケットのヘッダー部分
2.1.1. Synch Leader
2.1.1. 同時性リーダー
RS-232 provides a self-clocking communications medium. The
wires over which data flows are often placed in 'noisy'
environments where the noise can appear as added unwanted data.
For this reason the beginning of a packet is denoted by a one
octet SYNCH pattern. This allows the receiver to discard noise
which appears on the connection prior to the reception of a
packet. The SYNCH pattern is defined to be the one octet hex
01, the ASCII Start Of Header character <SOH>.
RS-232は自己の時間を計るコミュニケーション媒体を供給します。 データが流れるワイヤはしばしば雑音が付記された求められていないデータとして現れることができる'騒がしい'環境に置かれます。 この理由で、パケットの始まりは1つの八重奏SYNCHパターンによって指示されます。 これで、受信機はパケットのレセプションの前に接続のときに現れる雑音を捨てることができます。 SYNCHパターンは、1つの八重奏十六進法01、ASCII Start Of Headerキャラクタ<SOH>になるように定義されます。
The SYNCH pattern should ideally be unlikely to occur as the
result of noise. Differing modems, etc. have differing
responses to noise so this is hard to achieve. The pattern
chosen is thought to be a good compromise since many modems
manifest noise by setting the high order bits. Situations will
occur in which receiver is scanning for the beginning of a
packet and a spurious SYNCH pattern is seen. To detect
situations of this type a header checksum is provided (see
below).
SYNCHパターンは雑音の結果として理想的に起こるべきでありそうにはありません。 異なったモデムであり、などが異なった応答を雑音に持っているので、これは達成しにくいです。 多くのモデムが高位のビットを設定することによって雑音を表すので、選ばれたパターンは良い感染であると考えられます。 どの受信機がパケットの始まりの間、スキャンされるかに状況は起こるでしょう、そして、偽りのSYNCHパターンは見られます。 このタイプの状況を検出するために、ヘッダーチェックサムを提供します(以下を見てください)。
Finn [Page 5]
フィンランド人[5ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
2.1.2. Control Bits
2.1.2. コントロールビット
The first octet following the SYNCH pattern contains a 5-bit
field of control flags and two 1-bit sequence number fields.
The last bit is reserved and must be zero.
SYNCHパターンに従う最初の八重奏は指揮旗と2つの1ビットの一連番号分野の5ビットの分野を含んでいます。 最後のビットは、予約されていて、ゼロであるに違いありません。
2.1.2.1. SYN - Synchronize Flag
2.1.2.1. SYN--旗を同期させてください。
Synchronize the connection. No data may be sent in a packet
which has the SYN flag set.
接続を同時にさせてください。 SYN旗を設定するパケットでデータを全く送らないかもしれません。
2.1.2.2. ACK - Acknowledge Flag
2.1.2.2. ACK--旗を承認してください。
Acknowledge number is significant. Data may accompany a
packet which has this flag set as long as neither of SYN,
RST, nor FIN are also set. Once a connection has been
established this is always set.
数が重要であると認めてください。 データはまた、SYNのどちらも、RST、およびFINが用意ができている限り、この旗を設定するパケットに伴うかもしれません。 接続がいったん確立されると、これはいつも設定されます。
2.1.2.3. RST - Reset Flag
2.1.2.3. RST--リセット旗
Reset the connection. This is a method by which one end of
a connection can reset the other when an anomalous condition
is detected. No data may be sent in a packet which has the
RST flag set.
接続をリセットしてください。 これは変則的な状態が検出されるとき接続の終わりがもう片方をリセットできるメソッドです。 RST旗を設定するパケットでデータを全く送らないかもしれません。
2.1.2.4. FIN - Finishing Flag
2.1.2.4. フィン--旗を完成させること。
This indicates that no more data will be sent to the other
end of the connection. It also indicates that no more data
will be accepted. No data may be sent in a packet which has
the FIN flag set.
これは、それ以上のデータが全く接続のもう一方の端に送られないのを示します。 また、それは、それ以上のデータが全く受け入れられないのを示します。 FIN旗を設定するパケットでデータを全く送らないかもしれません。
2.1.2.5. SN - Sequence Number
2.1.2.5. SN--一連番号
The Sequence Number associated with this packet.
Sequence Numberはこのパケットと交際しました。
2.1.2.6. AN - Acknowledge Number
2.1.2.6. --数を承認してください
If the ACK control flag is set this is the next Sequence
Number the sender of the packet is expecting to receive.
ACK指揮旗が設定されるなら、これはパケットの送付者が受け取ると予想している次のSequence Numberです。
2.1.2.7. EOR - End of Record
2.1.2.7. EOR--記録の終わり
This bit is provided as an aid for higher level protocols
which may need to fragment their packets. The Internet
protocol for example often uses packets as large as 576
octets. A packet of such size would require fragmentation
それらのパケットを断片化する必要があるかもしれないより高い平らなプロトコルのための援助としてこのビットを提供します。 例えば、インターネットプロトコルはしばしば576の八重奏と同じくらい大きいパケットを使用します。 そのようなサイズのパケットは断片化を必要とするでしょう。
Finn [Page 6]
フィンランド人[6ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
when transported using this protocol. The EOR bit if set
provides information to the higher level that a record is
terminated in this packet. It is for information only and
is the responsibility of the higher level to set/clear it
when building packets to send. The interface to the
protocol must provide a method of reading/setting/clearing
this bit.
これを使用することで輸送されたら、議定書を作ってください。 設定されるなら噛み付かれたEORは記録がこのパケットで終えられるというより高いレベルへの情報を提供します。 それは、情報だけのためにあって、発信するためにパケットを建てるときそれを設定するか、または晴れさせるより高いレベルの責任です。 プロトコルへのインタフェースはこのビットを読むか、設定する、またはきれいにするメソッドを提供しなければなりません。
2.1.2.8. SO - Single Octet
2.1.2.8. そのように--ただ一つの八重奏
One application thought to be of special importance is
single character transmission --- a user communicates from
the keyboard of a personal computer to another computer over
an unreliable link. Since rapid interactive response is
desirable it is expected that many of the characters typed
will be transmitted individually. To minimize the overhead
of this special case the SO control flag is provided.
特別な重要性がある1つのアプリケーション考えがただ一つのキャラクタトランスミッションです。--- ユーザはパーソナルコンピュータのキーボードから頼り無いリンクの上の別のコンピュータまで交信します。 以来、急速な対話的な応答はタイプされた文字の多くが個別に伝えられると予想されるのが望ましいです。 この特別なケースの諸経費を最小にするために、SO指揮旗を提供します。
The SO flag has no meaning if either the SYN, RST, or FIN
flags are set. Assume none of those flags are set, then if
the SO flag is set it indicates that a single octet of data
is contained in this packet. Since the amount of data is
known to be one octet the LENGTH field is superfluous and
itself contains the data octet. The data portion of the
packet is not transmitted.
SO旗には、意味でないのがSYN、RSTであるならあるか、またはFIN旗は設定されます。 それらの旗のいずれも設定されないと仮定してください、そして、SO旗が設定されるなら、次に、それは、データのただ一つの八重奏がこのパケットに含まれているのを示します。 データ量が1つの八重奏であることが知られているのでLENGTH分野が余計である、それ自体、データ八重奏を含んでいます。 パケットのデータ部は伝えられません。
The SO flag removes the need to transmit the data portion of
the packet in this special case. Without the SO flag seven
octets would be required of the packet, with it only four
are needed and so transmission efficiency is improved by 40
percent. The header checksum protects the single octet of
data.
SO旗はこの特別な場合でパケットのデータ部を伝える必要性を取り除きます。 SO旗がなければ、パケットは7つの八重奏に要求されて、それだけで、4が必要であるので、伝達効率は40パーセント改良されます。 ヘッダーチェックサムはデータのただ一つの八重奏を保護します。
2.1.3. Length
2.1.3. 長さ
The second octet following the SYNCH pattern holds length
information. If the SYN bit is present this contains the
maximum number of data octets the receiver is allowed to
transmit in any single packet to the sender. This quantity is
called the MDL. A sender may indicate his unwillingness to
accept any data octets by specifying an MDL of zero. In this
case presumably all the data would be moving from the sender to
the receiver. Obviously if data is to be transmitted both
sides of a connection cannot have an MDL of zero.
SYNCHパターンに従う2番目の八重奏は長さの情報を保持します。 SYNビットが存在しているなら、これは受信機がどんな単一のパケットでも送付者に伝えることができるデータ八重奏の最大数を含んでいます。 この量はMDLと呼ばれます。 送付者は、ゼロのMDLを指定することによってどんなデータ八重奏も受け入れるために彼の気がすすまないことを示すかもしれません。 この場合、おそらくすべてのデータが送付者から受信機まで動いているでしょう。データが明らかに伝えられることであるなら、接続の両側はゼロのMDLを持つことができません。
If neither the SYN, RST, nor FIN flags are set this is an 8-bit
field called LENGTH. In this case if the SO flag bit is set
SYN、RSTもFIN旗もそうでないなら、設定されて、これはLENGTHと呼ばれる8ビットの分野です。 この場合、SOが弛むなら、ビットは設定されます。
Finn [Page 7]
フィンランド人[7ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
then LENGTH contains a single octet of data. Otherwise it
contains the count of data octets in this packet. From zero
(0) to MDL octets of data may appear in a single packet. MDL
is limited to a maximum of 255.
そして、LENGTHはデータのただ一つの八重奏を含んでいます。 さもなければ、それはこのパケットでのデータ八重奏のカウントを含んでいます。 ゼロから、データのMDL八重奏への(0)は単一のパケットに現れるかもしれません。 MDLは最大255に制限されます。
2.1.4. Header Checksum
2.1.4. ヘッダーチェックサム
The header checksum algorithm is the 8-bit equivalent of the
16-bit data checksum detailed below. It is built and processed
in an similar manner but is eight bits wide instead of sixteen.
When sending the header checksum octet is initially cleared.
An 8-bit sum of the control, length, and header checksum octets
is formed employing end-around carry. That sum is then
complemented and stored in the header checksum octet. Upon
receipt the 8-bit end-around carry sum is formed of the same
three octets. If the sum is octal 377 the header is presumed
to be valid. In all other cases the header is assumed to be
invalid.
ヘッダーチェックサムアルゴリズムは以下で詳細な16ビットのデータチェックサムの8ビットの同等物です。 それは、同様の方法で建てられて、処理されますが、8ビットは16の代わりに広いです。 初めは発信するとき、ヘッダーチェックサム八重奏はクリアされます。 コントロール、長さ、およびヘッダーチェックサム八重奏の8ビットの合計は形成雇用エンドアラウンドに運ばれるということです。 その合計は、ヘッダーチェックサム八重奏に次に、補足となって、格納されます。 8ビットのエンドアラウンドが運ぶ領収書に、合計は同じ3つの八重奏について形成されます。 合計が8進377であるなら、ヘッダーはあえて有効です。 他のすべての場合では、ヘッダーが無効であると思われます。
The reasons for providing this separate protection to the
header are discussed in the chapter dealing with error
handling. The header checksum covers the control and data
length octets. It does not include the SYNCH pattern.
この別々の保護をヘッダーに供給する理由はエラー処理に対処する章で論じられます。 ヘッダーチェックサムはコントロールとデータ長さの八重奏を含んでいます。 それはSYNCHパターンを含んでいません。
2.2. Data Format
2.2. データの形式
The data portion of a packet immediately follows the header if the
SO flag is not set and LENGTH > 0. It consists of LENGTH data
octets immediately followed by two data checksum octets. If
present the data portion contains LENGTH+2 octets.
パケットのデータ部はSO旗がセットとまたはLENGTH>0でないならすぐに、ヘッダーに続きます。 それは2つのデータチェックサム八重奏がすぐにあとに続いたLENGTHデータ八重奏から成ります。 存在しているなら、データ部はLENGTH+2八重奏を含んでいます。
Finn [Page 8]
フィンランド人[8ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
Data Byte No.
データ・バイトNo.
+-------------------------------+
1 | | High order \
+-- --+ > Word
2 | | Low order /
+-- --+
. | Data | High order \
+-- --+ > Word
. | | Low order /
+-- --+
LENGTH | | High order \
+-------------------------------+ > Word
| Imaginary padding octet 0 | Low order /
+-------------------------------+
LENGTH+1 | | High order \
+-- Data Checksum --+ > Word
LENGTH+2 | | Low order /
+-------------------------------+
+-------------------------------+ 1 | | 高位\+----+ >Word2| | 下位/+----+。| データ| 高位\+----+ >Word。| | 下位/+----+ LENGTH| | 高位\+------------------------------->が言い表す+| 想像する詰め物八重奏0| 下位/+-------------------------------+ 長さ+1| | 高位\+--データChecksum--+ >Word LENGTH+2| | 下位/+-------------------------------+
Data Portion of a Packet
パケットのデータ部
2.2.1. Data Checksum
2.2.1. データチェックサム
The last two octets of the data portion of a packet are a data
checksum. A 16-bit checksum is used by this protocol to detect
incorrectly transmitted data. This has shown itself to be a
reliable method for detecting most categories of bit drop out
and bit insertion. While it does not guarantee the detection
of all such errors the probability of such an error going
undetected is on the order of 2**(-16).
パケットのデータ部の最後の2つの八重奏がデータチェックサムです。 16ビットのチェックサムはこのプロトコルによって使用されて、不当に伝えられたデータを検出します。 これは、ビットのほとんどのカテゴリが脱落する検出のための確かな方法になるように本性を表して、挿入に噛み付きました。 そのようなすべての誤りの検出を保証しませんが、2**(-16)の注文にはそのような誤りが察知されずにいるという確率があります。
The checksum octets follow the data to enable the sender of a
packet to compute the checksum while transmitting a packet and
the receiver to compute the checksum while receiving the
packet. Thus neither must store the packet and then process
the data for checksumming in a separate pass.
チェックサム八重奏は、パケットを受けている間、チェックサムを計算するためにパケットと受信機を伝えている間、パケットの送付者がチェックサムを計算するのを可能にするためにデータに従います。 したがって、どちらも、別々のパスでchecksummingするようにパケットを格納して、次に、データを処理してはいけません。
Order of Transmission
トランスミッションの注文
The order in which the 8-bit octets are assembled into
16-bit words, which is the low order octet and which is the
high, must be rigidly specified for the purpose of computing
16-bit checksums. We specify the big endian ordering in the
diagram above [Cohen 81].
8ビット・オクテットがどれであるかで16ビットの単語に組み立てられたオーダー(下位の八重奏であり、高値である)を16ビットのチェックサムを計算する目的に厳格に指定しなければなりません。私たちは[コーエン81]より上でダイヤグラムを入るように命じるビッグエンディアンを指定します。
Finn [Page 9]
フィンランド人[9ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
Checksum Algorithm
チェックサムアルゴリズム
The checksum algorithm chosen is similar to that used by
IP/TCP protocols [IP 81] [TCP 81]. This algorithm has shown
itself to be both reliable and relatively easy to compute.
The interested reader may refer to [TCP Checksum 78] for a
more thorough discussion of its properties.
選ばれたチェックサムアルゴリズムはIP/TCPプロトコル[IP81][TCP81]によって使用されるそれと同様です。 このアルゴリズムは、信頼できて、かつ計算するのが比較的簡単であるように本性を表しました。 興味のある読者は特性の、より徹底的な議論について[TCP Checksum78]について言及するかもしれません。
The checksum algorithm is:
チェックサムアルゴリズムは以下の通りです。
SENDER
送付者
The unsigned sum of the 16-bit words of the data portion
of the packet is formed. Any overflow is added into the
lowest order bit. This sum does not include the header
portion of the packet. For the purpose of building a
packet for transmission the two octet checksum field is
zero. The sum formed is then bit complemented and
inserted into the checksum field before transmission.
パケットのデータ部の16ビットの単語の無記名の合計は形成されます。 どんなオーバーフローも最も低いオーダービットに加えられます。 この合計はパケットのヘッダー部分を含んでいません。 トランスミッションのためにパケットを建てる目的のために、2八重奏チェックサム分野はゼロです。 そして、形成された合計はトランスミッションの前にチェックサム分野に補足となって、挿入されたビットです。
If the total number of data octets is odd then the last
octet is padded to the right (low order) with zeros to
form a 16-bit word for checksum purposes. This pad octet
is not transmitted as part of the packet.
データ八重奏の総数が変であるなら最後の八重奏はゼロで正しい(下位)に水増しされて、チェックサム目的に対する16ビットの単語を形成します。 このパッド八重奏はパケットの一部として伝えられません。
RECEIVER
受信機
The sum is computed as above but including the values
received in the checksum field. If the 16-bit sum is
octal 177777 then the data is presumed to be valid. In
all other cases the data is presumed to be invalid.
合計は、同じくらい上で計算されますが、チェックサム分野に受け取られた値を含んでいます。 16ビットの合計が8進177777であるなら、データはあえて有効です。 他のすべての場合では、データはあえて無効です。
This unsigned 16-bit sum adds 16-bit quantities with any
overflow bit added into the lowest order bit of the sum. This
is called 'end around carry'. End around carry addition
provides several properties: 1) It provides full commutivity of
addition (summing in any order is equivalent), and 2) If you
apply a given rotation to each quantity before addition and
when the final total is formed apply the inverse rotation, then
the result will be equivalent to any other rotation chosen.
The latter property gives little endian machines like a PDP-11
the go ahead to pick up 16-bit quantities and add them in byte
swapped order.
どんなオーバーフロービットも合計の最も低いオーダービットに加えられている状態で、この無記名の16ビットの合計は16ビットの量を加えます。 これは'エンドアラウンドは運ばれます'と呼ばれます。 エンドアラウンドキャリー添加は数個の資産を提供します: 1) それは添加(どんなオーダーでもまとめは同等である)の完全なcommutivity、および2を)提供します。 添加と最終的な合計がいつ形成されるかが逆さの回転を適用する前にあなたが与えられた回転を各量に適用すると、結果は選ばれたいかなる他の回転にも同等になるでしょう。 後者の特性は、16ビットの量を拾って、バイトの交換されたオーダーでそれらを加えるために先でPDP-11のようなリトルエンディアンマシンに碁を与えます。
Finn [Page 10]
フィンランド人[10ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
The PDP-11 code to calculate the checksum is:
チェックサムについて計算するPDP-11コードは以下の通りです。
CLR R0 ; R0 will get the checksum
; R2 contains LENGTH count
LOOP: ADD (R1)+,R0 ; Add the next 16-bit byte
ADC R0 ; Make any carry be end around
SOB R2,LOOP ; Loop over entire packet
COM R0 ; Bit complement result
CLR R0。 R0はチェックサムを得るでしょう。 R2はLENGTHカウントLOOPを含んでいます: R0、+を加えてください(R1)。 次の16ビットのバイトADC R0を加えてください。 エンドアラウンドがSOB R2、LOOPであったならいずれも運ばせてください。 全体のパケットCOM R0の上で輪にしてください。 噛み付いている補数結果
2.3. Sequence Numbers
2.3. 一連番号
Sequence numbers work with acknowledge numbers to inform the
sender that his last data packet was received, and to inform the
receiver of the sequence number of the next data packet it expects
to see. When the ACK flag is set in a packet the AN field
contains the sequence number of the next data packet it expects
from the sender. The sender looks at the AN field and by
implication knows that the packet he just sent should have had a
sequence number of:
一連番号が働いている、見るために数が彼の最後のデータ・パケットが受け取られたことを送付者に知らせて、それが予想する次のデータ・パケットの一連番号の受信機を知らせると認めてください。 ACK旗がパケットに設定されるとき、AN分野はそれが送付者から予想する次のデータ・パケットの一連番号を含んでいます。 送付者は、AN分野を見て、含意で彼がただ送ったパケットが以下の一連番号を持つはずであったのを知っています。
<AN received-1 modulo 2>
受け取られていている1つの法の<AN2>。
If it did have that number that packet is considered to have been
acknowledged.
それにその数があったなら、そのパケットが承認されたと考えられます。
Similarly, the receiver expects the next data packet it sees to
have an SN field value equal to the AN field of the last
acknowledge message it sent. If this is not the case then the
receiver assumes that it is receiving a duplicate of a data packet
it earlier acknowledged. This implies that the packet containing
the acknowledgment did not arrive and therefor the packet that
contained the acknowledgment should be retransmitted. The
duplicate data packet is discarded.
同様に、受信機は、最終AN分野へのSN分野値の同輩がそれが見る次のデータ・パケットでそれが送ったメッセージを承認すると予想します。 これがそうでないなら、受信機は、それが前に承認したデータ・パケットの写しを受け取っていると仮定します。 これは、承認を含むパケットが到着しなかったのを含意します、そして、そのために、承認を含んだパケットは再送されるべきです。 重複データパケットは捨てられます。
The only packets which require acknowledgment are packets
containing status flags (SYN, RST, FIN, or SO) or data. A packet
which contains only an acknowledgment, i.e. <AN=n><CTL=ACK>, does
not require a response (it contains no status flags or data).
承認を必要とする唯一のパケットが状態旗(SYN、RST、FIN、またはSO)かデータを含むパケットです。 承認だけを含むパケット(すなわち、<AN=n><CTL=ACK>)は応答を必要としません(それはどんな状態旗もデータも含んでいません)。
Both the AN and SN fields are a single bit wide. Since at most
one packet is in the process of being sent/acknowledged in a
particular direction at any one time a single bit is sufficient to
provide a method of duplicate packet detection and removal of a
packet from the retransmission queue. The arithmetic to advance
these numbers is modulo 2. Thus when a data packet has been
acknowledged the sender's next sequence number will be the current
one, plus one modulo 2:
ANとSN分野の両方が広い状態で噛み付かれたシングルです。 いかなる時も特定の方向に送るか、または承認することの途中にパケットが最も1つにあるので、1ビットは再送キューから写しパケット検出の方法とパケットの取り外しを提供するために十分です。 これらの数を進める演算は法2です。 データ・パケットが承認されたとき、したがって、送付者の次の一連番号は現在のものになるでしょう、プラス1法2:
Finn [Page 11]
フィンランド人[11ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
<SN = SN + 1 modulo 2>
<SNはSN+1法2>と等しいです。
The individual acknowledgment of each packet containing data can
mislead one into thinking that side A of a connection cannot send
data to side B until it receives a packet from B. That only then
can it acknowledge B's packet and place in the acknowledging
packet some data of its own. This is not the case.
それがB.Thatだけからパケットを受けるまで接続の側面Aが側Bにデータを送ることができないと思うのにデータを含むそれぞれのパケットの個々の承認が1つをミスリードすることができて、次に、それは、ビーズパケットを承認して、それ自身のいくつかのデータを承認パケットに置くことができますか? これはそうではありません。
As long as its last packet sent requiring a response has been
acknowledged each side of a connection is free to send a data
packet whenever it wishes. Naturally, if one side is sending a
data packet and it also must acknowledge receipt of a data packet
from the other side, it is most efficient to combine both
functions in a single packet.
応答が必要とさせられる最後のパケットが承認された限り、願っているときはいつも、接続の各側面は無料でデータ・パケットを送ることができます。 当然、半面がデータ・パケットを送って、また、反対側からデータ・パケットの領収書を受け取ったことを知らせなければならないなら、単一のパケットで両方の機能を結合するのは最も効率的です。
2.4. Maximum Packet Size
2.4. 最大のパケットサイズ
The maximum packet size is:
最大のパケットサイズは以下の通りです。
SYNCH + HEADER + Data Checksum + 255 = 261 octets
SYNCH+HEADER+データChecksum+255 = 261八重奏
There is therefor no need to allocate more than that amount of
storage for any received packets.
どんな容認されたパケットのためのその量の格納以上も割り当てる必要は全くそのためにありません。
Finn [Page 12]
フィンランド人[12ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
3. The Opening and Closing of a Connection
3. 接続の始まりと閉鎖
3.1. Opening a Connection
3.1. 接続を開きます。
A "three-way handshake" is the procedure used to establish a
connection. It is normally initiated by one end of the connection
and responded to by the other. It will still work if both sides
simultaneously initiate the procedure. Experience has shown that
this strategy of opening a connection reduces the probability of
false connections to an acceptably low level.
「3方向ハンドシェイク」は取引関係を築くのに用いられた手順です。 それに通常、接続の片端によって開始されていて、もう片方によって応じられます。 それでも、両側が同時に手順に着手すると、それは働くでしょう。 経験は、接続を開くこの戦略が許容できて低いレベルに偽の接続の確率を引き下げるのを示しました。
The simplest form of the three-way handshake is illustrated in the
diagram below. The time order is line by line from top to bottom
with certain lines numbered for reference. User events are placed
in brackets as in [OPEN]. An arrow (-->) represents the direction
of flow of a packet and an ellipsis (...) indicates a packet in
transit. Side A and side B are the two ends of the connection.
An "XXX" indicates a packet which is lost or rejected. The
contents of the packet are shown on the center of each line. The
state of both connections is that caused by the departure or
arrival of the packet represented on the line. The contents of
the data portion of a packet are left out for clarity.
3方向ハンドシェイクの最も簡単なフォームは以下のダイヤグラムで例証されます。 時間オーダーは参照のためにある線で1行ずつ上から下まで付番されます。 ユーザ出来事は[オープン]のように括弧に置かれます。 矢、(-->) パケットと(…)が、パケットが中に通過するのを示す省略の流れの方向を表します。 側Aと側Bは接続の2つの終わりです。 "XXX"は失われているか、または拒絶されるパケットを示します。 パケットの内容はそれぞれの線のセンターに示されます。 線の上に表されたパケットの出発か到着で引き起こされて、両方の接続の状態はそれです。 パケットのデータ部の内容は明快ために省かれます。
Side A Side B
側Bに面があってください。
1. CLOSED LISTEN
1. 閉じられて、聴いてください。
2. [OPEN request]
SYN-SENT -> <SN=0><CTL=SYN><MDL=n> ...
2. [オープン要求]SYN-SENT-><SN=0><CTL=SYN><MDL=n>…
3. --> SYN-RECEIVED
... <SN=0><AN=1><CTL=SYN,ACK><MDL=m> <--
3. -->はSYN受信されました… <SN=0><、1>の=<CTL=SYN、ACK><MDL=m><--
4. ESTABLISHED <--
--> <SN=1><AN=1><CTL=ACK><DATA> ...
4. 確立した<----><SN=1><、1>の=<CTL=ACK><データ>…
5. --> ESTABLISHED
5. --設立された>。
In line 2 above the user at side A has requested that a connection
be opened. Side A then attempts to open a connection by sending a
SYN packet to side B which is in the LISTEN state. It specifies
its initial sequence number, here zero. It places in the LENGTH
field of the header the largest number of data octets it can
consume in any one packet (MDL). The MDL is normally positive.
The action of sending this packet places A in the SYN-SENT state.
側のユーザの上の線2では、Aは、接続が開かれるよう要求しました。 そして、側Aは、LISTEN状態にあるBに面があるためにSYNパケットを送ることによって接続を開くのを試みます。 それはここで初期シーケンス番号を指定します。ゼロ。 それはそれがどんなパケット(MDL)でも消費できるデータ八重奏の最多数をヘッダーのLENGTH分野に置きます。 通常、MDLは積極的です。 このパケットを送る動作はSYN-SENT状態にAを置きます。
In line 3 side B has just received the SYN packet from A. This
並んで、3側BはA.ThisからSYNパケットをちょうど受けたところです。
Finn [Page 13]
フィンランド人[13ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
places B in the SYN-RECEIVED state. B now sends a SYN packet to A
which acknowledges the SYN it just received from A. Note that the
AN field indicates B is now expecting to hear SN=1, thus
acknowledging the SYN packet from A which used SN=0. B also
specifies in the LENGTH field the largest number of data octets it
is prepared to consume.
SYN-RECEIVED状態の場所B。 Bは現在それがANがさばくA.Noteからただ受けたSYNが、Bが、現在SN=1を聞くと予想しているのを示すと認めるAにSYNパケットを送ります、その結果、SN=0を使用したAからSYNパケットを承認します。 また、BはLENGTH分野でそれが消費するように準備されるデータ八重奏の最多数を指定します。
Side A receives the SYN packet from B which acknowledges A's
original SYN packet in line 4. This places A in the ESTABLISHED
state. Side A can now be confident that B expects to receive more
packets from A.
側Aは線4でAのオリジナルのSYNパケットを承認するBからSYNパケットを受けます。 これはESTABLISHED状態にAを置きます。 側Aは現在、Bが、Aから、より多くのパケットを受けると予想すると確信している場合があります。
A is now free to send B the first DATA packet. In line 5 upon
receipt of this packet side B is placed into the ESTABLISHED
state. DATA cannot be sent until the sender is in the ESTABLISHED
state. This is because the LENGTH field is used to specify the
MDL when opening the connection.
Aは現在、自由に最初のDATAパケットをBに送ることができます。 このパケットを受け取り次第線5では、側BはESTABLISHED状態に置かれます。 送付者がESTABLISHED状態にあるまで、DATAを送ることができません。 これはLENGTH分野が接続を開くとき、MDLを指定するのに使用されるからです。
3.2. Recovering from a Simultaneous Active OPEN
3.2. 同時のアクティブな戸外から、回復します。
It is of course possible that both ends of a connection may choose
to perform an active OPEN simultaneously. In this case neither
end of the connection is in the LISTEN state, both send SYN
packets. A reliable bidirectional protocol must recover from this
situation. It should recover in such a manner that the connection
is successfully initiated.
接続の両端が、同時に活発なオープンを実行するのを選ぶのは、もちろん可能です。 この場合、接続のどちらの終わりもLISTEN状態になくて、両方がパケットをSYNに送ります。 信頼できる双方向のプロトコルはこの状況から回復しなければなりません。 接続が首尾よく開始されるのはそのような方法で回復するべきです。
Finn [Page 14]
フィンランド人[14ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
Side A Side B
側Bに面があってください。
1. CLOSED CLOSED
1. 閉じられた状態で、閉じられます。
2. [OPEN request]
SYN-SENT --> <SN=0><CTL=SYN><MDL=n> ...
2. [オープン要求] SYN-SENT--><SN=0><CTL=SYN><MDL=n>…
3. ... [OPEN request]
<SN=0><CTL=SYN><MDL=m> <-- SYN-SENT
3. ... [オープン要求]<SN=0><CTL=SYN><MDL=m><--SYN-SENT
4. --> SYN-RECEIVED
... <SN=0><AN=1><CTL=SYN,ACK><MDL=m> <--
4. -->はSYN受信されました… <SN=0><、1>の=<CTL=SYN、ACK><MDL=m><--
5. (packet finally arrives)
SYN-RECEIVED <-- <SN=0><CTL=SYN><MDL=m>
5. (パケットは最終的に到着します) SYNによって容認された<--<SN=0><CTL=SYN><MDLはm>と等しいです。
--> <SN=0><AN=1><CTL=SYN,ACK><MDL=n> --> ESTABLISHED
... <SN=1><AN=1><CTL=ACK> <--
--><SN=0><、1>の=<CTL=SYN、ACK><MDL=n>(設立された>) <SN=1><、1>の=<CTL=ACK><--
6. (packet finally arrives)
ESTABLISHED <-- <SN=0><AN=1><CTL=SYN,ACK><MDL=m>
--> <SN=1><AN=1><CTL=ACK> ...
6. (パケットは最終的に到着します) <は設立しました--、<SN=0><、1>の=<CTL=SYN、ACK><MDL=m>--、><SN=1><、1>の=<CTL=ACK>…
During simultaneous connection both sides of the connection
cycle from the CLOSED state through SYN-SENT to SYN-RECEIVED,
and finally to ESTABLISHED.
同時接続の間、接続の両側はSYN-SENTを通したCLOSED状態からSYN-RECEIVEDまで最終的なESTABLISHEDに循環します。
3.3. Detecting a Half-Open Connection
3.3. 半開きな接続を検出します。
Any computer may crash after a connection has been established.
After recovering from the crash it may attempt to open a new
connection. The other end must be able to detect this condition
and treat it as an error.
接続が確立された後にどんなコンピュータもクラッシュするかもしれません。 クラッシュから回復した後に、それは、新しい接続を開くのを試みるかもしれません。 もう一方の端は、この状態を検出して、誤りとしてそれを扱うことができなければなりません。
Finn [Page 15]
フィンランド人[15ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
Side A Side
側に面があってください。
1. ESTABLISHED ESTABLISHED
1. 確立していた状態で、設立されます。
--> <SN=0><AN=1><CTL=ACK><DATA> ...
-->
(crashes)
--><SN=0><は1>の=<CTL=ACK><データ>です…。 -->。(クラッシュ)
2. XXX <SN=1><AN=1><CTL=ACK><DATA> <--
2. XXX<SN=1><、1>の=<CTL=ACK><データ><--
3. (attempts to open new connection )
--> <SN=0><CTL=SYN><MDL=m> -->
... <SN=0><AN=1><CTL=RST,ACK> <-- (abort)
CLOSED
3. (新しい接続を開く試み) --><SN=0><CTL=SYN><MDLはm>と等しいです-->。 <SN=0><、1>の=<CTL=RST、ACK><--閉じられます(中止になります)。
4. <--
(connection refused)
CLOSED
4. <-- (拒否された接続) 閉じられます。
3.4. Closing a Connection
3.4. 接続を終えます。
Either side may choose to close an established connection. This
is accomplished by sending a packet with the FIN control bit set.
No data may appear in a FIN packet. The other end of the
connection responds by shutting down its end of the connection and
sending a FIN, ACK in response.
どちらの側も、確立した接続を終えるのを選ぶかもしれません。 これは、FINコントロールビットがセットした状態でパケットを送ることによって、達成されます。 データは全くFINパケットに現れないかもしれません。 接続のもう一方の端は、接続の終わりを止めて、FIN(応答におけるACK)を送ることによって、応じます。
Side A Side B
側Bに面があってください。
1. ESTABLISHED ESTABLISHED
1. 確立していた状態で、設立されます。
2. [CLOSE request from user]
FIN-WAIT --> <SN=0><AN=1><CTL=FIN> ...
2. [ユーザからのCLOSE要求] FIN-WAIT--><SN=0><AN=1><CTL=FIN>…
3. --> LAST-ACK
... <SN=1><AN=1><CTL=FIN,ACK> <--
3. -->の最後のACK… <SN=1><、1>の=<CTL=フィン、ACK><--
4. TIME-WAIT <--
--> <SN=1><AN=0><CTL=ACK> ...
4. 時間待ち<----><SN=1><、=0><CTL=ACK>…
5. --> CLOSED
5. -->は閉じました。
6. (after 2*SRTT time passes)
CLOSED
6. (2*SRTT時間が経過した後に) 閉じられます。
In line 2 the user on side A of the fully opened connection has
decided to close it down by issuing a CLOSE call. No more data
線2では、完全に開かれた接続の側面Aの上のユーザは、CLOSE呼び出しを発行することによってそれを閉鎖すると決めました。 それ以上のデータがありません。
Finn [Page 16]
フィンランド人[16ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
will be accepted for sending. If data remains unsent a message
"Warning: Unsent data remains." is communicated to the user. No
more data will be received. A packet containing a FIN but no data
is constructed and sent. Side A goes into the FIN-WAIT state.
送付のために、受け入れるでしょう。 データの残りがメッセージを非送付する、「警告:」 「Unsentデータの残り」 ユーザとコミュニケートします。 それ以上のデータを全く受け取らないでしょう。 FINを含んでいますが、どんなデータも含まないパケットを、組み立てて、送ります。 側AはFIN-WAIT状態に入ります。
Side B sees the FIN sent and immediately builds a FIN, ACK packet
in response. It then goes into the LAST-ACK state. The FIN, ACK
packet is received by side A and an answering ACK is immediately
sent. Side A then goes to the TIME-WAIT state. In line 5 side B
receives the final acknowledgment of its FIN, ACK packet and goes
to the CLOSED state. In line 6 after waiting to be sure its last
acknowledgment was received side A goes to the CLOSED state (SRTT
is the Smoothed Round Trip Time and is defined in section 6.3.1).
側Bは、FINが送られるのを見て、すぐに、応答でFIN、ACKパケットを建てます。 そして、それはLAST-ACK状態に入ります。 FINであり、側AでACKパケットを受け取ります、そして、すぐに、回答ACKを送ります。 そして、側Aはタイム誌-WAIT状態に行きます。 並んで、5側Bは、FIN、ACKパケットの最終的な承認を受けて、CLOSED状態に行きます。 待った後の線6では、最後の承認が受けられたのを確信しているように、側AはCLOSED状態に行きます(SRTTはSmoothed Round Trip Timeであり、セクション6.3.1で定義されます)。
Finn [Page 17]
フィンランド人[17ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
4. Packet Reception
4. パケットレセプション
The act of receiving a packet is relatively straightforward. There are a few points which deserve some discussion. This chapter will discuss packet reception stage by stage in time order.
パケットを受ける行為は比較的簡単です。 何らかの議論に値する数ポイントがあります。 本章は時間オーダーで段階でパケットレセプションステージについて議論するでしょう。
Synch Detection
同時性検出
The first stage in the reception of a packet is the discovery of a
SYNCH pattern. Octets are read continuously and discarded until
the SYNCH pattern is seen. Once SYNCH has been observed proceed
to the Header Reception stage.
パケットのレセプションにおける第一段階はSYNCHパターンの発見です。 SYNCHパターンが見られるまで、八重奏は、絶え間なく読まれて、捨てられます。 SYNCHがいったん観測された後、Header Receptionステージに進んでください。
Header Reception
ヘッダーレセプション
The remainder of the header is three octets in length. No further
processing can continue until the complete header has been read.
Once read the header checksum test is performed. If this test
fails it is assumed that the current SYNCH pattern was the result
of a data error. Since the correct SYNCH may appear immediately
after the current one, go back to the Synch Detection stage but
treat the three octets of the header following the bad SYNCH as
new input.
ヘッダーの残りは長さが3つの八重奏です。 完全なヘッダーが読まれるまで、どんなより遠い処理も続くことができません。 一度ヘッダーに読み込まれたチェックサムテストは実行されます。 このテストが失敗するなら、現在のSYNCHパターンがデータ誤りの結果であったと思われます。 正しいSYNCHが現在のもの直後現れるかもしれないので、Synch Detection舞台に戻りなさい、ただし、新しい入力として悪いSYNCHに続いて、ヘッダーの3つの八重奏を扱ってください。
If the header checksum test succeeds then proceed to the Data
Reception stage.
ヘッダーチェックサムテストが成功するなら、Data Receptionステージに進んでください。
Data Reception
データ受信
A determination of the remaining length of the packet is made. If
either of the SYN, RST, SO, or FIN flags are set then legally the
entire packet has already been read and it is considered to have
'arrived'. No data portion of a packet is present when one of
those flags is set. Otherwise the LENGTH field specifies the
remaining amount of data to read. In this case if the LENGTH
field is zero then the packet contains no data portion and it is
considered to have arrived.
パケットの残っている長さの決断をします。 SYN、RST、SO、またはFINでは、旗が設定されるなら、法的に、全体のパケットは既に読まれました、そして、それが'到着した'と考えられます。 それらの旗の1つが設定されるとき、パケットのどんなデータ部も存在していません。 さもなければ、LENGTH分野は、読むために残っているデータ量を指定します。 この場合、パケットはLENGTH分野がゼロであるならデータ部を全く含みません、そして、到着したのは考えられます。
We now assume that a data portion is present and LENGTH was
non-zero. Counting the data checksum LENGTH+2 octets must now be
read. Once read the data checksum test is performed. If this
test fails the entire packet is discarded, return to the Synch
Detection stage. If the test succeeds then the packet is
considered to have arrived.
私たちは現在、データ部が存在していて、LENGTHが非ゼロであったと思います。 現在、データチェックサムLENGTH+2八重奏を数えるのを読まなければなりません。 いったん読まれると、データチェックサムテストは実行されます。 このテストが失敗するなら、全体のパケットは捨てられて、Synch Detectionへのリターンはステージです。 テストが成功するなら、パケットが到着したと考えられます。
Finn [Page 18]
フィンランド人[18ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
Once arrived the packet is released to the upper level protocol software. In a multiprocess implementation packet reception would now begin again at the Synch Detection stage.
いったん到着していると、パケットは上側の平らなプロトコル・ソフトウエアに放出されます。 aでは、レセプションが現在再びSynch Detection段階で始める実現パケットを多重処理してください。
Finn [Page 19]
フィンランド人[19ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
5. Functional Specification
5. 機能的な仕様
A convenient model for the discussion and implementation of protocols is that of a state machine. A connection can be thought of as passing through a variety of states, with possible error conditions, from its inception until it is closed. In such a model each state represents a known point in the history of a connection. The connection passes from state to state in response to events. These events are caused by user calls to the protocol interface (a request to open or close a connection, data to send, etc.), incoming packets, and timeouts.
プロトコルの議論と実現のための便利なモデルは州のマシンのものです。 さまざまな州を通り抜けると接続を思うことができます、可能なエラー条件で、それが閉じられるまでの始まりから。 そのようなモデルで、各州は接続の歴史の知られているポイントを表します。 接続は出来事に対応して述べる状態から変化します。 これらの出来事はユーザ呼び出しでプロトコルインタフェース(接続、送るデータなどを開くか、または閉じるという要求)、入って来るパケット、およびタイムアウトに引き起こされます。
Information about a connection must be maintained at both ends of that connection. Following the terminology of [TCP 81] the information necessary to the successful operation of a connection is called the Transmission Control Block or TCB. The user requests to the protocol interface are OPEN, SEND, RECEIVE, ABORT, STATUS, and CLOSE.
その接続の両端で接続の情報を保守しなければなりません。 [TCP81]必要情報の用語に接続のうまくいっている操作に従うのはTransmission Control BlockかTCBと呼ばれます。 プロトコルインタフェースへのユーザ要求は、オープンと、SENDと、RECEIVEと、ABORTと、STATUSと、CLOSEです。
This chapter is broken up into three parts. First a brief description of each protocol state will be presented. Following this is a slightly more detailed look at the allowed transitions which occur between states. Finally a detailed discussion of the behavior of each state is given.
本章は3つの部品に終えられます。 まず最初に、それぞれのプロトコル状態の簡単な説明は提示されるでしょう。 これに続くのは、州の間に起こる許された遷移へのわずかに詳細な一見です。 最終的にそれぞれの状態の振舞いの詳細な論議を与えます。
5.1. Protocol States
5.1. プロトコル州
The states used to describe this protocol are:
このプロトコルについて説明するのに使用される州は以下の通りです。
LISTEN
聴いてください。
This state represents waiting for a connection from the
other end of the link.
この州はリンクのもう一方の端から接続の待ちを表します。
SYN-SENT
SYNによって送られます。
This represents waiting for a matching connection request
after having sent a connection request.
接続要求を送って、これは有の後の合っている接続要求の待ちを表します。
SYN-RECEIVED
SYNを受け取られていさせます。
This represents waiting for a confirming connection request
acknowledgment after having both received and sent a
connection request.
これは両方を持った後の承認が接続要求を受け取って、送ったという確認接続要求の待ちを表します。
Finn [Page 20]
フィンランド人[20ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
ESTABLISHED
設立されます。
This state represents a connection fully opened at both
ends. This is the normal state for data transfer.
この州は両端で完全に開かれた接続の代理をします。 これはデータ転送のための正常な状態です。
FIN-WAIT
フィン待ち
In this state one is waiting for a connection termination
request from the other end of the connection and an
acknowledgment of a termination request previously sent.
この状態では、1つは接続のもう一方の端と以前に送られた終了要求の承認から接続終了要求を待っています。
LAST-ACK
最後のACK
This end of the connection has seen and acknowledged a
termination request from the other end. This end has
responded with a termination request of its own and is now
expecting an acknowledgment of that request.
接続のこの終わりは、もう一方の端からの終了要求を見て、承諾しました。 この終わりは、それ自身の終了要求で応じて、現在、その要求に承認を予想しています。
CLOSING
閉じます。
This represents waiting for an acknowledgment of a
connection termination request.
これは接続終了要求の承認の待ちを表します。
TIME-WAIT
時間待ち
This represents waiting for enough time to pass to be sure
that the other end of the connection received the
acknowledgment of its termination request.
これは、接続のもう一方の端が終了要求の承認を受けたのを確信しているように通ることができるくらいの時間の待ちを表します。
CLOSED
閉じられます。
A fictional state which represents a completely terminated
connection. If either end of a connection is in this state
it will neither send nor receive data or control packets.
完全に終えられた接続の代理をする作り事の州。 接続のどちらの終わりもこの状態にあると、それは、データかコントロールパケットを送付でない、また受け取らないでしょう。
Finn [Page 21]
フィンランド人[21ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
5.2. State Transitions
5.2. 状態遷移
This section describes events which cause the protocol to depart
from its current state. A brief mention of each state is
accompanied by a list of departure events and to which state the
protocol goes as a result of those events. Departures due to the
presence of a RST flag are not shown.
このセクションはプロトコルが現状から出発する出来事について説明します。 それぞれの状態の簡潔な言及は出発出来事のリストとプロトコルがそれらの出来事の結果、どの状態を行かせるかに伴われます。 RST旗の存在による出発は示されません。
5.2.1. LISTEN
5.2.1. 聴いてください。
This is a request to listen for any connection from the other
end of the link. In this state, no packets are sent. The
connection may be thought of as half-open. A STATUS request
will return to the caller this information.
これはリンクのもう一方の端からどんな接続も聞こうとするという要求です。 この状態では、パケットを全く送りません。 接続は半開きであるとして思われるかもしれません。 STATUS要求はこの情報を訪問者に返すでしょう。
Arrived at from the CLOSED state in response to a passive OPEN.
In a passive OPEN no packets are sent, the interface is waiting
for the initiation of a connection from the other end of the
link. Also this state can be reached in certain cases in
response to an RST connection reset request.
CLOSED状態から、受け身のオープンに対応して、到着します。 パケットが全く送られない受け身のオープンでは、インタフェースはリンクのもう一方の端から接続の開始を待っています。 また、ある場合には、この状態にRST接続リセット要求に対応して達することができます。
Departures
出発
- A CLOSE request is made by the user. Delete the half-open
TCB and go to the CLOSED state.
- CLOSE要求はユーザによってされます。 半開きなTCBを削除してください、そして、CLOSED状態に行ってください。
- A packet arrives with the SYN flag set. Retrieve the
sender's MDL he placed into the LENGTH field. Set AN to
be received SN+1 modulo 2. Build a response packet with
SYN, ACK set. Choose your MDL and place it into the
LENGTH octet. Choose your initial SN, place in AN. Send
this packet and go to the SYN-RECEIVED state.
- パケットはSYN旗のセットと共に到着します。 彼がLENGTH分野に置いた送付者のMDLを検索してください。 ANに容認されたSN+1法2であるように設定してください。 SYNと共に応答パケットを建ててください、そして、ACKはセットします。 MDLを選んでください、そして、LENGTH八重奏にそれを置いてください。 初期のSNを選んでください、そして、ANで入賞してください。 このパケットを送ってください、そして、SYN-RECEIVED状態に行ってください。
5.2.2. SYN-SENT
5.2.2. SYNによって送られます。
Arrived at from the CLOSED state in response to a user's active
OPEN request.
CLOSED状態から、ユーザの活発なオープン要求に対応して、到着します。
Departures
出発
- A CLOSE request is made by the user. Delete the TCB and
go to the CLOSED state.
- CLOSE要求はユーザによってされます。 TCBを削除してください、そして、CLOSED状態に行ってください。
- A packet arrives with the SYN flag set. Retrieve the
sender's MDL he placed into the LENGTH field. Set AN to
- パケットはSYN旗のセットと共に到着します。 彼がLENGTH分野に置いた送付者のMDLを検索してください。 セット
Finn [Page 22]
フィンランド人[22ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
be received SN+1 modulo 2. Build a response packet with
ACK set, place in AN. Send this packet and go to the
SYN-RECEIVED state.
容認されたSN+1法2になってください。 ACKがセットした状態で、応答パケットを建ててください、そして、ANで入賞してください。 このパケットを送ってください、そして、SYN-RECEIVED状態に行ってください。
- A packet arrives with the SYN, ACK flags set. Retrieve
the sender's MDL he placed into the LENGTH field. Set AN
to be received SN+1 modulo 2. Build a response packet
with ACK set. Set SN to be SN+1 modulo 2, place SN and AN
into the header. Remembering the other end's MDL, build
data portion of packet. Send this packet and go to the
ESTABLISHED state.
- パケットはSYNと共に到着して、ACK旗はセットします。 彼がLENGTH分野に置いた送付者のMDLを検索してください。 ANに容認されたSN+1法2であるように設定してください。 ACKがセットした状態で、応答パケットを建ててください。 SNにヘッダーへのSN+1法2と、場所SNとANであるように設定してください。 もう一方の端のMDLを覚えていて、パケットのデータ部を築き上げてください。 このパケットを送ってください、そして、ESTABLISHED状態に行ってください。
5.2.3. SYN-RECEIVED
5.2.3. SYNを受け取られていさせます。
Arrived at from the LISTEN and SYN-SENT states in response to
an arriving SYN packet.
LISTENとSYN-SENT州から、到着しているSYNパケットに対応して、到着します。
Departures
出発
- A CLOSE request is made by the user. Create a packet with
FIN set. Send it and go to the FIN-WAIT state.
- CLOSE要求はユーザによってされます。 FINがセットした状態で、パケットを作成してください。 それを送ってください、そして、FIN-WAIT状態に行ってください。
- A packet arrives with the ACK flag set. This packet
acknowledges a previous SYN packet. Go to the ESTABLISHED
state. The TCB should now note the connection is fully
opened.
- パケットはACK旗のセットと共に到着します。 このパケットは前のSYNパケットを承認します。 ESTABLISHED状態に行ってください。 TCBは、現在、接続が完全に開かれることに注意するはずです。
- A packet arrives with the FIN flag set. The other end has
decided to close the connection. Create a packet with
FIN, ACK set. Send it and go to the LAST-ACK state.
- パケットはFIN旗のセットと共に到着します。 もう一方の端は、接続を終えると決めました。 FINと共にパケットを作成してください、そして、ACKはセットします。 それを送ってください、そして、LAST-ACK状態に行ってください。
5.2.4. ESTABLISHED
5.2.4. 設立されます。
This state is the normal state for a connection. Data packets
may be exchanged in both directions (MDL allowing). It is
arrived at from the SYN-RECEIVED and SYN-SENT states in
response to the completion of connection initiation.
この状態は接続に、正常な状態です。 両方の方向(MDL許容)とデータ・パケットを交換するかもしれません。 接続開始の完成に対応してSYN-RECEIVEDとSYN-SENT州からそれに達します。
Departures
出発
- In response to a CLOSE request from the user. Set AN to
be most recently received SN+1 modulo 2. Build a packet
with FIN set. Set SN to be SN+1 modulo 2, place SN and AN
into the header and send the packet. Go to the FIN-WAIT
state.
- ユーザからのCLOSE要求に対応して。 ANにごく最近容認されたSN+1法2であるように設定してください。 FINがセットした状態で、パケットを建ててください。 SNにヘッダーへのSN+1法2と、場所SNとANであり、パケットを送るように設定してください。 FIN-WAIT状態に行ってください。
- A packet containing a FIN is received. Set AN to be
- FINを含むパケットは受け取られています。 ANは設定します。
Finn [Page 23]
フィンランド人[23ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
received SN+1 modulo 2. Build a response packet with both
FIN and ACK set. Set SN to be SN+1 modulo 2, place SN and
AN into the header. No data portion is built. Send this
packet and go to the LAST-ACK state.
容認されたSN+1法2。 FINとACKが設定する両方で応答パケットを建ててください。 SNにヘッダーへのSN+1法2と、場所SNとANであるように設定してください。 どんなデータ部も組立していません。 このパケットを送ってください、そして、LAST-ACK状態に行ってください。
5.2.5. FIN-WAIT
5.2.5. フィン待ち
Arrived at from either the SYN-RECEIVED state or from the
ESTABLISHED state. In both cases the user had requested a
CLOSE of the connection and a packet with a FIN was sent.
どちらかからのSYN-RECEIVED州において、または、ESTABLISHED状態から到着しました。 どちらの場合も、ユーザは、接続のCLOSEとFINがあるパケットが送られたよう要求しました。
Departures
出発
- A FIN, ACK packet is received which acknowledges the FIN
just sent. Go to the TIME-WAIT state.
- FINであり、ACKパケットは受け取られています(ただ送られたFINを承認します)。 タイム誌-WAIT状態に行ってください。
- A FIN packet is received which indicates the other end of
the connection has simultaneously decided to close. Set
AN=received SN+1 modulo 2, and SN=SN+1 modulo 2. Send a
response packet with the ACK set. Go to the CLOSING
state.
- FINパケットは受け取られています(接続のもう一方の端が、同時に閉じると決めたのを示します)。 セットAN=はSN+1法2、およびSN=SN+1法2を受け取りました。 ACKセットがある応答パケットを送ってください。 CLOSING状態に行ってください。
5.2.6. LAST-ACK
5.2.6. 最後のACK
Arrived at from the ESTABLISHED and SYN-RECEIVED states.
ESTABLISHEDとSYN-RECEIVED州から、到着します。
Departures
出発
- An ACK is received for the last packet sent which was a
FIN. Delete the TCB and go to the CLOSED state.
- 送られたFINであった最後のパケットのためにACKを受け取ります。 TCBを削除してください、そして、CLOSED状態に行ってください。
5.2.7. CLOSING
5.2.7. 閉じます。
Arrived at from the FIN-WAIT state.
FIN-WAIT状態から、到着します。
Departures
出発
- An ACK is received for the last packet sent which was a
FIN. Go to the TIME-WAIT state.
- 送られたFINであった最後のパケットのためにACKを受け取ります。 タイム誌-WAIT状態に行ってください。
5.2.8. TIME-WAIT
5.2.8. 時間待ち
Arrived at from the FIN-WAIT and CLOSING states.
FIN-WAITとCLOSING州から、到着します。
Finn [Page 24]
フィンランド人[24ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
Departures
出発
- This states waits until 2*SRTT time has passed. It then
deletes the TCB associated with the connection and goes to
the CLOSED state.
- 2*SRTT時間が経過するまで、待っていますこれが、述べる。 それは、次に、接続に関連しているTCBを削除して、CLOSED状態に行きます。
5.2.9. CLOSED
5.2.9. 閉じられます。
This state can be arrived at for a number of reasons: 1) while
in the LISTEN state the user requests a CLOSE, 2) while in the
SYN-SENT state the user requests a CLOSE, 3) while in the
TIME-WAIT state the 2*SRTT time period has elapsed, and 4)
while in the LAST-ACK state an arriving packet has an ACK of
the previously sent FIN packet.
様々な意味でこの状態に達することができます: 1) ユーザがLISTEN状態でCLOSEを要求している間、2は、)SYN-SENTにある間、2*SRTTの期間がタイム誌-WAIT状態で経過しましたが、ユーザがCLOSE、3を)要求すると述べます、そして、LAST-ACKにある間、4は)到着パケットには以前に送られたFINパケットのACKがあると述べます。
In this state no data is read or sent over the link. To leave
this state requires an outside request to open a new
connection.
この状態では、データを全くリンクの上に読み込みもしませんし、送りもしません。 この状態を出るのは新しい接続を開くという外の要求を必要とします。
Departures
出発
- User requests an active OPEN. Create a packet with SYN
set. Choose your MDL and place it into the LENGTH octet.
Choose your initial SN. AN is immaterial. Send this
packet and go to the SYN-SENT state. The TCB for this
connection is created. The connection may be thought of
as half-open. A STATUS request will return to the caller
this information.
- ユーザは活発なオープンを要求します。 SYNがセットした状態で、パケットを作成してください。 MDLを選んでください、そして、LENGTH八重奏にそれを置いてください。 初期のSNを選んでください。 ANは重要でないです。 このパケットを送ってください、そして、SYN-SENT状態に行ってください。 この接続のためのTCBは作成されます。 接続は半開きであるとして思われるかもしれません。 STATUS要求はこの情報を訪問者に返すでしょう。
- User requests a passive OPEN. The TCB for this connection
is created. The connection may be thought of as
half-open. A STATUS request will return to the caller
this information. Go to the LISTEN state.
- ユーザは受け身のオープンを要求します。 この接続のためのTCBは作成されます。 接続は半開きであるとして思われるかもしれません。 STATUS要求はこの情報を訪問者に返すでしょう。 LISTEN状態に行ってください。
Finn [Page 25]
フィンランド人[25ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
5.3. State Behavior
5.3. 国家行動
This section discusses in detail the behavior of each state in
response to the arrival of a packet. In what follows a packet is
not considered to have arrived until it has passed a number of
tests (see the chapter entitled: Packet Reception).
このセクションは詳細にパケットの到着に対応してそれぞれの状態の振舞いについて論じます。 続くことでパケットがそれまで到着したと考えられないかが多くのテストに合格しました(権利を与えられた章: パケットReceptionを見てください)。
The method chosen to describe state behavior is tabular. Each
state is listed opposite a sequence of named procedures to execute
whenever a packet has arrived.
国家行動について説明するために選ばれた方法は表です。 各状態はパケットが到着したときはいつも、実行する命名された手順の系列の反対側に記載されています。
STATE BEHAVIOR
=============+========================
LISTEN | A
-------------+------------------------
SYN-SENT | B
-------------+------------------------
SYN-RECEIVED | C1 D1 E F1 H1
-------------+------------------------
ESTABLISHED | C2 D2 E F2 H2 I1
-------------+------------------------
FIN-WAIT | C2 D2 E F3 H3
-------------+------------------------
LAST-ACK | C2 D3 E F3 H4
-------------+------------------------
CLOSING | C2 D3 E F3 H5
-------------+------------------------
TIME-WAIT | D3 E F3 H6
-------------+------------------------
CLOSED | G
-------------+------------------------
国家行動=============+======================== 聴いてください。| A-------------+------------------------ SYNによって送られます。| B-------------+------------------------ SYNを受け取られていさせます。| C1 D1E F1H1-------------+------------------------ 設立されます。| C2 D2E F2 H2 I1-------------+------------------------ フィン待ち| C2 D2E F3 H3-------------+------------------------ 最後のACK| C2 D3E F3 H4-------------+------------------------ 閉じます。| C2 D3E F3 H5-------------+------------------------ 時間待ち| D3E F3 H6-------------+------------------------ 閉じられます。| G-------------+------------------------
For example, in the ESTABLISHED state the arrival of a packet
causes procedure C2 to be executed, then D2, then E, F2, H2, and
finally I1. Any procedure may terminate the processing which
occurs or cause a state change. Note that these procedures are
executed in sequence, first C2, then D2, etc. The time ordering
cannot be mixed.
例えば、ESTABLISHED状態では、パケットの到着は手順の実行されるべきC2、次に、D2、次に、E、F2、H2、および最終的にI1を引き起こします。 どんな手順も、起こる処理を終えるか、または州の変化を引き起こすかもしれません。 これらの手順が次に、系列、最初に、C2、D2などで実行されることに注意してください。 時間注文を混ぜることができません。
The particular actions associated with each procedure are now
described.
各手順に関連している特定の動作は現在、説明されます。
Finn [Page 26]
フィンランド人[26ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
A --------------------------------------------------------
A--------------------------------------------------------
This procedure details the behavior of the LISTEN state. First
check the packet for the RST flag. If it is set then packet is
discarded and ignored, return and continue the processing
associated with this state.
この手順はLISTEN状態の振舞いを詳しく述べます。 まず最初に、RST旗がないかどうかパケットをチェックしてください。 それが設定されて、次に、パケットが捨てられて、無視されるなら、この状態に関連している処理を返して、続けてください。
We assume now that the RST flag was not set. Check the packet
for the ACK flag. If it is set we have an illegal condition
since no connection has yet been opened. Send a RST packet
with the correct response SN value:
私たちは、現在、RST旗が設定されなかったと思います。 ACK旗がないかどうかパケットをチェックしてください。 接続が全くまだ開かれていないので、それが設定されるなら、私たちには、不法な状態があります。 正しい応答SN価値があるRSTパケットを送ってください:
<SN=received AN><CTL=RST>
<SN=は><CTL=RST>を受けました。
Return to the current state without any further processing.
さらなる処理なしでどんな現状まで戻ってください。
We assume now that neither the RST nor the ACK flags were set.
Check the packet for a SYN flag. If it is set then an attempt
is being made to open a connection. Create a TCB for this
connection. The sender has placed its MDL in the LENGTH field,
also specified is the sender's initial SN value. Retrieve and
place them into the TCB. Note that the presence of the SO flag
is ignored since it has no meaning when either of the SYN, RST,
or FIN flags are set.
私たちは、現在、RSTもACK旗も用意ができていなかったと思います。 SYN旗がないかどうかパケットをチェックしてください。 それを設定するなら、接続を開くのを試みをしています。 この接続のためにTCBを作成してください。 送付者はLENGTH分野にMDLを置きました、また、指定されているのが、送付者の初期のSN値です。 それらをTCBに検索して、置いてください。 SYN、RST、またはFINに、旗があるとき、それには意味でないのがあるのでSO旗の存在が無視されるというメモはセットしました。
Send a SYN packet which acknowledges the SYN received. Choose
the initial SN value and the MDL for this end of the
connection:
SYNが受信したと認めるものをSYNパケットに送ってください。 初期のSN値とMDLを接続のこの終わりに選んでください:
<SN=0><AN=received SN+1 modulo 2><CTL=SYN, ACK><LENGTH=MDL>
<SN=0><AN=はSN+1法2><CTL=SYN、ACK><LENGTH=MDL>を受けました。
and go to the SYN-RECEIVED state without any further
processing.
そして、さらなる処理なしでどんなSYN-RECEIVED状態に行ってください。
Any packet not satisfying the above tests is discarded and
ignored. Return to the current state without any further
processing.
上のテストを満たさないどんなパケットも、捨てられて、無視されます。 さらなる処理なしでどんな現状まで戻ってください。
Finn [Page 27]
フィンランド人[27ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
B --------------------------------------------------------
B--------------------------------------------------------
This procedure represents the behavior of the SYN-SENT state
and is entered when this end of the connection decides to
execute an active OPEN.
この手順は、SYN-SENT状態の振舞いを表して、接続のこの終わりが、活発なオープンを実行すると決めると、入れられます。
First, check the packet for the ACK flag. If the ACK flag is
set then check to see if the AN value was as expected. If it
was continue below. Otherwise the AN value was unexpected. If
the RST flag was set then discard the packet and return to the
current state without any further processing, else send a
reset:
まず最初に、ACK旗がないかどうかパケットをチェックしてください。 ACK旗が設定されるならチェックして、予想されるとしてAN値があったか確認してください。 それがそうであったなら、以下で続いてください。 さもなければ、AN値は予期していませんでした。 RST旗が設定されたなら、パケットを捨ててください、そして、一層のいずれがなければもほかに処理するのがリセットを送る現状まで戻ってください:
<SN=received AN><CTL=RST>
<SN=は><CTL=RST>を受けました。
Discard the packet and return to the current state without any
further processing.
パケットを捨ててください、そして、さらなる処理なしでどんな現状まで戻ってください。
At this point either the ACK flag was set and the AN value was
as expected or ACK was not set. Second, check the RST flag.
If the RST flag is set there are two cases:
ここに、ACKが旗を揚げさせるどちらかが設定されました、そして、予想されるとしてAN値があったか、またはACKは用意ができていませんでした。 2番目に、RST旗をチェックしてください。 RST旗が設定されるなら、2つのケースがあります:
1. If the ACK flag is set then discard the packet, flush the
retransmission queue, inform the user "Error: Connection
refused", delete the TCB, and go to the CLOSED state without
any further processing.
1. ACK旗が設定されるならパケットを捨ててくださいといって、再送キューを洗い流してくださいといって、ユーザに知らせてください、「誤り:」 「拒否された接続」、TCBを削除してください、そして、さらなる処理なしでどんなCLOSED状態に行ってください。
2. If the ACK flag was not set then discard the packet and
return to this state without any further processing.
2. ACK旗が設定されなかったなら、パケットを捨ててください、そして、さらなる処理なしでどんなこの状態に戻ってください。
At this point we assume the packet contained an ACK which was
Ok, or there was no ACK, and there was no RST. Now check the
packet for the SYN flag. If the ACK flag was set then our SYN
has been acknowledged. Store MDL received in the TCB. At this
point we are technically in the ESTABLISHED state. Send an
acknowledgment packet and any initial data which is queued to
send:
ここに、私たちが、パケットがOkであったACKを含んだと思うか、ACKが全くなくて、またまたはRSTが全くありませんでした。今度は、SYN旗がないかどうかパケットをチェックしてください。 ACK旗が設定されたなら、私たちのSYNは承認されました。 TCBに受け取られたMDLを格納してください。 ここに、私たちは技術的にESTABLISHED状態にあります。 発信するために列に並ばせられる確認応答パケットとあらゆる初期のデータを送ってください:
<SN=received AN><AN=received SN+1 modulo 2><CTL=ACK><DATA>
容認されたAN><<SN=AN=はSN+1法2><CTL=ACK><DATA>を受けました。
Go to the ESTABLISHED state without any further processing.
さらなる処理なしでどんなESTABLISHED状態に行ってください。
If the SYN flag was set but the ACK was not set then the other
end of the connection has executed an active open also.
Acknowledge the SYN, choose your MDL, and send:
SYN旗が設定されましたが、ACKが用意ができていなかったなら、接続のもう一方の端はアクティブな戸外も実行しました。 SYNを承認してください、そして、MDLを選んでください、そして、発信してください:
<SN=0><AN=received SN+1 modulo 2><CTL=SYN, ACK><LENGTH=MDL>
<SN=0><AN=はSN+1法2><CTL=SYN、ACK><LENGTH=MDL>を受けました。
Finn [Page 28]
フィンランド人[28ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
Go to the SYN-RECEIVED state without any further processing.
さらなる処理なしでどんなSYN-RECEIVED状態に行ってください。
Any packet not satisfying the above tests is discarded and
ignored. Return to the current state without any further
processing.
上のテストを満たさないどんなパケットも、捨てられて、無視されます。 さらなる処理なしでどんな現状まで戻ってください。
C1 --------------------------------------------------------
C1--------------------------------------------------------
Examine the received SN field value. If the SN value was
expected then return and continue the processing associated
with this state.
容認されたSN分野価値を調べてください。 SN値が予想されたなら、この状態に関連している処理を返して、続けてください。
We now assume the SN value was not what was expected.
私たちは、現在、SN値が予想されたものでなかったと思います。
If either RST or FIN were set discard the packet and return to
the current state without any further processing.
RSTかFINのどちらかがセットであるなら、パケットを捨ててくださいだろうに、そして、さらなる処理なしでどんな現状まで戻ってください。
If neither RST nor FIN flags were set it is assumed that this
packet is a duplicate of one already received. Send an ACK
back:
RSTもFIN旗もセットでなかったなら、このパケットが既に受け取られた1の写しであると思われます。 ACKを返送してください:
<SN=received AN><AN=received SN+1 modulo 2><CTL=ACK>
容認されたAN><<SN=AN=はSN+1法2><CTL=ACK>を受けました。
Discard the duplicate packet and return to the current state
without any further processing.
写しパケットを捨ててください、そして、さらなる処理なしでどんな現状まで戻ってください。
C2 --------------------------------------------------------
C2--------------------------------------------------------
Examine the received SN field value. If the SN value was
expected then return and continue the processing associated
with this state.
容認されたSN分野価値を調べてください。 SN値が予想されたなら、この状態に関連している処理を返して、続けてください。
We now assume the SN value was not what was expected.
私たちは、現在、SN値が予想されたものでなかったと思います。
If either RST or FIN were set discard the packet and return to
the current state without any further processing.
RSTかFINのどちらかがセットであるなら、パケットを捨ててくださいだろうに、そして、さらなる処理なしでどんな現状まで戻ってください。
If SYN was set we assume that the other end crashed and has
attempted to open a new connection. We respond by sending a
legal reset:
SYNがセットであったなら、私たちは、もう一方の端が、クラッシュして、新しい接続を開くのを試みたと思います。 私たちは法的なリセットを送ることによって、応じます:
<SN=received AN><AN=received SN+1 modulo 2><CTL=RST, ACK>
容認されたAN><<SN=AN=はSN+1法2><CTL=RST、ACK>を受けました。
This will cause the other end, currently in the SYN-SENT state,
to close. Flush the retransmission queue, inform the user
"Error: Connection reset", discard the packet, delete the TCB,
and go to the CLOSED state without any further processing.
これは現在、閉鎖へのSYN-SENT状態へのもう一方の端を引き起こすでしょう。 再送キューを洗い流してくださいといって、ユーザに知らせてください、「誤り:」 「リセットされた接続」、パケットを捨ててください、そして、TCBを削除してください、そして、さらなる処理なしでどんなCLOSED状態に行ってください。
Finn [Page 29]
フィンランド人[29ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
If neither RST, FIN, nor SYN flags were set it is assumed that
this packet is a duplicate of one already received. Send an
ACK back:
RST、FINもSYN旗も設定されて、このパケットが既に受け取られた1の写しであると思われるということでなかったなら。 ACKを返送してください:
<SN=received AN><AN=received SN+1 modulo 2><CTL=ACK>
容認されたAN><<SN=AN=はSN+1法2><CTL=ACK>を受けました。
Discard the duplicate packet and return to the current state
without any further processing.
写しパケットを捨ててください、そして、さらなる処理なしでどんな現状まで戻ってください。
D1 --------------------------------------------------------
D1--------------------------------------------------------
The packet is examined for a RST flag. If RST is not set then
return and continue the processing associated with this state.
パケットはRST旗がないかどうか調べられます。 RSTが用意ができていないなら、この状態に関連している処理を返して、続けてください。
RST is now assumed to have been set. If the connection was
originally initiated from the LISTEN state (it was passively
opened) then flush the retransmission queue, discard the
packet, and go to the LISTEN state without any further
processing.
現在、RSTが設定されたと思われます。 接続が元々LISTEN状態から開始されたなら(それは受け身に開かれました)、再送キューを洗い流してください、そして、パケットを捨ててください、そして、さらなる処理なしでどんなLISTEN状態に行ってください。
If instead the connection was initiated actively (came from the
SYN-SENT state) then flush the retransmission queue, inform the
user "Error: Connection refused", discard the packet, delete
the TCB, and go to the CLOSED state without any further
processing.
接続が代わりに活発(SYN-SENT状態から、来た)に開始されたなら再送キューを洗い流してくださいといって、ユーザに知らせてください、「誤り:」 「拒否された接続」、パケットを捨ててください、そして、TCBを削除してください、そして、さらなる処理なしでどんなCLOSED状態に行ってください。
D2 --------------------------------------------------------
D2--------------------------------------------------------
The packet is examined for a RST flag. If RST is not set then
return and continue the processing associated with this state.
パケットはRST旗がないかどうか調べられます。 RSTが用意ができていないなら、この状態に関連している処理を返して、続けてください。
RST is now assumed to have been set. Any data remaining to be
sent is flushed. The retransmission queue is flushed, the user
is informed "Error: Connection reset.", discard the packet,
delete the TCB, and go to the CLOSED state without any further
processing.
現在、RSTが設定されたと思われます。 送るために残っているどんなデータも紅潮しています。 再送キューが紅潮している、ユーザは知識がある、「誤り:」 「接続リセット」、パケットを捨ててください、そして、TCBを削除してください、そして、さらなる処理なしでどんなCLOSED状態に行ってください。
D3 --------------------------------------------------------
D3--------------------------------------------------------
The packet is examined for a RST flag. If RST is not set then
return and continue the processing associated with this state.
パケットはRST旗がないかどうか調べられます。 RSTが用意ができていないなら、この状態に関連している処理を返して、続けてください。
RST is now assumed to have been set. Discard the packet,
delete the TCB, and go to the CLOSED state without any further
processing.
現在、RSTが設定されたと思われます。 パケットを捨ててください、そして、TCBを削除してください、そして、さらなる処理なしでどんなCLOSED状態に行ってください。
Finn [Page 30]
フィンランド人[30ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
E --------------------------------------------------------
E--------------------------------------------------------
Check the presence of the SYN flag. If the SYN flag is not set
then return and continue the processing associated with this
state.
SYN旗の存在をチェックしてください。 SYN旗が設定されないなら、この状態に関連している処理を返して、続けてください。
We now assume that the SYN flag was set. The presence of a SYN
here is an error. Flush the retransmission queue, send a legal
RST packet.
私たちは、現在、SYN旗が設定されたと思います。 ここでのSYNの存在は誤りです。 再送キューを洗い流してください、そして、法的なRSTパケットを送ってください。
If the ACK flag was set then send:
ACK旗が設定されたなら、発信してください:
<SN=received AN><CTL=RST>
<SN=は><CTL=RST>を受けました。
If the ACK flag was not set then send:
ACK旗が設定されなかったなら、発信してください:
<SN=0><CTL=RST>
<SN=0><CTL=RST>。
The user should receive the message "Error: Connection reset.",
then delete the TCB and go to the CLOSED state without any
further processing.
ユーザがメッセージを受け取るべきである、「誤り:」 「接続リセット」、次に、TCBを削除してください、そして、さらなる処理なしでどんなCLOSED状態に行ってください。
F1 --------------------------------------------------------
F1--------------------------------------------------------
Check the presence of the ACK flag. If ACK is not set then
discard the packet and return without any further processing.
ACK旗の存在をチェックしてください。 ACKが用意ができていないなら、さらなる処理なしでどんなパケットとリターンを捨ててください。
We now assume that the ACK flag was set. If the AN field value
was as expected then return and continue the processing
associated with this state.
私たちは、現在、ACK旗が設定されたと思います。 予想されるとしてAN分野価値があったなら、この状態に関連している処理を返して、続けてください。
We now assume that the ACK flag was set and that the AN field
value was unexpected. If the connection was originally
initiated from the LISTEN state (it was passively opened) then
flush the retransmission queue, discard the packet, and send a
legal RST packet:
私たちは現在、ACK旗が設定されて、AN分野価値が予期していなかったと思います。 接続が元々LISTEN状態から開始されたなら(それは受け身に開かれました)、再送キューを洗い流してください、そして、パケットを捨ててください、そして、法的なRSTパケットを送ってください:
<SN=received AN><CTL=RST>
<SN=は><CTL=RST>を受けました。
Then delete the TCB and go to the LISTEN state without any
further processing.
次に、TCBを削除してください、そして、さらなる処理なしでどんなLISTEN状態に行ってください。
Otherwise the connection was initiated actively (came from the
SYN-SENT state) then inform the user "Error: Connection
refused", flush the retransmission queue, discard the packet,
and send a legal RST packet:
さもなければ、接続が活発(SYN-SENT状態から、来た)に開始されて、次に、ユーザに知らせてください、「誤り:」 「拒否された接続」、再送キューを洗い流してください、そして、パケットを捨ててください、そして、法的なRSTパケットを送ってください:
Finn [Page 31]
フィンランド人[31ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
<SN=received AN><CTL=RST>
<SN=は><CTL=RST>を受けました。
Then delete the TCB and go to the CLOSED state without any
further processing.
次に、TCBを削除してください、そして、さらなる処理なしでどんなCLOSED状態に行ってください。
F2 --------------------------------------------------------
F2--------------------------------------------------------
Check the presence of the ACK flag. If ACK is not set then
discard the packet and return without any further processing.
ACK旗の存在をチェックしてください。 ACKが用意ができていないなら、さらなる処理なしでどんなパケットとリターンを捨ててください。
We now assume that the ACK flag was set. If the AN field value
was as expected then flush the retransmission queue and inform
the user with an "Ok" if a buffer has been entirely
acknowledged. Another packet containing data may now be sent.
Return and continue the processing associated with this state.
私たちは、現在、ACK旗が設定されたと思います。 予想されるとしてAN分野価値があったなら、再送キューを洗い流してください、そして、バッファが完全に承認されたかどうかを「OK」をもっているユーザに知らせてください。 現在、データを含む別のパケットを送るかもしれません。 この状態に関連している処理を返して、続けてください。
We now assume that the ACK flag was set and that the AN field
value was unexpected. This is assumed to indicate a duplicate
acknowledgment. It is ignored, return and continue the
processing associated with this state.
私たちは現在、ACK旗が設定されて、AN分野価値が予期していなかったと思います。 これが写し承認を示すと思われます。 それは無視されます、そして、戻ってください、そして、この状態に関連している処理を続けてください。
F3 --------------------------------------------------------
F3--------------------------------------------------------
Check the presence of the ACK flag. If ACK is not set then
discard the packet and return without any further processing.
ACK旗の存在をチェックしてください。 ACKが用意ができていないなら、さらなる処理なしでどんなパケットとリターンを捨ててください。
We now assume that the ACK flag was set. If the AN field value
was as expected then continue the processing associated with
this state.
私たちは、現在、ACK旗が設定されたと思います。 予想されるとしてAN分野価値があったなら、この状態に関連している処理を続けてください。
We now assume that the ACK flag was set and that the AN field
value was unexpected. This is ignored, return and continue
with the processing associated with this state.
私たちは現在、ACK旗が設定されて、AN分野価値が予期していなかったと思います。 これは無視されます、そして、戻ってください、そして、この状態に関連している処理を続行してください。
G --------------------------------------------------------
G--------------------------------------------------------
This procedure represents the behavior of the CLOSED state of a
connection. All incoming packets are discarded. If the packet
had the RST flag set take no action. Otherwise it is necessary
to build a RST packet. Since this end is closed the other end
of the connection has incorrect data about the state of the
connection and should be so informed.
この手順は接続のCLOSED状態の振舞いを表します。 すべての入って来るパケットが捨てられます。 パケットでRST旗を設定したなら、行動を全く取らないでください。 さもなければ、RSTパケットを建てるのが必要です。 この終わりが閉じられるので、接続のもう一方の端は、接続の状態に関する間違ったデータを持って、とても知識があるべきです。
If the ACK flag was set then send:
ACK旗が設定されたなら、発信してください:
<SN=received AN><CTL=RST>
<SN=は><CTL=RST>を受けました。
Finn [Page 32]
フィンランド人[32ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
If the ACK flag was not set then send:
ACK旗が設定されなかったなら、発信してください:
<SN=0><AN=received SN+1 modulo 2><CTL=RST, ACK>
<SN=0><AN=はSN+1法2><CTL=RST、ACK>を受けました。
After sending the reset packet return to the current state
without any further processing.
リセットパケットを送った後に、さらなる処理なしでどんな現状まで戻ってください。
H1 --------------------------------------------------------
H1--------------------------------------------------------
Our SYN has been acknowledged. At this point we are
technically in the ESTABLISHED state. Send any initial data
which is queued to send:
私たちのSYNは承認されました。 ここに、私たちは技術的にESTABLISHED状態にあります。 発信するために列に並ばせられるあらゆる初期のデータを送ってください:
<SN=received AN><AN=received SN+1 modulo 2><CTL=ACK><DATA>
容認されたAN><<SN=AN=はSN+1法2><CTL=ACK><DATA>を受けました。
Go to the ESTABLISHED state and execute procedure I1 to process
any data which might be in this packet.
ESTABLISHED状態に行ってください、そして、手順I1を実行して、このパケットにあるあらゆるデータを処理してください。
Any packet not satisfying the above tests is discarded and
ignored. Return to the current state without any further
processing.
上のテストを満たさないどんなパケットも、捨てられて、無視されます。 さらなる処理なしでどんな現状まで戻ってください。
H2 --------------------------------------------------------
H2--------------------------------------------------------
Check the presence of the FIN flag. If FIN is not set then
continue the processing associated with this state.
FIN旗の存在をチェックしてください。 FINが用意ができていないなら、この状態に関連している処理を続けてください。
We now assume that the FIN flag was set. This means the other
end has decided to close the connection. Flush the
retransmission queue. If any data remains to be sent then
inform the user "Warning: Data left unsent." The user must
also be informed "Connection closing." An acknowledgment for
the FIN must be sent which also indicates this end is closing:
私たちは、現在、FIN旗が設定されたと思います。 これは、もう一方の端が、接続を終えると決めたことを意味します。 再送キューを洗い流してください。 何かデータが送るために残っているならユーザに知らせてください、「警告:」 「データはunsentを残しました。」 また、ユーザも「接続終わりであること」で知識があるに違いありません。 FINのためのまた、この終わりが閉じているのを示す承認を送らなければなりません:
<SN=received AN><AN=received SN + 1 modulo 2><CTL=FIN, ACK>
容認されたAN><<SN=AN=はSN+1法2><CTL=FIN、ACK>を受けました。
Go to the LAST-ACK state without any further processing.
さらなる処理なしでどんなLAST-ACK状態に行ってください。
Finn [Page 33]
フィンランド人[33ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
H3 --------------------------------------------------------
H3--------------------------------------------------------
This state represents the final behavior of the FIN-WAIT state.
この州はFIN-WAIT状態の最終的な振舞いを表します。
If the packet did not contain a FIN we assume this packet is a
duplicate and that the other end of the connection has not seen
the FIN packet we sent earlier. Rely upon retransmission of
our earlier FIN packet to inform the other end of our desire to
close. Discard the packet and return without any further
processing.
パケットがFINを含まなかったなら、私たちは、このパケットが写しであり、接続のもう一方の端が私たちが、より早く送ったFINパケットを見ていないと思います。 私たちの以前のFINパケットの「再-トランスミッション」を当てにして、閉じる私たちの願望のもう一方の端を知らせてください。 さらなる処理なしでどんなパケットとリターンを捨ててください。
At this point we have a packet which should contain a FIN. By
the rules of this protocol an ACK of a FIN requires a FIN, ACK
in response and no data. If the packet contains data we have
detected an illegal condition. Send a reset:
<SN=received AN><AN=received SN+1 modulo 2><CTL=RST, ACK>
ここに、私たちはFINを含むはずであるパケットを持っています。 このプロトコルの規則で、FINのACKはFIN、応答におけるACK、およびデータを全く必要としません。 パケットがデータを含んでいるなら、私たちは不法な状態を検出しました。 リセットを送ってください: 容認されたAN><<SN=AN=はSN+1法2><CTL=RST、ACK>を受けました。
Discard the packet, flush the retransmission queue, inform the
user "Error: Connection reset.", delete the TCB, and go to the
CLOSED state without any further processing.
パケットを捨ててくださいといって、再送キューを洗い流してくださいといって、ユーザに知らせてください、「誤り:」 「接続リセット」、TCBを削除してください、そして、さらなる処理なしでどんなCLOSED状態に行ってください。
We now assume that the FIN flag was set and no data was
contained in the packet. If the AN field value was expected
then this packet acknowledges a previously sent FIN packet.
The other end of the connection is then also assumed to be
closing and expects an acknowledgment. Send an acknowledgment
of the FIN:
私たちは、現在、FIN旗が設定されて、データが全くパケットに含まれなかったと思います。 AN分野価値が予想されたなら、このパケットは以前に送られたFINパケットを承認します。 接続のもう一方の端は、次に、また、閉じていると思われて、承認を予想します。 FINの承認を送ってください:
<SN=received AN><AN=received SN+1 modulo 2><CTL=ACK>
容認されたAN><<SN=AN=はSN+1法2><CTL=ACK>を受けました。
Start the 2*SRTT timer associated with the TIME-WAIT state,
discard the packet, and go to the TIME-WAIT state without any
further processing.
タイム誌-WAIT状態に関連している2*SRTTタイマを始動してください、そして、パケットを捨ててください、そして、さらなる処理なしでどんなタイム誌-WAIT状態に行ってください。
Otherwise the AN field value was unexpected. This indicates a
simultaneous closing by both sides of the connection. Send an
acknowledgment of the FIN:
さもなければ、AN分野価値は予期していませんでした。 これは接続の両側のそばで同時の閉鎖を示します。 FINの承認を送ってください:
<SN=received AN><AN=received SN+1 modulo 2><CTL=ACK>
容認されたAN><<SN=AN=はSN+1法2><CTL=ACK>を受けました。
Discard the packet, and go to the CLOSING state without any
further processing.
パケットを捨ててください、そして、さらなる処理なしでどんなCLOSING状態に行ってください。
Finn [Page 34]
フィンランド人[34ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
H4 --------------------------------------------------------
H4--------------------------------------------------------
This state represents the final behavior of the LAST-ACK state.
この州はLAST-ACK状態の最終的な振舞いを表します。
If the AN field value is expected then this ACK is in response
to the FIN, ACK packet recently sent. This is the final
acknowledging message indicating both side's agreement to close
the connection. Discard the packet, flush all queues, delete
the TCB, and go to the CLOSED state without any further
processing.
AN分野価値が予想されるなら、このACKはFIN、最近送られたACKパケットに対応しています。 これは両方を示す最終的な承認メッセージです。接続を終える側の協定。 パケットを捨ててください、そして、すべての待ち行列を洗い流してください、そして、TCBを削除してください、そして、さらなる処理なしでどんなCLOSED状態に行ってください。
Otherwise the AN field value was unexpected. Discard the
packet and remain in the current state without any further
processing.
さもなければ、AN分野価値は予期していませんでした。 パケットを捨ててください、そして、現状のときにさらなる処理なしでどんな残ってください。
H5 --------------------------------------------------------
H5--------------------------------------------------------
This state represents the final behavior of the CLOSING state.
この州はCLOSING状態の最終的な振舞いを表します。
If the AN field value was expected then this packet
acknowledges the FIN packet recently sent. This is the final
acknowledging message indicating both side's agreement to close
the connection. Start the 2*SRTT timer associated with the
TIME-WAIT state, discard the packet, and go to the TIME-WAIT
state without any further processing.
AN分野価値が予想されたなら、このパケットは最近送られたFINパケットを承認します。 これは両方を示す最終的な承認メッセージです。接続を終える側の協定。 タイム誌-WAIT状態に関連している2*SRTTタイマを始動してください、そして、パケットを捨ててください、そして、さらなる処理なしでどんなタイム誌-WAIT状態に行ってください。
Otherwise the AN field value was unexpected. Discard the
packet and remain in the current state without any further
processing.
さもなければ、AN分野価値は予期していませんでした。 パケットを捨ててください、そして、現状のときにさらなる処理なしでどんな残ってください。
H6 --------------------------------------------------------
H6--------------------------------------------------------
This state represents the behavior of the TIME-WAIT state.
Check the presence of the ACK flag. If ACK is not set then
discard the packet and return without any further processing.
この州はタイム誌-WAIT状態の振舞いを表します。 ACK旗の存在をチェックしてください。 ACKが用意ができていないなら、さらなる処理なしでどんなパケットとリターンを捨ててください。
Check the presence of the FIN flag. If FIN is not set then
discard the packet and return without any further processing.
FIN旗の存在をチェックしてください。 FINが用意ができていないなら、さらなる処理なしでどんなパケットとリターンを捨ててください。
We now assume that the FIN flag was set. This situation
indicates that the last acknowledgment of the FIN packet sent
by the other end of the connection did not arrive. Resend the
acknowledgment:
私たちは、現在、FIN旗が設定されたと思います。 この状況は、接続のもう一方の端までに送られたFINパケットの最後の承認が到着しなかったのを示します。 承認を再送してください:
<SN=received AN><AN=received SN+1 modulo 2><CTL=ACK>
容認されたAN><<SN=AN=はSN+1法2><CTL=ACK>を受けました。
Finn [Page 35]
フィンランド人[35ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
Restart the 2*SRTT timer, discard the packet, and remain in the
current state without any further processing.
2*SRTTタイマを再開してください、そして、パケットを捨ててください、そして、現状のときにさらなる処理なしでどんな残ってください。
I1 --------------------------------------------------------
I1--------------------------------------------------------
This represents that stage of processing in the ESTABLISHED
state in which all the flag bits have been processed and only
data may remain. The packet is examined to see if it contains
data. If not the packet is now discarded, return to the
current state without any further processing.
これはすべてのフラグビットが処理されて、データだけが残るかもしれないESTABLISHED州のその加工段階を表します。 パケットは、それがデータを含むかどうか確認するために調べられます。 パケットがどんな現在捨てられないなら、さらなる処理なしでどんな現状まで戻ってください。
We assume the packet contained data, that either the SO flag
was set or LENGTH is positive. That data is placed into the
user's receive buffers. As these become full the user should
be informed "Receive buffer full." An acknowledgment is sent:
私たちがパケットの含まれたデータを仮定するか、SOが弛むのが設定されたか、またはLENGTHは積極的です。 そのデータはユーザの受信バッファの中に置かれます。 これらが完全になるように、ユーザは知識がある「バッファをいっぱいに受け取ってください」であるべきです。 承認を送ります:
<SN=received AN><AN=received SN+1 modulo 2><CTL=ACK>
容認されたAN><<SN=AN=はSN+1法2><CTL=ACK>を受けました。
If data is queued to send then it is most efficient to
'piggyback' this acknowledgment on that data packet.
データが発信するために列に並ばせられるなら、この承認がそのデータ・パケットで'背負って'であることは最も効率的です。
The packet is now discarded, return to the ESTABLISHED state
without any further processing.
いずれのないESTABLISHED状態へのリターンがさらに処理されて、パケットは現在、捨てられます。
5.4. Timers
5.4. タイマ
There are three timers associated with this protocol. Their
purpose will now be briefly discussed as will the actions taken
when a timer expires. The particular nature these timeouts take
and the methods by which they are set is the responsibility of the
protocol implementation.
このプロトコルに関連している3個のタイマがあります。 現在、タイマが期限が切れるとき取られた行動のように簡潔にそれらの目的について議論するでしょう。 これらのタイムアウトが取る特定の自然とそれらが設定されているのが、プロトコル実現の責任であるということである方法。
5.4.1. User Timeout
5.4.1. ユーザタイムアウト
For practical implementation reasons it is desirable to have a
user controllable timeout associated with the successful
opening of a connection, successful acknowledgment of data, and
successful closing of a connection. Consider the situations in
which a connection is so noisy that no data gets through, or a
connection is physically cut. Without an overriding timeout
these situations would result in unbounded retransmissions.
実際的な実現理由で、接続のうまくいっている始まり、データのうまくいっている承認、および接続のうまくいっている閉鎖に関連しているユーザ制御可能なタイムアウトを持っているのは望ましいです。 接続がある状況がデータが全く通らないか、または接続が物理的に切られるほど騒がしいと考えてください。 最優先のタイムアウトがなければ、これらの状況は限りない「再-トランスミッション」をもたらすでしょう。
When this timeout expires the user is informed "Error:
Connection aborted due to user timeout.", all queues are
flushed, the TCB is deleted, and the CLOSED state is entered.
このタイムアウトが期限が切れるとき、ユーザは知識がある、「誤り:」 「接続はユーザタイムアウトのため中止になった」、すべての待ち行列が紅潮していて、TCBは削除されて、CLOSED状態は入られます。
Finn [Page 36]
フィンランド人[36ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
5.4.2. Retransmission Timeout
5.4.2. 再送タイムアウト
This timer ensures that any packet sent for which the SN is
significant is acknowledged. When such a packet is sent it is
placed in a retransmission queue and the retransmission timer
is begun. If an acknowledgment has not arrived within the
timer's period then the packet is retransmitted and the timer
is restarted. If the acknowledgment does arrive in time then
the timer is stopped and the packet is removed from the
retransmission queue. The next packet with a significant SN
may now be sent.
このタイマは、SNが重要である送られたどんなパケットも承認されるのを確実にします。 そのようなパケットを送るとき、それを再送キューに置きます、そして、再送信タイマーを始めます。 承認がタイマの期間中に到着していないなら、パケットは再送されます、そして、タイマは再開されます。 承認が時間内に到着するなら、タイマを止めます、そして、再送キューからパケットを取り除きます。 現在、重要なSNがある次のパケットを送るかもしれません。
This timeout is expected to operate in conjunction with a
counter which keeps track of the number of times a packet has
been retransmitted. Normally an upper limit is set on
retransmissions. If that limit is exceeded then the connection
is aborted. This event is similar to the user timeout. The
user is informed "Error: Connection aborted due to
retransmission failure", all queues are flushed, the TCB is
deleted, and the CLOSED state is entered.
このタイムアウトがパケットが再送されたという回の数の動向をおさえるカウンタに関連して作動すると予想されます。 通常、上限は「再-トランスミッション」に設定されます。 その限界が超えられているなら、接続は中止されます。 この出来事はユーザタイムアウトと同様です。 ユーザは知識がある、「誤り:」 すべての待ち行列が紅潮しています、そして、TCBは削除されます、そして、「接続は「再-トランスミッション」の故障のため中止になっ」て、CLOSED状態は入られます。
5.4.3. TIME-WAIT Timeout
5.4.3. 時間待ちタイムアウト
This timeout is used to catch any FIN packets which might be
retransmitted from the other end of a connection in response to
a dropped acknowledgment packet. The timeout period should be
at least as long as 2*SRTT. After this timeout expires the
other end of the connection is assumed to be closed, the TCB is
deleted, and this end enters the CLOSED state also.
このタイムアウトは、低下している確認応答パケットに対応して接続のもう一方の端から再送されるどんなFINパケットも捕らえるのに使用されます。 タイムアウト時間は2*SRTTと少なくとも同じくらい長いはずです。 TCBは削除されます、そして、このタイムアウトが期限が切れた後に、接続のもう一方の端が閉じられると思われて、この終わりはCLOSED状態にも入ります。
Finn [Page 37]
フィンランド人[37ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
6. Data Error Handling
6. データエラー処理
This chapter discusses in detail the types of data errors an established connection may encounter. These are distinct from protocol errors discussed above. In order of discussion these are:
本章は詳細に確立した接続が遭遇するかもしれないデータ誤りのタイプについて議論します。 これらは上で議論したプロトコル誤りと異なっています。 議論の順に、これらは以下の通りです。
- Framing Errors
- 縁どり誤り
- Missing SYNCH pattern
- なくなったSYNCHパターン
- Unacknowledged packets
- 不承認のパケット
- Bad packets
- 悪いパケット
- Duplicate packets
- パケットをコピーしてください。
- Outside flow control
- フロー制御の外で
- Packets that are too large
- 大き過ぎるパケット
- Packets that are too small
- 小さ過ぎるパケット
6.1. Framing Errors
6.1. 縁どり誤り
The RS-232 specification provides framing only for an individual
octet. Link level protocols for computer networking normally
provide framing for each packet. The SYNCH pattern provides a
boundary for the beginning of a packet. No similar pattern was
chosen to mark the end and completely frame the packet.
RS-232仕様は個々の八重奏のためだけの縁どりを提供します。 通常、コンピュータのネットワーク化のためのリンク・レベルプロトコルは各パケットのための縁どりを提供します。 SYNCHパターンはパケットの始まりの間、境界を提供します。 どんな同様のパターンも、終わりを示して、パケットを完全に縁どるために選ばれませんでした。
Any bit pattern can appear in the data portion of a packet. For
any particular pattern to reliably mark the end of a packet that
terminating pattern cannot be allowed to appear in the data. This
is usually accomplished by the sender altering any occurrence of
the terminating pattern in the data so that it is both no longer
recognizable as that pattern and also restorable upon receipt.
Both the sender and the receiver are required by this technique to
examine all the data. In the absence of a protocol chip to
perform this function, it is a source of some overhead.
どんなビット・パターンもパケットのデータ部に現れることができます。 どんな特定のパターンも、パケットの端がその終わりパターンであると確かにマークするのがデータに現れることができません。 これがデータにおける、終わりパターンのどんな発生も変更する送付者によって通常達成されるので、それも、もうそのパターンとして認識可能であって、かつまた、領収書で復元できません。 送付者と受信機の両方が、すべてのデータを調べるためにこのテクニックによって必要とされます。 この機能を実行するプロトコルチップがないとき、それは何らかのオーバーヘッドの源です。
6.1.1. Synthetic Framing
6.1.1. 合成の縁どり
In the absence of framing, the end of the packet must be
synthetically determined. The start of a packet is indicated
by the SYNCH pattern. The expected end of a packet can now
only be determined by examining the LENGTH octet of the header.
It is important to know whether or not the LENGTH data can be
縁どりがないとき、パケットの端は総合的に断固としていなければなりません。 パケットの始まりはSYNCHパターンによって示されます。 パケットの予想された端は、現在、ヘッダーのLENGTH八重奏を調べることによって、決定できるだけです。 LENGTHデータがそうであることができるかどうかを知るのは重要です。
Finn [Page 38]
フィンランド人[38ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
trusted. This is accomplished by employing a one octet header
checksum to cover the first two octets following the SYNCH
pattern. If the header passes the checksum test and neither
the SYN, FIN, RST, nor SO flag bits were set then LENGTH is
trusted and the number of octets expected beyond the header is
LENGTH+2. (For those packets in which any of the above flag
bits are set the packet length is fixed and includes only a
header portion.)
信じられる。 これは、SYNCHパターンに従って、最初の2つの八重奏をカバーするのに1つの八重奏のヘッダーチェックサムを使うことによって、達成されます。 ヘッダーがチェックサムテストとどちらもSYNを渡さないか、そして、FIN、RST、およびSOフラグビットはセットの当時のLENGTHが信じられて、ヘッダーを超えて予想された八重奏の数がLENGTH+2であるということでした。 (上のフラグビットのいずれも設定されるそれらのパケットに関して、パケット長は、修理されていて、ヘッダー部分だけを含んでいます。)
If the header fails the checksum test we are in some
difficulty. The length is incorrect so it may be too small or
too large. To recover from this error do the following.
Beginning immediately after the SYNCH pattern rescan looking
for the next SYNCH pattern. Throw away all octets until a
SYNCH is seen and then attempt to reinterpret it as a packet.
The sender's retransmission timeout guarantees that a new copy
of the packet will be transmitted. This ensures that in
discarding the initial SYNCH pattern, the SYNCH pattern from
the beginning of the retransmitted packet will eventually be
seen.
ヘッダーがチェックサムテストに失敗するなら、私たちが困難にいます。 それは、長さが不正確であり、小さ過ぎるので大き過ぎるかもしれません。 この誤りから克服するには、以下をしてください。 SYNCHパターン直後、次のSYNCHパターンを探しながら、再スキャンしてください。 SYNCHが見られるまで、すべての八重奏を無駄にしてください、そして、次に、パケットとしてそれを解釈し直すのを試みてください。 送付者の再送タイムアウトは、パケットの新しいコピーが伝えられるのを保証します。 これは、初期のSYNCHパターンを捨てる際に、再送されたパケットの始まりからのSYNCHパターンが結局見られるのを確実にします。
6.1.2. Costs of Synthetic Framing
6.1.2. 合成の縁どりのコスト
This framing strategy causes no overhead unless data errors
occur in the packet. This is presumed to be a low probability
occurrence. In addition it removes the overhead of both sender
and receiver passing over the data to process any termination
pattern which might appear in the data.
データ誤りがパケットに発生しないなら、この縁どり戦略はオーバーヘッドを全く引き起こしません。 これはあえて低い確率発生されること。 さらに、それは、データに現れるどんな終了パターンも処理するために送付者と受信機通過の両方のオーバーヘッドをデータの上に移します。
The worst case behavior would require a packet header to fail
its checksum, a new SYNCH pattern to appear in the next few
octets, that header failing its checksum, etc., until the SYNCH
pattern of the retransmitted packet were finally seen.
Consistently bad behavior of this type indicates an extremely
noisy communications link.
最悪の場合の振舞いは、パケットのヘッダーがチェックサムに失敗するのを必要とするでしょう、次のわずかな八重奏、チェックサムに失敗するそのヘッダーなどで見える新しいSYNCHパターン、再送されたパケットのSYNCHパターンが最終的に見られるまで。 このタイプの一貫して悪い振舞いは非常に騒がしいコミュニケーションリンクを示します。
6.2. Missing SYNCH Pattern
6.2. なくなった同時性パターン
Any valid packet must begin with the SYNCH pattern. Any receiver
must discard all input octets until the SYNCH pattern is seen.
The data which immediately follows a SYNCH pattern is interpreted
as a packet. The header checksum test is applied, then LENGTH+2
octets are read, the data checksum test is applied, etc.
どんな有効なパケットもSYNCHパターンで始まらなければなりません。 SYNCHパターンが見られるまで、どんな受信機もすべての入力八重奏を捨てなければなりません。 すぐにSYNCHパターンに従うデータはパケットとして解釈されます。 ヘッダーチェックサムテストが適用されている、次に、LENGTH+2八重奏は読まれて、データチェックサムテストは適用されていますなど。
Finn [Page 39]
フィンランド人[39ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
6.3. Unacknowledged Packets
6.3. 不承認のパケット
If an ACK for a packet is not obtained within the retransmission
timeout interval that packet is retransmitted. Because
significant variability in response can be expected from either
end of a connection it is best to dynamically calculate the
retransmission timeout interval. An example of such a calculation
is provided below. The protocol will operate successfully,
although not with as high an effective transmission rate, if a
realistic upper bound time is used instead.
パケットのためのACKが再送タイムアウト間隔中に入手されないなら、そのパケットは再送されます。 どちらの終わりからも接続に応答における重要な可変性を予想できるので、ダイナミックに再送タイムアウト間隔について計算するのは最も良いです。 そのような計算に関する例を以下に提供します。 プロトコルは首尾よく作動するでしょう、どんな同じくらい高い有効な通信速度でもそうしませんが、現実的な上限時間が代わりに費やされるなら。
A realistic upper bound time depends upon the packet size and line
speed. If the baud rate of the connection is 300 or above let B
be the baud rate (for clarity assume it is the same in both
directions), let L be the MDL of the receiver, let P be the packet
processing time of the receiver. Then an Upper Bound for the
Reception Time (UBRT) is:
現実的な上限時間はパケットサイズとライン・スピードに依存します。 接続のボーレートが300以上であるなら、Bがボーレートであることをさせてください、そして、(明快には、それが両方の方向と同じであると仮定してください)Lが受信機のMDLであることをさせてください、そして、Pが受信機のパケット処理時間であることをさせてください。次に、Reception Time(UBRT)のためのUpper Boundは以下の通りです。
UBRT = L/(B/10) seconds + P seconds
UBRTはL/と(B/10)秒+P秒等しいです。
and a realistic upper bound time is 2*UBRT seconds.
そして、現実的な上限時間は2*UBRT秒です。
6.3.1. Calculation of Retransmission Timeout Interval
6.3.1. 再送タイムアウト間隔の計算
For the purpose of detecting retransmission time out the
protocol must have access to a clock which provides at least
single second resolution. One technique for calculating the
round trip time is:
「再-トランスミッション」タイムアウトを検出する目的のために、プロトコルは少なくとも2番目のただ一つの解決を提供する時計に近づく手段を持たなければなりません。 周遊旅行時間について計算するための1つのテクニックは以下の通りです。
Measure the elapsed time between sending a packet with a
particular SN and receiving an ACK with an AN which covers
that SN. The measured elapsed time is the Round Trip Time
(RTT). Next a Smoothed Round Trip Time (SRTT) is calculated
as:
特定のSNと共にパケットを送って、そのSNを覆うANと共にACKを受けるとき、経過時間を測定してください。 測定経過時間はRound Trip Time(RTT)です。 次に、Smoothed Round Trip Time(SRTT)は以下として計算されます。
SRTT = (ALPHA * SRTT) + ((1- ALPHA) * RTT)
SRTTは+と等しいです(アルファ*SRTT)。((1つのアルファ)*RTT)
and based upon this you compute the Retransmission Time Out
(RTO) as:
そして、これに基づいて、あなたは以下としてRetransmission Time Out(RTO)を計算します。
RTO = min[UBOUND, max[LBOUND, (BETA * SRTT)]]
RTO=分[UBOUND、最大[LBOUND、(ベータ*SRTT)]]
where UBOUND is an upper bound on the timeout (e.g., 1
minute), LBOUND is a lower bound on the timeout (e.g., 1
second), ALPHA is a smoothing factor (e.g., .8 to .9), and
BETA is a delay variance factor (e.g., 1.3 to 2.0).
UBOUNDがタイムアウト(例えば、1分)の上限であるところでは、LBOUNDはタイムアウト(例えば、1秒)における下界です、そして、アルファーはスムージング要素(例えば、.8〜.9)です、そして、BETAは遅れ変化の要素(例えば、1.3〜2.0)です。
Finn [Page 40]
フィンランド人[40ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
6.4. Bad Packets
6.4. 悪いパケット
A bad packet is received when it fails either the header or data
checksum tests. When this happens the sender will retransmit the
packet after the retransmission timeout interval.
ヘッダーかデータチェックサムテストに失敗するとき、悪いパケットは受け取られています。 これが起こると、送付者は再送タイムアウト間隔の後にパケットを再送するでしょう。
6.5. Duplicate Packets
6.5. パケットをコピーしてください。
A duplicate packet is a packet which passes the checksum tests but
for which the SN received is significant but not the expected
value. This is normally caused when the sender did not get the
ACK last sent by the receiver. This situation is diagrammed
below.
写しパケットは期待値ではなく、合格しますが、受け取られたSNがチェックサムテストが重要であるパケットです。 送付者が最後に受信機でACKを送らせなかったとき、通常、これを引き起こします。この状況は以下に図解されます。
Side A Side B
側Bに面があってください。
ESTABLISHED ESTABLISHED
確立していた状態で、設立されます。
1. --> <SN=1><AN=0><CTL=ACK><DATA> ...
-->
1. --><SN=1><は=0><CTL=ACK><データ>です…。 -->。
2. XXX <SN=0><AN=0><CTL=ACK><OTHER-DATA> <--
2. XXX<SN=0><、=0のCTL=ACKの>の<の他のデータの>><<--
3. (after SRTT)
--> <SN=1><AN=0><CTL=ACK><DATA> ...
3. (SRTTの後の) --><SN=1><は=0><CTL=ACK><データ>です…。
4. -->
... <SN=0><AN=0><CTL=ACK><OTHER-DATA> <--
4. -->… <SN=0><、=0のCTL=ACKの>の<の他のデータの>><<--
5. <--
5. <--
In line 2, B's packet was lost in transit, it may have failed its
checksum tests when it reached A or its initial SYNCH pattern was
smashed, etc.. In line 3 side A comes to the decision that its
packet from line 1 was not received after SRTT time passes and
retransmits that packet.
線2では、ビーズパケットはトランジットで失われて、それはAに達したか、または初期のSYNCHパターンがつぶされたときのチェックサムテストなどに失敗したかもしれません。 並んで、3側AはSRTT時間がそのパケットを通過して、再送した後に線1からのパケットが受け取られなかったという結論に達します。
In line 4 side B receives the packet. It detects a duplicate
because it already sent a packet acknowledging A's SN=1 (although
that packet was lost). B now discards the duplicate and
immediately retransmits its last packet to A. Side A finally
receives the retransmitted packet in line 5.
並んで、4側Bはパケットを受けます。 それは、既にパケット承認AのSN=1を送ったので(そのパケットが失われましたが)、写しを検出します。 Bは、現在、写しを捨てて、すぐに、最後のパケットをA.に再送します。Side Aは線5で最終的に再送されたパケットを受けます。
Finn [Page 41]
フィンランド人[41ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
6.6. Outside Flow Control
6.6. フロー制御の外で
There are many large computer systems which make use of flow
control to regulate their input side of an RS-232 link. Flow
control based upon two special characters such as <Ctrl-S> (ASCII
DC3) and <Ctrl-Q> (ASCII DC1) is almost universally in use today.
So it becomes important for the protocol to be able to either:
彼らのRS-232リンクのインプット側を整えるのにフロー制御を利用する多くの大きいコンピュータ・システムがあります。 <Ctrl-S>(ASCII DC3)や<Ctrl-Q>(ASCII DC1)などの2つの特殊文字に基づくフロー制御は今日、ほとんど一般に使用中です。 それで、プロトコルがどちらかにできるのは重要になります:
(1) Recognize and obey the flow control of the host
computer(s), or
または(1) ホストコンピュータのフロー制御を認識して、従ってください。
(2) Ignore the flow control but still guarantee reliable data
reception.
(2) フロー制御を無視しなさい、ただし、それでも、確実な資料レセプションを保証してください。
It is the latter approach which this protocol takes. This
decision was made because the number of differing flow control
characters in use would make it difficult to obey them all.
それはこのプロトコルが取る後者のアプローチです。 彼らに皆、従うのは使用中の異なったフロー制御キャラクタの数で難しくなるでしょう、したがって、この決定をしました。
There is a particular type of flow control with which this
protocol will not operate. The ENQUIRE, ACKNOWLEDGE method of
flow control requires that the receiver of an inquiry respond
with an acknowledge before any more data will be sent to it.
This type of flow control also usually prohibits unrestricted
8-bit data transmission because the inquiry character is
forbidden as a data byte.
このプロトコルが作動しない特定のタイプのフロー制御があります。 ENQUIRE、フロー制御のACKNOWLEDGE方法が問い合せの受信機が応じるのを必要とする、以前、それ以上のデータがそれに送られると認めてください。 また、問い合せキャラクタが1データ・バイトとして禁じられるので、通常、このタイプのフロー制御は無制限な8ビットのデータ送信を禁止します。
For the other class of flow control methods a proof is required
that data may still be reliably transmitted and received if flow
control is ignored. For the purposes of this discussion assume
<Ctrl-S> is sent when the receiving end of the connection wishes
the sender to stop transmitting. A <Ctrl-Q> is sent when the
receiver wishes the sender to resume. The choice of these
particular two characters is arbitrary. If the sender does not
immediately cease transmission upon receipt of the <Ctrl-S>,
characters may be discarded. Since this protocol chooses to
ignore the flow control characters any part of a packet may be
discarded.
もう片方のクラスのフロー制御方法において、フロー制御を無視するなら、まだデータを確かに送って、受け取っているかもしれないという証拠が、必要です。 この議論の目的には、接続の犠牲者が、送付者が、伝わるのを止める必要があるとき、<Ctrl-S>が送られると仮定してください。 受信機が、送付者が再開する必要があるとき、<Ctrl-Q>を送ります。 これらの特定の2つのキャラクタの選択は任意です。 送付者がすぐに<Ctrl-S>を受け取り次第トランスミッションをやめないなら、キャラクタは捨てられるかもしれません。 このプロトコルが、フロー制御キャラクタを無視するのを選ぶので、パケットのどんな一部も捨てられるかもしれません。
More precisely stated consider X to be the receiver and Y to be
the sender. The packet sent is represented by the string abc
where a, b, and c are data segments of unspecified size. X may
receive one of:
以上は、送付者になるようにXが受信機とYであると考えるように正確に述べました。 送られたパケットはa、b、およびcが不特定のサイズのデータ・セグメントであるストリングabcによって表されます。 Xは1を受け取るかもしれません:
1. abc
2. ab
3. ac
4. bc
1. abc2腹筋3ac4bc
Finn [Page 42]
フィンランド人[42ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
For case [1] the correct data is received and no special action
need be taken.
ケース[1]において、正しいデータは受信されています、そして、どんな特別な行動も取る必要はありません。
For cases [2], [3], and [4] we have a situation identical to data
dropped during transmission. This is handled by the same
checksum, time-out and retransmission strategy already described.
ケース[2]、[3]、および[4]のために、私たちには、トランスミッションの間に落とされたデータと同じ状況があります。 これは既に説明された同じチェックサム、タイムアウト、および「再-トランスミッション」戦略で扱われます。
Assume Y is not now in the act of receiving a packet, then Y sees
the two characters <Ctrl-S> and <Ctrl-Q> appear as input in that
order. Y is waiting for a message to appear and so expects to see
a SYNCH pattern. If the two characters "<Ctrl-S><Ctrl-Q>" are not
part of a SYNCH pattern then they will be immediately discarded.
If Y is receiving a packet then the <Ctrl-S> and <Ctrl-Q> are seen
to be added noise characters and would be detected by the checksum
tests. The packet being received would require retransmission.
2のキャラクタ<Ctrl-S>と<Ctrl-Q>がそのオーダーで入力されるように見えるのをYが現在、パケットを受ける行為中でなく、次に、Yが、見ると仮定してください。 Yは、現れるメッセージを待っているので、SYNCHパターンを見ると予想します。 2であるなら、キャラクタ「<Ctrl-S><Ctrl-Q>」はSYNCHパターンの一部でなく、次に、彼らはすぐに、捨てられるでしょう。 Yがパケットを受けているなら、<Ctrl-S>と<Ctrl-Q>は加えられた雑音キャラクタであると考えられて、チェックサムテストで検出されるでしょう。 受け取られるパケットは「再-トランスミッション」を必要とするでしょう。
The question of which character to pick for the SYNCH pattern is
slightly muddied by the above observation. To the author's
knowledge <SOH> is rarely if ever picked for flow control. This
is part of the motivation in using it as the SYNCH pattern.
SYNCHパターンにどのキャラクタを選んだらよいかに関する質問は上の観測でわずかに濁されます。 作者のものが知っている限り、今までにフロー制御に選ばれるなら、めったに<SOH>はそうです。 これはSYNCHが型に基づいて作るのでそれを使用することにおける動機の一部です。
How does one guarantee that any data will actually arrive
successfully? The initial choice of maximum data counts during
connection establishment is very important. Some knowledge of
one's own operating system must be assumed. If it is known for
example, that streams of data in excess of a certain length will
often trigger flow control at the connection baud rate, then the
maximum data count should be chosen sufficiently lower that flow
control rarely will be employed. An intelligent choice of the
maximum data count will guarantee that some packets will arrive
without encountering flow control.
1つは、どんなデータも実際にどのように首尾よく到着するのを保証しますか? コネクション確立の間の最大のデータカウントの初期の選択は非常に重要です。 自分自身のオペレーティングシステムに関する何らかの知識を想定しなければなりません。 それが接続ボーレートで例えば、ある長さを超えたデータのそのストリームがしばしばフロー制御の引き金となるのを知って、次に、十分下ろす最大のデータカウントが選ばれるべきであることであるなら、そのフロー制御はめったに使われないでしょう。 最大のデータカウントの利口な選択は、いくつかのパケットがフロー制御に遭遇しないで到着するのを保証するでしょう。
6.7. Packets that are too Large
6.7. パケット、もLarge
Assume a packet arrives which passes its header checksum test but
whose LENGTH is larger than the MDL of the receiver. In such a
case the sender has violated the protocol or a packet has a data
error in the LENGTH octet and has passed the header checksum test.
The latter is unlikely so that we assume the former. The receiver
will abort his connection. The sender must inform the user
"Error: Connection aborted due to MDL error", and go to the CLOSED
state.
合格しますが、LENGTHが受信機のMDLよりヘッダーチェックサムテストが大きいパケットが到着すると仮定してください。このような場合には送付者がプロトコルに違反したか、パケットは、LENGTH八重奏におけるデータ誤りを持って、ヘッダーチェックサムテストに合格しました。 後者がありそうもないので、私たちは前者を仮定します。 受信機は彼の接続を中止するでしょう。 送付者がユーザに知らせなければならない、「誤り:」 「接続はMDL誤りのため中止になっ」て、CLOSED状態に行ってください。
When the MDL is exceeded the receiver will transmit a legal reset:
MDLが超えられているとき、受信機は法的なリセットを伝えるでしょう:
<SN=received AN><CTL=RST>
<SN=は><CTL=RST>を受けました。
Finn [Page 43]
フィンランド人[43ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
6.8. Packets that are too Small
6.8. パケット、もSmall
Assume that a packet has passed its header checksum test but some
of the data octets have been dropped by the link. In such a case
the receiver's routine which reads data and builds packets is
expecting octets which do not arrive. After SRTT the sender will
retransmit this packet to the receiver. The receiver will now
have enough data to complete the packet. Almost certainly however
it will fail the data checksum test. As with any bad packet the
receiver will rescan from the octet immediately following the
SYNCH pattern for the next SYNCH pattern. In this manner the
receiver will eventually see the SYNCH pattern of the
retransmitted packet.
パケットがヘッダーチェックサムテストに合格しましたが、データ八重奏のいくつかがリンクによって落とされたと仮定してください。 データを読んで、パケットを建てるこのような場合には受信機のルーチンが到着しない八重奏を予想しています。 SRTTの後に、送付者はこのパケットを受信機に再送するでしょう。受信機には、現在、パケットを完成できるくらいのデータがあるでしょう。 しかしながら、ほぼ確実に、それはデータチェックサムテストに失敗するでしょう。 どんな悪いパケットの場合も、すぐに次のSYNCHパターンのためのSYNCHパターンに従って、受信機は八重奏から再スキャンされるでしょう。 この様に、受信機は結局、再送されたパケットのSYNCHパターンを見るでしょう。
Finn [Page 44]
フィンランド人[44ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
I. Inability to Transmit/Receive 8-bit Data
I. 8ビットのデータを送ることができないか、受け取ることができないこと
There are some older operating systems and devices which do not permit 8-bit communication over an RS-232 link. Most of these allow restricted 7-bit communication. Where this is an unavoidable problem both ends of the connection must have a protocol layer beneath this protocol. This lower layer will unpack packets it sends over the RS-232 link. It will also repack packets it receives over the RS-232 link. RATP will automatically determine whether or not full 8-bit or restricted 7-bit communication is being used (see below).
RS-232リンクの上に8ビットのコミュニケーションを可能にしないいくつかの、より古いオペレーティングシステムと装置があります。 これらの大部分は制限された7ビットのコミュニケーションを許容します。 これがプロトコルがこれの下で接続の両端で層にしなければならない避けて通れない問題であるところでは、議定書を作ってください。 この下層はそれがRS-232リンクの上に送るパケットをアンパックするでしょう。 それはRS-232リンクの上に受ける「再-パック」パケットもそうするでしょう。 RATPは、完全な8ビットの、または、制限された7ビットのコミュニケーションが使用されているかどうか(以下を見てください)自動的に決定するでしょう。
The strategy chosen for restricted 7-bit communication is called 4/8 packing. That is, each octet to be sent will be broken up into two 4-bit nibbles. The order of transmission is the high order four bits followed by the low order bits. Each octet to be received will be repacked by the inverse function. The high order nibble will be received first then the low order nibble. These two nibbles will be reassembled into an octet.
制限された7ビットのコミュニケーションに選ばれた戦略は4/8パッキングと呼ばれます。 すなわち、送られる各八重奏は2つの4ビットの少量に終えられるでしょう。 トランスミッションの注文は下位のビットに応じて4ビットがいうことになった高位です。 各受け取られるべき八重奏は逆さの機能によって再梱包されるでしょう。 高位少量は次に、容認された1番目が下位の少量であったならそうするでしょう。 これらの2つの少量が八重奏に組み立て直されるでしょう。
I.1. Encoding for Transmission
I.1。 トランスミッションのためのコード化
For those systems which are incapable of 8-bit data transmission
over RS-232 links, there are operating systems which in addition
place special restrictions on the non-printable ASCII characters.
The encoding for 4/8 packing should restrict itself to
transmitting data only in the printable 7-bit ASCII range.
それらのRS-232リンクの上の8ビットのデータ送信で不可能なシステムのために、非印刷可能なASCII文字に関してさらに、特別な制限を課すオペレーティングシステムがあります。 パッキングがそれ自体を制限するべきである4/8のための印刷可能な7ビットのASCII範囲だけでデータを送るコード化。
I.2. Framing an Octet
I.2。 八重奏を縁どっています。
The seventh and highest order bit of a transmitted 7-bit ASCII
byte is a flag used to indicate whether the high or low order
nibble of an octet is contained in this character. This flag bit
if set implies that a new octet is being received and that this
printable ASCII character contains the high order nibble of an
octet in its four low order bits. In addition it implies the next
ASCII character received should not have its highest order bit
set.
伝えられた7ビットのASCIIバイトの7番目の、そして、最も高いオーダービットは八重奏の高いか低いオーダー少量がこのキャラクタに含まれているかどうかを示すのに使用される旗です。 設定されるなら噛み付かれたこの旗は、新しい八重奏を受けていて、この印刷可能なASCII文字が4下位のビットの八重奏の高位少量を含むのを含意します。 さらに、それは、キャラクタが受けた次のASCIIで最も高いオーダービットを設定するべきでないのを含意します。
This high order flag bit is set by adding the ASCII character "@"
(octal 100) to a data byte. Thus the first nibble of an octet is
always transmitted with "@" added to its value. The high order
nibble will be transformed into the characters "@" through letter
"O".
1データ・バイトへのASCII文字"@"(8進100)を加えることによって、この高位フラグビットはセットです。 したがって、"@"が値に加えられている状態で、八重奏の最初の少量がいつも伝えられます。 高位少量が文字「O」によるキャラクタ"@"に変えられるでしょう。
The lower order nibble of an octet is transmitted with zero "0"
added to its value. The low order nibble will be transformed into
八重奏の下層階級少量が「0インチは箔をつけなかったこと」で伝えられます。 下位の少量に変形するでしょう。
Finn [Page 45]
フィンランド人[45ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
characters "0" through "?". When receiving 4/8 packed data, any
characters not within the range "0" through letter "O" are
discarded.
キャラクタ、「“?"を通した0インチ。」 受信するとき、4/8はデータを梱包して、範囲の中のどんなキャラクタも「文字「O」による0インチは捨てられます」です。
The octet whose octal value is 45 will be transmitted as two 7-bit
printable ASCII characters:
8進値が45である八重奏は2人の7ビットの印刷可能なASCII文字として伝えられるでしょう:
+-------------+
High order |1|0|0|0|1|0|0| First transmitted ("@" + data) = D
+-------------+
Low order |0|1|1|0|1|0|1| Second transmitted ("0" + data) = 5
+-------------+
+-------------+ 高位|1|0|0|0|1|0|0| 1番目は("@"+データ)=D+を伝えました。-------------+ 下位|0|1|1|0|1|0|1| 2番目が伝わった、(「0インチ+データ) =5+」-------------+
Since data bytes may be dropped or added at any time it is
important to know always which portion of an octet is expected and
to deliver only complete octets to the higher protocol level. If
a single 7-bit character were completely dropped without being
noticed the data stream delivered to the higher level could be
shifted by an odd multiple of four bits. In the worst case this
condition could remain indefinitely and the higher level would
never receive an octet correctly. In such a case no packets would
be correctly received, leading to an unusable connection.
データ・バイトがいつでも落とされるか、または加えられるかもしれないので、いつも八重奏のどの部分が予想されるかを知って、より高いプロトコルレベルに完全な八重奏だけを提供するのは重要です。 単独の7ビットのキャラクタが悟られずに完全に落とされるなら、4ビットの変な倍数で、より高いレベルに届けられたデータ・ストリームは移動させられることができるでしょうに。 最悪の場合にはこの状態は無期限に残るかもしれません、そして、より高いレベルは八重奏を決して正しく受けません。 使用不可能な接続に通じて、正しくこのような場合にはパケットを全く受け取らないでしょう。
To avoid this problem octets are assembled using a state machine
driven by the presence of the high order flag bit. The presence
of that bit in the 7-bit printable character indicates the
beginning of a new octet. The two state machine which assembles
octets is described below. A byte received with the high order
flag bit set is called "HIGH", the byte without "LOW".
この問題を避けるために、八重奏は高位フラグビットの存在によって動かされた州のマシンを使用することで組み立てられます。 7ビットの印刷可能なキャラクタでのそのビットの存在は新しい八重奏の始まりを示します。 八重奏を組み立てる2州のマシンは以下で説明されます。 フラグビットが設定した高位で受け取られた1バイトは「安値」なしで「高値」、バイトと呼ばれます。
State 0
状態0
[Start state] Read a byte from the legal restricted set.
This is determined by seeing if the byte is in the legal
range "@" to the letter "O". If it was not discard the byte
and return to this state.
[状態を始めます] 法的な制限されたセットから1バイトを読んでください。 文字「O」にバイトが法的な範囲"@"にあるかわかることによって、これは決定します。 それがそうでなかったなら、バイトを捨ててください、そして、この状態に戻ってください。
A HIGH byte was read. Place the four low order bits of the
byte into the four high order bits of the assembled octet
and go to state 1. Otherwise discard the byte and return to
this state.
HIGHバイトは読まれました。 組み立てられた八重奏の4高位のビットへのバイトの4下位のビットで入賞してください、そして、1を述べに行ってください。 さもなければ、バイトを捨ててください、そして、この状態に戻ってください。
Finn [Page 46]
フィンランド人[46ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
State 1
状態1
Read a byte from the legal restricted set. This is
determined by seeing if the byte is in the legal range zero
"0" to the letter "O". If it was not discard the byte and
return to this state.
法的な制限されたセットから1バイトを読んでください。 バイトが法的な範囲に何か「文字「O」への0インチ」ないかわかることによって、これは決定します。 それがそうでなかったなら、バイトを捨ててください、そして、この状態に戻ってください。
If a LOW byte was read subtract zero "0" from the byte
placing the four low order bits of the result into the four
low order bits of the assembled octet. A full octet has now
been assembled. Pass the octet to the higher level and go
to state 0.
LOWバイトがそうであったなら、読まれて、どんな「組み立てられた八重奏の4下位のビットに4下位のビットの結果を置くバイトからの0インチ」も引き算しないでください。 完全な八重奏は現在、組み立てられました。 より高いレベルに八重奏を通過してください、そして、0を述べに行ってください。
Otherwise a HIGH byte was read. Place the four low order
bits of the byte into the four high order bits of the
assembled octet and return to this state.
さもなければ、HIGHバイトは読まれました。 組み立てられた八重奏の4高位のビットへのバイトの4下位のビットで入賞してください、そして、この状態に戻ってください。
Utilizing this state machine to receive 4/8 packed data ensures
that the data stream delivered to the higher level will not
permanently remain shifted an odd multiple of four bits. The
restriction placed upon bytes read removes obviously bad data and
in some cases would handle uncontrolled padding or blocking
insertion.
詰まっているデータが確実にする4/8を受け取るのにこの州のマシンを利用して、より高いレベルに届けられたデータ・ストリームが永久に残っていないのが4ビットの変な倍数を移行させました。 読まれたバイトに置かれた制限は、明らかに悪いデータを取り除いて、いくつかの場合、非制御の詰め物かブロッキング挿入を扱うでしょう。
I.3. Automatic Detection of 8-bit or 4/8 Packed Data
I.3。 8ビットか4/8ビット詰まっているデータの自動検出
It is an unavoidable problem that some machines cannot handle
unrestricted 8-bit data. Since this is given, it is desirable to
be able to automatically detect whether unrestricted 8-bit or
restricted 4/8 packing is being used to transmit data on a
connection. For the purposes of this discussion those machines
capable of transmitting and receiving both unrestricted 8-bit and
4/8 packed data are called smart. Machines are called dumb if
they can only transmit and receive 4/8 packed data.
それはいくつかのマシンが無制限な8ビットのデータを扱うことができないという避けて通れない問題です。 これを与えるので、無制限な8ビットの、または、制限された4/8パッキングが接続に関するデータを送るのに使用されているかどうか自動的に検出できるのは望ましいです。 この議論の目的のために、両方の8ビットと4/8の無制限な詰まっているデータを送って、受け取ることができるそれらのマシンは賢いと呼ばれます。 4/8の詰まっているデータしか送受信できないなら、マシンは馬鹿であると呼ばれます。
When initiating a connection there are four possible machine
configurations and they are:
接続を開始して、いつ、4つの可能な機械コンフィギュレーションがあるか、そして、それらは以下の通りです。
1. A (smart) opens a connection to B (smart).
1. A(賢い)はB(賢い)に接続を開きます。
2. A (dumb) opens a connection to B (smart).
2. A(馬鹿な)はB(賢い)に接続を開きます。
3. A (dumb) opens a connection to B (dumb).
3. A(馬鹿な)はB(馬鹿な)に接続を開きます。
4. A (smart) opens a connection to B (dumb).
4. A(賢い)はB(馬鹿な)に接続を開きます。
Finn [Page 47]
フィンランド人[47ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
Each case is examined and extensions to the behavior for the
LISTEN and SYN-SENT states are provided which allow both types of
machines to initiate or receive a connection.
LISTENとSYN-SENT州への振舞いへの両方のタイプのマシンが接続を開始するか、または受ける拡大を、各ケースを調べて、提供します。
Cases 1 and 2: LISTEN Behavior for a Smart Machine
ケース1と2: スマートマシンのための振舞いを聴いてください。
In these cases machine A initiates a connection to B who is
assumed to be in the LISTEN state. B must be able to passively
detect whether 8-bit or 4/8 packing is being used and respond
accordingly. The method B uses relies upon the detection of a
valid first packet. In the LISTEN state B attempts to
simultaneously treat the incoming data as if it were both
unrestricted 8-bit and 4/8 packed.
これらの場合では、マシンAはBとのLISTEN状態にいると思われる接続を開始します。 Bは、8ビットか4/8ビットパッキングが使用されているかどうか受け身に検出して、それに従って、こたえることができなければなりません。 Bが使用する方法は有効な最初のパケットの検出を当てにします。 LISTENでは、州Bは、まるでそれがともに8ビットで無制限であるかのように同時に受信データを扱うのを試みます、そして、4/8は荷造りしました。
The incoming data is in effect fed to two different receiving
algorithms. The detection of a valid header will occur to one
of these algorithms before the other. If the first valid
header was read assuming unrestricted 8-bit data then any
resulting connection is assumed to use unrestricted 8-bit data
for the life of the connection. If the first valid header
assumed 4/8 packing then the resulting connection is assumed to
use 4/8 packing for the life of the connection. In the case of
the detection of illegal condition in the LISTEN state the
protocol will reply with a RST packet in kind.
事実上、2つの異なった受信アルゴリズムに受信データを入れます。有効なヘッダーの検出はもう片方の前にこれらのアルゴリズムの1つの心に浮かぶでしょう。 最初の有効なヘッダーが無制限な8ビットのデータを仮定しながら読まれたなら、どんな結果として起こる接続も無制限な8ビットのデータを接続の人生に使用すると思われます。 最初の有効なヘッダーが、4/8が荷造りしていると仮定したなら、結果として起こる接続が接続の人生で荷造りする4/8を使用すると思われます。 LISTEN状態での不法な状態の検出の場合では、プロトコルはRSTパケットで本質的に返答するでしょう。
Case 3: LISTEN Behavior for a Dumb Machine
ケース3: 馬鹿なマシンのための振舞いを聴いてください。
In this case machine B is the recipient of a connection request
and is capable of handling only 4/8 packed data. The LISTEN
behavior for machine B assumes that all connections are 4/8
packed. It never deals with unrestricted 8-bit data. As a
result it will refuse to open a connection request from a smart
machine (see case 4 below).
この場合、マシンBは、接続要求の受取人であり、4/8の詰まっているデータだけを扱うことができます。 マシンBが、すべての接続が4/8であると仮定するので、LISTENの振舞いは荷造りしました。 それは無制限な8ビットのデータに決して対処しません。 その結果、それは、スマートマシンからの接続要求を開くのを拒否するでしょう(以下のケース4を見てください)。
Case 4: SYN-SENT Behavior for a Smart Machine
ケース4: スマートマシンのためのSYNによって送られた振舞い
In this case machine A attempts to open a connection to machine
B. However, A has no knowledge of B's capabilities. A will
send its connection request assuming B is smart using
unrestricted 8-bit transmission. It will await a reply
assuming the response will be unrestricted 8-bit also. If B is
in fact dumb it will not return a SYN-ACK because of the
restriction imposed by case 3 above. If no connection is made
with B using 8-bit data the entire connection initiation is
restarted assuming B is dumb, 4/8 packing is used and the
response is assumed to be 4/8 packed as well.
Aには、この場合、マシンAは、B.Howeverを機械加工するために接続を開くのを試みて、ビーズ能力に関する知識が全くありません。 意志で、接続要求は、Bが無制限な8ビットのトランスミッションを使用することで賢いと仮定します。 それは無制限であると応答が8ビットでなる仮定する回答もお待ちするでしょう。 事実上、Bが馬鹿であるなら、それは上でケース3によって課された制限のためにSYN-ACKを返さないでしょう。 Bが8ビットのデータを使用している状態で接続が全く作られないなら、Bが馬鹿であると仮定しながら、全体の接続開始は再出発されて、また、使用されるパッキングと応答が4/8であると思われる4/8は荷造りしました。
Finn [Page 48]
フィンランド人[48ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
The cost of this approach is a longer time to determine whether
or not it is possible to open a connection to B. It is twice as
long. The advantages of being able to automatically adjust to
either unrestricted 8-bit or 4/8 packed data out weigh this
disadvantage. RATP will not exhibit the schizophrenic behavior
of many other asynchronous protocols when dealing with both
classes of machines.
このアプローチの費用はB.Itに接続を開くのが2倍長いのが、可能であるかどうか決定するより長い時間です。 できるのが外で自動的に8ビットか4/8ビット無制限な詰まっているデータに適応する利点はこの不都合の重さがあります。 両方のクラスのマシンに対処するとき、RATPは他の多くの非同期なプロトコルの精神分裂病患者の振舞いを示さないでしょう。
Finn [Page 49]
フィンランド人[49ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
II. A Brief Survey of Some Asynchronous Link Protocols
II。 いくつかの非同期なリンク・プロトコルの概略調査
II.1. DDCMP
II.1。 DDCMP
DDCMP, Copyright (c) 1978 Digital Equipment Corporation [DDCMP
78], is a reliable point-to-point and multi-point transmission
protocol is used by many of that manufacturer's computers. DDCMP
does provide reliable asynchronous two way data transmission.
DDCMP(Copyright(c)1978DEC[DDCMP78])は信頼できるポイントツーポイントです、そして、マルチポイントトランスミッションプロトコルはそのメーカーのコンピュータの多くによって使用されます。 DDCMPは信頼できる非同期なツーウェイデータ伝送を提供します。
Some of the decisions taken in the design of DDCMP reflect its
orientation toward multi-point data links. This leads to headers
which are substantially longer than needed for two way
point-to-point communications.
DDCMPのデザインで取られた決定のいくつかがマルチポイントデータ・リンクに向かってオリエンテーションを反映します。 これはヘッダーに通じます(ツーウェイポイントツーポイントコミュニケーションに必要とされるより実質的に長いです)。
DDCMP allows as many as 255 outstanding unacknowledged messages.
DDCMP does specifically mention that a particular end of a
connection may choose to limit the send queue to one outstanding
unacknowledged message. It also allows sending a stream of
outstanding unacknowledged packets. Unless all RS-232
implementations of DDCMP were limited to a single outstanding
packet, the collision with existing flow control restrictions
could lead to very low thruput. (DDCMP is assumed to have control
over the link driver. Dealing with various differing flow control
mechanisms is not a consideration.)
DDCMPは最大255の傑出している不承認のメッセージを許容します。 DDCMPは、接続の特定の終わりが、送信キューを1つの傑出している不承認のメッセージに制限するのを選ぶかもしれないと明確に言及します。 また、それで、傑出している不承認のパケットの流れを送ります。 DDCMPのすべてのRS-232実現が単一の傑出しているパケットに制限されるというわけではないなら、既存のフロー制御制限との衝突は非常に低いスループットにつながるかもしれないでしょうに。 DDCMPがリンクドライバーを管理すると思われます。(様々な異なったフロー制御メカニズムに対処するのは、考慮ではありません。)
DDCMP uses a CRC polynomial for data protection which is difficult
to calculate for many machines without special hardware [TCP
Checksum 78]. Many Digital Equipment computers have such
hardware.
DDCMPは特別なハードウェア[TCP Checksum78]なしで多くのマシンを予測するのが難しいデータ保護にCRC多項式を使用します。 多くのデジタル・イクイップメントコンピュータには、そのようなハードウェアがあります。
DDCMP does not provide the receiver with the ability to restrict
incoming packet size. It is true that all the higher level
protocols built on top of DDCMP could separately negotiate packet
size. But this burden would then be moved away from the link
level where it properly resides.
DDCMPは入って来るパケットサイズを制限する能力を受信機に提供しません。 DDCMPの上で築き上げられたすべての、より高い平らなプロトコルが別々にパケットサイズを交渉するかもしれないのは、本当です。 しかし、そして、この負担はリンク・レベルから遠くにそれが適切に住んでいるところに動かされるでしょう。
Generally, a full implementation of DDCMP is too complex for
consideration. If one were to implement 'part' of the protocol
then issues of compatibility with already existing implementations
on other computers are raised.
一般に、考慮には、DDCMPの完全な実施は複雑過ぎます。 1つがプロトコルの'部分'を実装するつもりであったなら、他のコンピュータの上の既に既存の実装との互換性の問題は高くしています。
Finn [Page 50]
フィンランド人[50ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
II.2. MODEM Protocol
II.2。 モデムプロトコル
This is a protocol in common use amongst microcomputers. The
description here comes from
これはマイクロコンピュータの中で共用のプロトコルです。 ここでの記述は来ます。
MODEM/XMODEM Protocol Explained by Kelly Smith, CP/M-Net
"SYSOP" January 8,1980
ケリー・スミスによって説明されたモデム/XMODEMプロトコル、M CP/ネット"SYSOP"1980年1月8日
.... Data is sent in 128-byte sequentially numbered blocks,
with a single checksum byte appended to the end of each block.
As the receiving computer acquires the incoming data, it
performs its own checksum and upon each completion of a block,
it compares its checksum result with that of the sending
computers. If the receiving computer matches the checksum of
the sending computer, it transmits an ACK (ASCII code protocol
character for ACKNOWLEDGE (06 Hex, Control-F)) back to the
sending computer. The ACK therefore means "all's well on this
end, send some more...".
.... 128バイトの連続して付番されたブロックでそれぞれのブロックの端まで1チェックサムバイトを追加している状態でデータを送ります。 受信側のコンピュータが受信データを取得するとき、それ自身のチェックサムを実行します、そして、1ブロックの各完成のときに、送付コンピュータのものとチェックサム結果を比べます。 受信側のコンピュータが送付コンピュータのチェックサムに合っているなら、それはACK(ACKNOWLEDGE(06Hex、Control-F)のためのASCIIコードプロトコルキャラクタ)を送付コンピュータに伝えて戻します。 したがって、ACKは、「すべてがよくこの終わりにあって、それ以上で発信してください」と意味します…
The sending computer will transmit an "initial NAK" (ASCII
protocol character for NEGATIVE ACKNOWLEDGE (15 Hex,
Control-U))...or, "that wasn't quite right, please send again".
Due to the asynchronous nature of the initial "hook-up" between
the two computers, the receiving computer will "time-out"
looking for data, and send the NAK as the "cue" for the sending
computer to begin transmission. The sending computer knows
that the receiving computer will "time-out", and uses this fact
to "get in sync"... The sending computer responds to the
"initial NAK" with a SOH (ASCII code protocol character for
START OF HEADING (01 Hex, Control-A)), sends the first block
number, sends the 1's complement of the block number, sends 128
bytes of 8 bit data, and finally a checksum, where the checksum
is calculated by summing the SOH, the block number, the block
number 1's complement, and the 128 bytes of data.
送付コンピュータは「初期のNAK」(NEGATIVE ACKNOWLEDGE(15Hex、Control-U)のためのASCIIプロトコルキャラクタ)を伝えるでしょう…または、「それは全く正しかったというわけではなく、もう一度発信してください。」 2台のコンピュータの間の初期の「接続」の非同期的性質のため、「タイムアウト」がデータを探して、受信側のコンピュータは送るでしょう、そして、「手がかり」としてNAKを送って、送付コンピュータはトランスミッションを始めてください。 送付コンピュータは、受信側のコンピュータが「同時性に入ること」に「タイムアウト」を望んでいて、この事実を使用するのを知っています… 送付コンピュータは(というASCIIコードが、(01Hex、Control-a))が最初の街区番号を送るSTART OF HEADINGのためにキャラクタについて議定書の中で述べて、街区番号の1の補数を送って、8ビットの128バイトのデータ、および最終的にチェックサムを送ります、チェックサムがSOHをまとめることによって計算されるところで、街区番号、街区番号1SOH補数、および128バイトのデータで「初期のNAK」に反応します。
Receiving Computer:
受信側のコンピュータ:
---/NAK/------------------------/ACK/------------------
15H 06H
---/NAK/------------------------/ACK/------------------ 15H 06H
Sending Computer:
コンピュータを送ります:
---/SOH/BLK#/BLK#/DATA/CSUM/---/SOH/BLK#/BLK#/DATA/etc.
01H 01H FEH 8bit 8bit 01H 02H FDH 8bit ....
---/SOH/BLK#/BLK#/DATA/CSUM/---/SOH/BLK#/BLK#/DATA/etc. 01H 01H FEH8の8ビットの噛み付いている01H 02H FDH8は噛み付きました…
Finn [Page 51]
フィンランド人[51ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
This process continues, with the next 128 bytes. If the block
was ACK'ed by the receiving computer, and then the next
sequential block number and its 1's complement, etc. ....
このプロセスは次の128バイトで持続します。 ブロックが受信側のコンピュータによるACK'edと、次に、次の連続した街区番号とその1の補数であったなら、などです。 ....
As can be seen from this partial description the MODEM protocol is
unidirectional, data can only pass from the sender to the receiver
in a stream. In order for data to flow simultaneously in the
other direction another connection over another RS-232 line would
be required.
MODEMプロトコルが見ることができるようにこの部分的な記述からの、単方向である、データは送付者から受信機まで絶え間なく終わることができるだけです。 データが同時にもう片方の方向に流れるように、別のRS-232系列の上の別の関係が必要でしょう。
In addition this protocol is restricted to a fixed 128 octet
packet size. Many front-end concentrators are unable to service
such large incoming packets. It has been observed many times that
the concentrator of a busy DECsystem-20 can invoke flow control on
input at 1200 baud for packets as small as 64 characters.
さらに、このプロトコルは固定128八重奏パケットサイズに制限されます。 多くのフロントエンド集中装置はそのような大きい入って来るパケットを調整できません。 何回も忙しいDECsystem-20の集中装置が入力のときにパケットのために1200年のボーに64のキャラクタと同じくらい小さくフロー制御を呼び出すことができるのが観測されました。
II.3. KERMIT System
II.3。 カーミットシステム
The KERMIT system, Copyright (c) 1981 Columbia University, is a
file transfer environment developed recently. It has
implementations which run on DECsystem-20, IBM 370 VM/CMS, 8080
CP/M based systems, and the IBM PC among others.
カーミットシステム(Copyright(c)1981コロンビア大学)は最近開発されたファイル転送環境です。 それはIBMのDECsystem-20の上で作業する実装、370VM/CMS、8080台のCP/Mのベースのシステム、および特にIBM PCを持っています。
KERMIT combines both the reliable transfer and file transfer into
a single package. Extension to other applications and higher
level protocols would be possible but the boundary between the
reliable transfer and application layers is very indistinct. It
violates the layering design strategy the Internet employs.
カーミットは信頼できる転送とファイル転送の両方をただ一つのパッケージの中に結合します。 他のアプリケーションと、より高い平らなプロトコルへの拡大は可能でしょうが、信頼できる転送と応用層の間の境界は非常に不明瞭です。 それはインターネットが使うレイヤリングデザイン戦略に違反します。
There is a limitation of transmission to the restricted printable
ASCII set for certain computers but not for others. This leads to
confusion. KERMIT allows both restricted ASCII and 8-bit
transmission.
あるコンピュータに設定された制限された印刷可能なASCIIへのトランスミッションの制限がありますが、他のもののためにあるというわけではありません。 これは混乱に通じます。 カーミットは制限されたASCIIと8ビットのトランスミッションの両方を許します。
The KERMIT protocol does have a method of setting MDL at
connection initiation. It is limited to a smaller maximum packet
size, 96 as opposed to 261 octets. Kermit originally used a
checksumming algorithm limited to six bits. This is considered to
provide too low a level of error detection capability for data
packets. Kermit now allows two other checksumming algorithms in
addition to the original. There must be a negotiation between
sender and receiver regarding which algorithm to use.
カーミットプロトコルには、接続開始にMDLを設定するメソッドがあります。 それは、より小さい最大のパケットサイズ、261の八重奏と対照的に96に制限されます。 カーミットは元々、6ビットに制限されたchecksummingアルゴリズムを使用しました。 これが低過ぎるレベルの誤り検出能力をデータ・パケットに提供すると考えられます。 カーミットは現在、オリジナルに加えて他の2checksummingにアルゴリズムを許します。 どのアルゴリズムを使用したらよいかに関して送付者と受信機との交渉があるに違いありません。
The KERMIT protocol does not appear to make provision for both
sides of a connection attempting an active open simultaneously.
One side must be an initial "sending Kermit" and the other a
"receiving Kermit". The code published as a KERMIT implementation
カーミットプロトコルは同時にアクティブな戸外を試みる接続の両側に備えるように見えません。 半面は、初期の「送付カーミット」ともう片方の「受信カーミット」であるに違いありません。 カーミット実装として発表されたコード
Finn [Page 52]
フィンランド人[52ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
guide cannot recover from simultaneous active opens, it
immediately ABORTs. This reflects a bias towards unidirectional
data flow.
ガイドは同時であるのから回復できません。能動態が開く、それ、すぐに、ABORTs。 これは単方向のデータフローに向かって偏見を反映します。
The KERMIT packet type (similar to RATP control flags) specifies
whether an ACK/NAK is contained in the packet, or data, etc.
These are mutually exclusive and piggybacking an ACK on a data
packet is not possible. This can be a source of overhead. In
addition KERMIT restricts the sender to a single outstanding
unacknowledged packet as does RATP. It allocates an entire byte
to the sequence number which is unnecessary.
カーミットパケットタイプ(RATP指揮旗と同様の)は、ACK/NAKがパケット、またはデータなどに含まれているかどうか指定します。 これらは互いに排他的です、そして、データ・パケットの上でACKを背負うのは可能ではありません。 これはオーバーヘッドの源であるかもしれません。 さらに、カーミットはRATPのように送付者を単一の傑出している不承認のパケットに制限します。 それは全体のバイトを不要な一連番号に割り当てます。
On the subject of error recovery, the size of a packet is
contained in the second byte of the packet and is not protected by
a header checksum. If the length field was in error due to noise
on the link, it could be longer than the correct packet size. The
code published as the KERMIT implementation guide relies upon the
detection of the <SOH> character anywhere in a packet to indicate
the beginning of a packet header. It re-SYNCHs using this
technique. This is only possible if binary data in a packet is
quoted. If full eight bit data is transmitted it does not appear
that the KERMIT protocol rescans for a new MARK (SYNCH) character
within the bad packet data just consumed. It will under these
circumstances throw away the retransmitted packet or portions
thereof. Re-SYNCHing under such conditions is problematical.
エラー回復に関して、パケットのサイズは、パケットの2番目のバイトに含まれていて、ヘッダーチェックサムによって保護されません。 長さの分野が雑音のためにリンクで間違っているなら、適度のパケットサイズより長いかもしれないでしょうに。 カーミット実装ガイドがパケットのヘッダーの始まりを示すためにパケットでどこでも<SOH>キャラクタの検出を当てにするように発表されたコード。 それ、これを使用する再SYNCHsテクニック。 パケットのバイナリ・データが引用される場合にだけ、これは可能です。 完全な8つのビット・データが伝えられるなら、カーミットプロトコルが新しいマーク(SYNCH)キャラクタのためにただ消費された悪いパケットデータの中で再スキャンされるように見えません。 それはこういう事情ですからそれの再送されたパケットか部分を無駄にするでしょう。 そのような状態の再SYNCHingは問題が多いです。
Finn [Page 53]
フィンランド人[53ページ]
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol
RFC916の1984年10月の信頼できる非同期な転送プロトコル
REFERENCES
参照
[Cohen 81]
[コーエン81]
Cohen, D. On Holy Wars and a Plea for Peace. IEEE Computer,
October, 1981.
コーエン、聖戦でのD.、および平和のための請願。 1981年10月のIEEEコンピュータ。
[DDCMP 78]
[DDCMP78]
DDCMP AA-D599A-TC edition, Digital Equipment Corporation, 1978.
Version 4.0.
DDCMP AA-D599A-TC版、DEC、1978。 バージョン4.0。
[IP 81]
[IP81]
Postel, J. DOD Standard Internet Protocol [RFC-791] Defense
Advanced Research Projects Agency, 1981.
ポステル、J.のDODの標準のインターネットプロトコル[RFC-791]ディフェンス先端研究は政府機関、1981を映し出します。
[TCP 81]
[TCP81]
Postel, J. Transmission Control Protocol [RFC-793] Defense
Advanced Research Projects Agency, 1981.
ポステル、J.通信制御プロトコル[RFC-793]ディフェンス先端研究は政府機関、1981を映し出します。
[TCP Checksum 78]
[TCPチェックサム78]
Plummer, W. W. TCP Checksum Function Design. Technical Report,
Bolt Beranek and Newman, Inc., 1978.
プラマー、W.W.TCPチェックサム機能デザイン。 技術報告書とボルトBeranekとニューマンInc.、1978
EDITORS NOTES
エディタ注意
This memo was prepared in essentially this form in June 1983, and set aside. Distribution at this time is prompted by the the "Thinwire" proposal described in RFC-914.
このメモは、1983年6月に本質的にはこのフォームで準備されて、かたわらに置かれました。 今回の分配はRFC-914で説明された"Thinwire"提案でうながされます。
--jon postel
--jon postel
Finn [Page 54]
フィンランド人[54ページ]
一覧
スポンサーリンク
