RFC1151 日本語訳

Network Working Group                                      C. Partridge
Request for Comments: 1151                 BBN Systems and Technologies
Updates: RFC 908                                              R. Hinden
                                               BBN Communications Corp.
                                                             April 1990

コメントを求めるワーキンググループC.ヤマウズラ要求をネットワークでつないでください: 1151のBBNシステムと技術アップデート: RFC908R.Hinden BBNコミュニケーション社の1990年4月

             Version 2 of the Reliable Data Protocol (RDP)

確実な資料プロトコルのバージョン2(RDP)

Status of this Memo

このMemoの状態

   This RFC suggests several updates to the specification of the
   Reliable Data Protocol (RDP) in RFC-908 based on experience with the
   protocol.  This revised version of the protocol is experimental.

このRFCはプロトコルの経験に基づくRFC-908のReliable Dataプロトコル(RDP)の仕様にいくつかのアップデートを勧めます。 プロトコルのこの改訂版は実験しています。

   Distribution of this memo is unlimited.

このメモの分配は無制限です。

Introduction

序論

   Experiments in 1986 and 1987 turned up some ambiguities and problems
   with the RDP specification.  At the time, it was hoped that the
   authors might find the time to revise the entire RDP specification to
   fix these problems, however given the limited demand for RDP
   implementations, the authors were never able to justify the time
   involved in revising the spec.  This document lists the changes that
   we believe are appropriate to make to RDP version 1.

1986年と1987年の実験はRDP仕様に関するいくつかのあいまいさと問題を捜しあてました。 当時、作者がこれらの問題を修正するために全体のRDP仕様を改訂する時間を見つけることが望まれていました、RDP実現を求めるわずかの需要を考えて、作者がどうしたら仕様を改訂するのにかかわる時間を決して正当化できないでも。 このドキュメントはRDPバージョン1に作るのが適切である私たちが、信じている変化を記載します。

   Readers are expected to be familiar with RFC-908.

読者がRFC-908によく知られさせると予想されます。

Changes To The Protocol Header

プロトコルヘッダーへの変化

   There are three changes to the protocol header: the checksum
   algorithm has been changed, the port size increased, and the version
   number incremented.  The new header format is shown in Figure 1.

プロトコルヘッダーへの3回の変化があります: チェックサムアルゴリズムは、変えてサイズが増加させたポートと、数が増加したバージョンです。 新しいヘッダー形式は図1に示されます。

   The major discovery during the testing of the protocol is that cost
   of computing the the RDP checksum proved surprisingly variable; its
   performance was more heavily affected by the host's data
   representation than anticipated.  Optimized checksum implementations
   on two comparable hardware bases gave performance that differed by a
   factor of five.  Since the speed of the checksum is a key factor in
   the performance of the protocol itself, this variation caused a
   noticeable difference in throughput.

プロトコルのテストの間の主要な発見はRDPチェックサムを計算する費用が驚くほど可変であると判明したということです。 性能はホストのデータ表現で予期されるよりずっしりと影響を受けました。 2個の匹敵するハードウェアベースにおける最適化されたチェックサム実現は5の要素で異なった性能を与えました。 以来チェックサムの速度がプロトコル自体の性能において主要因である、この変化はスループットのそれと分かる差異を引き起こしました。

   The wide variation in performance on comparable machines was felt to
   be undesirable, so the checksum has been changed.  RDP now uses the
   16-bit TCP checksum, which is specified on page 16 of RFC-793.

匹敵するマシンに関する性能の広い変化が望ましくないと感じられたので、チェックサムを変えました。 RDPは現在、16ビットのTCPチェックサムを使用します。(それは、16RFC-793ページで指定されます)。

Partridge & Hinden                                              [Page 1]

RFC 1151                    RDP - Version 2                   April 1990

ヤマウズラとHinden[1ページ]RFC1151RDP--バージョン1990年4月2日

   The 8-bit port size is probably too small to support a large range of
   applications.  Accordingly, the port size is now 16-bits.  Port
   numbers less than 1024 are reserved for well-defined applications.
   Allocable ports begin at port number 1024.

8ビットのポートサイズはたぶん広範囲なアプリケーションを支持できないくらい小さいです。 それに従って、現在、ポートサイズは16ビットです。 1024が明確なアプリケーションのために予約されるほど数を移植しないでください。 AllocableポートはポートNo.1024で始まります。

   Finally, because the checksum and port size have been changed, the
   version number has been increased to 2.

最終的に、バージョン番号は、チェックサムとポートサイズを変えたので、2まで増加しました。

                   0             0 0   1         1
                   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                  +-+-+-+-+-+-+---+---------------+
                  |S|A|E|R|N| |Ver|    Header     |
                0 |Y|C|A|S|U|0|No.|    Length     |
                  |N|K|K|T|L| |   |               |
                  +-+-+-+-+-+-+---+---------------+
                1 |         Source Port           |
                  +---------------+---------------+
                2 |       Destination Port        |
                  +---------------+---------------+
                3 |          Data  Length         |
                  +---------------+---------------+
                4 |                               |
                  +---    Sequence Number      ---+
                5 |                               |
                  +---------------+---------------+
                6 |                               |
                  +--- Acknowledgement Number  ---+
                7 |                               |
                  +---------------+---------------+
                8 |           Checksum            |
                  +---------------+---------------+
                9 |     Variable Header Area      |
                  .                               .
                  .                               .
                  |                               |
                  +---------------+---------------+

0 0 0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+---+---------------+ |S|A|E|R|N| |Ver| ヘッダー| 0 |Y|C|A|S|U|0|いいえ| 長さ| |N|K|K|T|L| | | | +-+-+-+-+-+-+---+---------------+ 1 | ソース港| +---------------+---------------+ 2 | 仕向港| +---------------+---------------+ 3 | データの長さ| +---------------+---------------+ 4 | | +--- 一連番号---+ 5 | | +---------------+---------------+ 6 | | +--- 承認番号---+ 7 | | +---------------+---------------+ 8 | チェックサム| +---------------+---------------+ 9 | 可変ヘッダー領域| . . . . | | +---------------+---------------+

                         RDP Header Format
                             Figure 1

RDPヘッダー形式数値1

Minor Errors and Ambiguities

軽い過失とあいまいさ

   Some ambiguities and minor errors have been found in RFC-908.  They
   are corrected in this section.

いくつかのあいまいさと軽い過失はRFC-908で見つけられました。 それらはこのセクションで修正されます。

   The value of the state variable, SND.UNA is treated inconsistently in
   the pseudo-code on pages 21-29.  On page 12, SND.UNA is defined as

州の変数の値であり、SND.UNAは21-29ページで中間コードで相反して扱われます。 12ページでは、SND.UNAは定義されます。

Partridge & Hinden                                              [Page 2]

RFC 1151                    RDP - Version 2                   April 1990

ヤマウズラとHinden[2ページ]RFC1151RDP--バージョン1990年4月2日

   "the sequence number of the oldest unacknowledged segment", and on
   page 21 it is appropriately set to the initial sequence number when
   the connection is opened.  But on page 28, when an acknowledgement is
   received, SND.UNA is set to SEG.ACK, the sequence number being
   acknowledged, instead of SEG.ACK+1.  A similar inconsistency occurs
   on page 26.  The proper fix is to always set SND.UNA to SEG.ACK+1.

「最も古い不承認のセグメントの一連番号、」 接続が開かれるとき、21ページでは、それは適切に初期シーケンス番号に設定されます。 しかし、承認が受け取られているとき、28ページでは、SND.UNAはSEG.ACKに用意ができています、一連番号が承認されて、SEG.ACK+1の代わりに。 同様の矛盾は26ページに起こります。 適切なフィックスはいつもSEG.ACK+1にSND.UNAを設定することです。

   The pseudo-code on page 25 for the SYN-SENT state is incorrect.  The
   first few lines cause all packets with the ACK bit set to be
   discarded, but later lines test the ACK bit.  The test for the ACK
   bit should be placed after all the other tests.  Also note that if
   the ACK bit is set, a RST segment is sent to reset the remote peer,
   but the local peer is left half-open.  There is a similar problem in
   the SYN-RCVD state.  The local peer should deallocate the connection
   record and close.

SYN-SENT状態への25ページの中間コードは不正確です。 わずかな最初の線が捨てられるように設定されたACKビットですべてのパケットを引き起こしますが、後の線はACKビットをテストします。 ACKビットのための他のすべてのテストが次々と置かれるべきです。 また、ACKビットを設定するなら、リモート同輩をリセットするためにRSTセグメントを送りますが、地元の同輩を半開きなままにすることに注意してください。 同様の問題がSYN-RCVD状態にあります。 地元の同輩は接続が記録して、閉じるdeallocateがそうするべきです。

   On page 24, the pseudo-code indicates that if non-data packets are
   received in the CLOSED state, a RST segment with SEG.ACK set to
   RCV.CUR should be sent.  RCV.CUR is not defined in the CLOSED state.
   SEG.ACK should be set to SEG.SEG.

24ページでは、中間コードは、CLOSED状態に非データ・パケットを受け取るなら、RCV.CURに用意ができているSEG.ACKがあるRSTセグメントを送るべきであるのを示します。 RCV.CURはCLOSED状態で定義されません。 SEG.ACKはSEG.SEGに用意ができるべきです。

   There is some inconsistency about how to handle a RST packet in the
   CLOSE-WAIT state.  On page 24, the pseudo-code shows that a RST
   should cause the connection state to become CLOSED.  Text on page 13
   and the state diagram on page 10 suggest the connection state should
   stay in CLOSE-WAIT.  The implementation should stay in CLOSE-WAIT.

CLOSE-WAIT状態でどうRSTパケットを扱うかに関して何らかの矛盾があります。 24ページでは、中間コードは、接続状態がRSTによってCLOSEDになるべきであるのを示します。 13ページのテキストと10ページの州のダイヤグラムは、接続状態がCLOSE-WAITに残るべきであると示唆します。 実現はCLOSE-WAITに残るべきです。

   On page 29, the pseudo-code for the OPEN state suggests that if a
   data packet is received in sequence, the acknowledgement packet
   should not contain EACKs.  This is misleading.  Implementations may
   include EACKs in the acknowledgement.

29ページでは、オープン状態への中間コードは、連続してデータ・パケットを受け取るなら、確認応答パケットがEACKsを含むはずがないと示唆します。 これは紛らわしいです。 実現は承認にEACKsを含むかもしれません。

   On page 18, it is possible to interpret the right edge as being
   either inside or outside the window.  This results in a one segment
   difference in the window size.  The proper interpretation is that the
   right edge is outside the window.  In other words, the right edge is
   the first sequence number that cannot be sent or received and the
   total window size is 2*X, where X is the maximum number of
   outstanding segments.

18ページでは、窓の中、または、窓の外にあると正しい縁を解釈するのは可能です。 これはウィンドウサイズの1つのセグメント差をもたらします。 適切な解釈は窓の外に正しい縁があるということです。 言い換えれば、正しい縁は送ることができないか、受け取ることができない最初の一連番号です、そして、総ウィンドウサイズは2*Xです。(そこでは、Xが傑出しているセグメントの最大数です)。

   One final problem is that RDP's flow control scheme does not allow
   the receiver to close the sender's window.  As a result, if the
   receiver acknowledges segments when they are received the sender can
   easily send more data than the receiver is prepared to buffer.  A
   solution to this problem (suggested by members of the End-2-End
   Research Group) is to only acknowledge a segment after it has been
   delivered to the application.  This scheme, however, has not be
   tested.

1つの最終的な問題は受信機がRDPのフロー制御計画で送付者の窓を閉じることができないということです。 その結果、それらが受け取られているとき、受信機がセグメントを承認するなら、送付者は容易に受信機がバッファリングするように準備されるより多くのデータを送ることができます。 この問題(End2が終わっているResearch Groupのメンバーによって提案される)の解決はそれをアプリケーションに届けた後にセグメントを承認するだけであることです。 しかしながら、この計画はテストされていません。

Partridge & Hinden                                              [Page 3]

RFC 1151                    RDP - Version 2                   April 1990

ヤマウズラとHinden[3ページ]RFC1151RDP--バージョン1990年4月2日

Security Considerations

セキュリティ問題

   Security issues are not addressed in this memo.

安全保障問題はこのメモに記述されません。

Authors' Addresses

作者のアドレス

   Craig Partridge
   Bolt Beranek and Newman Inc.
   50 Moulton Street
   Cambridge, MA 02138

モールトン・通りケンブリッジ、クレイグヤマウズラボルトBeranekとニューマン株式会社50MA 02138

   Phone: (617) 873-2459

以下に電話をしてください。 (617) 873-2459

   EMail: craig@BBN.COM

メール: craig@BBN.COM

   Robert Hinden
   Bolt Beranek and Newman Inc.
   50 Moulton Street
   Cambridge, MA 02238

モールトン・通りケンブリッジ、ロバートHindenボルトBeranekとニューマン株式会社50MA 02238

   Phone: (617) 873-3757

以下に電話をしてください。 (617) 873-3757

   Email: HINDEN@BBN.COM

メール: HINDEN@BBN.COM

Partridge & Hinden                                              [Page 4]

ヤマウズラとHinden[4ページ]