RFC908 日本語訳
0908 Reliable Data Protocol. D. Velten, R.M. Hinden, J. Sax. July 1984. (Format: TXT=97646 bytes) (Updated by RFC1151) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Reliable Data Protocol
確実な資料プロトコル
RFC-908
RFC-908
David Velten
デヴィッド・フェルテン
Robert Hinden
ロバートHinden
Jack Sax
ジャックSax
BBN Communications Corporation
BBNコミュニケーション社
July 1984
1984年7月
Status of This Memo
このメモの状態
This RFC specifies a proposed protocol for the ARPA Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このRFCはARPAインターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを改良に指定します。 このメモの分配は無制限です。
RDP Specification
RDP仕様
Table of Contents
目次
1 Introduction.......................................... 1
1つの序論… 1
2 General Description................................... 3
2.1 Motivation.......................................... 3
2.2 Relation to Other Protocols......................... 5
2 一般記述… 3 2.1動機… 3 他のプロトコルとの2.2関係… 5
3 Protocol Operation.................................... 7
3.1 Protocol Service Objectives......................... 7
3.2 RDP Connection Management........................... 7
3.2.1 Opening a Connection.............................. 8
3.2.2 Ports............................................. 8
3.2.3 Connection States................................. 8
3.2.4 Connection Record................................ 11
3.2.5 Closing a Connection............................. 13
3.2.6 Detecting an Half-Open Connection................ 14
3.3 Data Communication................................. 14
3.4 Reliable Communication............................. 15
3.4.1 Segment Sequence Numbers......................... 15
3.4.2 Checksums........................................ 16
3.4.3 Positive Acknowledgement of Segments............. 16
3.4.4 Retransmission Timeout........................... 17
3.5 Flow Control and Window Management................. 17
3.6 User Interface..................................... 19
3.7 Event Processing................................... 20
3.7.1 User Request Events.............................. 21
3.7.2 Segment Arrival Events........................... 24
3.7.3 Timeout Events................................... 29
3 操作について議定書の中で述べてください… 7 3.1 サービス目的について議定書の中で述べてください… 7 3.2 RDP接続管理… 7 3.2 .1 接続を開きます… 8 3.2 .2 移植します。 8 3.2 .3 接続州… 8 3.2 .4接続記録… 11 3.2 .5 接続を終えます… 13 3.2 .6 半開きな接続を検出します… 14 3.3データ通信… 14 3.4 信頼できるコミュニケーション… 15 3.4 .1 セグメント一連番号… 15 3.4 .2のチェックサム… 16 3.4 .3 セグメントの積極的な承認… 16 3.4 .4 Retransmissionタイムアウト… 17 3.5フロー制御とウィンドウ管理… 17 3.6ユーザーインタフェース… 19 3.7 イベント処理… 20 3.7 .1 ユーザ要求イベント… 21 3.7 .2 セグメント到着イベント… 24 3.7 .3 タイムアウトイベント… 29
4 RDP Segments and Formats............................. 31
4.1 IP Header Format................................... 31
4.2 RDP Header Format.................................. 32
4.2.1 RDP Header Fields................................ 33
4.3 SYN Segment........................................ 36
4.3.1 SYN Segment Format............................... 36
4.3.2 SYN Segment Fields............................... 37
4.4 ACK Segment........................................ 38
4.4.1 ACK Segment Format............................... 38
4.4.2 ACK Segment Fields............................... 39
4.5 Extended ACK Segment............................... 40
4.5.1 EACK Segment Format.............................. 40
4.5.2 EACK Segment Fields.............................. 40
4 RDPセグメントと形式… 31 4.1 IPヘッダー形式… 31 4.2 RDPヘッダー形式… 32 4.2 .1 RDPヘッダーフィールド… 33 4.3SYNセグメント… 36 4.3 .1 SYNセグメント形式… 36 4.3 .2 SYNセグメント分野… 37 4.4ACKセグメント… 38 4.4 .1 ACKセグメント形式… 38 4.4 .2 ACKセグメント分野… 39 4.5の拡張ACKセグメント… 40 4.5 .1 EACKセグメント形式… 40 4.5 .2 EACKセグメント分野… 40
Page i
ページi
RFC-908 July 1984
RFC-908 1984年7月
4.6 RST Segment........................................ 42
4.6.1 RST Segment Format............................... 42
4.7 NUL Segment........................................ 43
4.7.1 NUL segment format............................... 43
4.6RSTセグメント… 42 4.6 .1 RSTセグメント形式… 42 4.7NULセグメント… 43 4.7 .1 NULセグメント形式… 43
5 Examples of Operation................................ 45
5.1 Connection Establishment........................... 45
5.2 Simultaneous Connection Establishment.............. 46
5.3 Lost Segments...................................... 47
5.4 Segments Received Out of Order..................... 48
5.5 Communication Over Long Delay Path................. 49
5.6 Communication Over Long Delay Path With Lost
Segments
.................................................... 50
5.7 Detecting a Half-Open Connection on Crash
Recovery
.................................................... 51
5.8 Detecting a Half-Open Connection from the
Active Side
.................................................... 52
操作に関する5つの例… 45 5.1 接続設立… 45 5.2 同時接続設立… 46 5.3 セグメントを失います… 47 5.4のセグメントが故障していた状態で受信されました… 48 長時間の遅延経路の上の5.5コミュニケーション… 49 無くなっているセグメントがある長時間の遅延経路の上の5.6コミュニケーション… 50 5.7 クラッシュリカバリに半開きな接続を検出します… 51 5.8 アクティブ側から半開きな接続を検出します… 52
A Implementing a Minimal RDP........................... 53
実装するa最小量のRDP… 53
Page ii
ページii
RDP Specification
RDP仕様
FIGURES
図
1 Relation to Other Protocols............................ 5
2 Form of Data Exchange Between Layers................... 6
3 RDP Connection State Diagram.......................... 10
4 Segment Format........................................ 31
5 RDP Header Format..................................... 32
6 SYN Segment Format.................................... 37
7 ACK Segment Format.................................... 38
8 EACK Segment Format................................... 41
9 RST Segment Format.................................... 42
10 NUL Segment Format................................... 43
他のプロトコルとの1つの関係… 層の間のデータ交換の5 2フォーム… 6 3RDP接続州のダイヤグラム… 10 4 セグメント形式… 31 5 RDPヘッダー形式… 32 6 SYNセグメント形式… 37 7 ACKセグメント形式… 38 8 EACKセグメント形式… 41 9 RSTセグメント形式… 42 10NULセグメント形式… 43
Page iii
ページiii
CHAPTER 1
第1章
Introduction
序論
The Reliable Data Protocol (RDP) is designed to provide a
reliable data transport service for packet-based applications
such as remote loading and debugging. The protocol is intended
to be simple to implement but still be efficient in environments
where there may be long transmission delays and loss or non-
sequential delivery of message segments.
Reliable Dataプロトコル(RDP)は、リモートローディングやデバッグなどのパケットベースの応用のための確実な資料輸送サービスを提供するように設計されています。 メッセージ・セグメントの長いトランスミッション遅れと損失か非連続した配送があるかもしれないところで環境でまだ効率的であるのを除いて、実装するのがプロトコルが簡単であることを意図します。
Although this protocol was designed with applications such
as remote loading and debugging in mind, it may be suitable for
other applications that require reliable message services, such
as computer mail, file transfer, transaction processing, etc.
このプロトコルはリモートローディングやデバッグなどの応用で念頭に設計されましたが、それは信頼できるメッセージサービスを必要とする他のアプリケーションに適するかもしれません、コンピュータメール、ファイル転送、トランザクション処理などのように
Some of the concepts used come from a variety of sources.
The authors wish credit to be given to Eric Rosen, Rob Gurwitz,
Jack Haverty, and to acknowledge material adapted from "RFC-793,
The Transmission Control Protocol", edited by Jon Postel. Thanks
to John Linn for the checksum algorithm.
使用される概念のいくつかがさまざまなソースから来ます。 作者は、クレジットがエリック・ローゼンに与えられていて欲しいです、ロブGurwitz、ジャックHaverty、そして、材料を承認するのがジョン・ポステルによって編集された「RFC-793、通信制御プロトコル」から適合しました。 チェックサムアルゴリズムをジョン・リンをありがとうございます。
Page 1
1ページ
RFC-908 July 1984
RFC-908 1984年7月
Page 2
2ページ
RDP Specification General Description
RDP仕様一般記述
CHAPTER 2
第2章
General Description
概説
2.1 Motivation
2.1 動機
RDP is a transport protocol designed to efficiently support
the bulk transfer of data for such host monitoring and control
applications as loading/dumping and remote debugging. It
attempts to provide only those services necessary, in order to be
efficient in operation and small in size. Before designing the
protocol, it was necessary to consider what minimum set of
transport functions would satisfy the requirements of the
intended applications.
RDPは嵩がロードするか、またはどさっと落とすようなホストモニターと制御アプリケーションのためのデータ転送とリモートデバッグであると効率的にサポートするように設計されたトランスポート・プロトコルです。 それは、稼働中であり効率的であって、サイズが小さくなるように必要な状態でそれらのサービスだけを提供するのを試みます。 プロトコルを設計する前に、何の最小のセットの輸送機能が意図しているアプリケーションの要件を満たすかを考えるのが必要でした。
The following is a list of requirements for such a transport
protocol:
↓これはそのようなトランスポート・プロトコルのための要件のリストです:
o Reliable delivery of packets is required. When loading
or dumping a memory image, it is necessary that all
memory segments be delivered. A 'hole' left in the
memory image is not acceptable. However, the internet
environment is a lossy one in which packets can get
damaged or lost. So a positive acknowledgement and
retransmission mechanism is a necessary component of the
protocol.
o 信頼できるパケットの配信が必要です。 メモリイメージをロードするか、またはどさっと落とすとき、すべてのメモリセグメントが提供されるのが必要です。 メモリイメージで残っている'穴'は許容できません。 しかしながら、インターネット環境は破損する場合があるか、またはパケットが失われる場合がある損失性1です。 それで、積極的な承認と「再-トランスミッション」メカニズムはプロトコルの必要な成分です。
o Since loading and dumping of memory images over the
internet involves the bulk transfer of large amounts of
data over a lossy network with potentially long delays,
it is necessary that the protocol move data efficiently.
In particular, unnecessary retransmission of segments
should be avoided. If a single segment has been lost but
succeeding segments correctly received, the protocol
should not require the retransmission of all of the
segments.
o プロトコルが効率的にデータを動かすのが以来インターネットの上でメモリイメージをロードして、どさっと落とすと多量のデータのバルク転送が損失性ネットワークの上で潜在的に長い遅れにかかわるのが必要です。 特に、セグメントの不要な「再-トランスミッション」は避けられるべきです。 ただ一つのセグメントが失われましたが、続くセグメントが正しく受信されるなら、プロトコルはセグメントのすべてを「再-トランスミッション」に要求しないでしょうに。
o Loading and dumping are applications that do not
necessarily require sequenced delivery of segments, as
long as all segments eventually are delivered. So the
protocol need not force sequenced delivery. For these
types of applications, segments may be delivered in the
order in which they arrive.
o ローディングとダンピングは必ずセグメントの配列された配送を必要とするというわけではないアプリケーションです、すべてのセグメントが結局提供される限り。 それで、プロトコルは配列された配送を強制する必要はありません。 これらのタイプのアプリケーションにおいて、セグメントはそれらが到達するオーダーで提供されるかもしれません。
Page 3
3ページ
RFC-908 July 1984
RFC-908 1984年7月
o However, some applications may need to know that a
particular piece of data has been delivered before
sending the next. For example, a debugger will want to
know that a command inserting a breakpoint into a host
memory image has been delivered before sending a
"proceed" command. If those segments arrived out of
sequence, the intended results would not be achieved.
The protocol should allow a user to optionally specify
that a connection must deliver segments in sequence-
number order.
o しかしながら、いくつかのアプリケーションが、次を送る前に特定のデータが提供されたのを知る必要があるかもしれません。 例えば、デバッガは、「続き」コマンドを送る前にホストメモリイメージに区切り点を挿入するコマンドが提供されたのを知りたくなるでしょう。 それらのセグメントが順序が狂って到着するなら、意図した結果は獲得されないでしょうに。 プロトコルで、ユーザは、接続が系列数のオーダーにおけるセグメントを提供しなければならないと任意に指定できるべきです。
o The loading/dumping and debugging applications are well-
defined and lend themselves to easy packetization of the
transferred data. They do not require a complex byte-
stream transfer mechanism.
o ローディング/ダンピングとアプリケーションをデバッグするのは、よく定義されて、わたっているデータの簡単なpacketizationに自分たちを与えます。 彼らは複雑なバイトストリームトランスファ・メカニズムを必要としません。
In order to combine the requirements for bulk transfers of
data and reliable delivery, it is necessary to design a
connection-oriented protocol using a three-way handshake to
synchronize sequence numbers. The protocol seems to be
approaching TCP in complexity, so why was TCP not, in fact,
chosen? The answer is that TCP has some disadvantages for these
applications. In particular:
データと信頼できる配信のバルク転送のための要件を結合するために、一連番号を同期させるのに3方向ハンドシェイクを使用する接続指向のプロトコルを設計するのが必要です。 プロトコルは複雑さでTCPにアプローチしているように思えて、非常に、TCPはなぜ事実上選ばれませんでしたか? 答えはTCPにはこれらのアプリケーションのためのいくつかの損失があるということです。 特に:
o TCP is oriented toward a more general environment,
supporting the transfer of a stream of bytes between two
communicating parties. TCP is best suited to an
environment where there is no obvious demarcation of data
in a communications exchange. Much of the difficulty in
developing a TCP implementation stems from the complexity
of supporting this general byte-stream transfer, and thus
a significant amount of complexity can be avoided by
using another protocol. This is not just an
implementation consideration, but also one of efficiency.
o 2の間のパーティーを伝えるバイトのストリームの転送をサポートして、TCPは、より一般的な環境に向かって適応します。 コミュニケーション交換における、データのどんな明白な画定もない環境にTCPを合わせるのは最も良いです。 TCP実装を開発することにおける、困難の多くがこの一般的なバイト・ストリームが転送であるとサポートする複雑さによります、そして、その結果、別のプロトコルを使用することによって、かなりの量の複雑さは避けることができます。 これは実装の考慮だけではなく、1でもあります。効率について。
o Since TCP does not allow a byte to be acknowledged until
all prior bytes have been acknowledged, it often forces
unnecessary retransmission of data. Therefore, it does
not meet another of the requirements stated above.
o すべての先のバイトが承認されるまでTCPが、1バイトが承認されるのを許容しないので、それはしばしば不要なデータの再伝送を強制します。 したがって、それは上に述べられた要件の別のものに会いません。
o TCP provides sequenced delivery of data to the
application. If the application does not require such
sequenced delivery, a large amount of resources are
wasted in providing it. For example, buffers may be tied
up buffering data until a segment with an earlier
sequence number arrives. The protocol should not force
its segment-sequencing desires on the application.
o TCPはデータの配列された配送をアプリケーションに提供します。 アプリケーションがそのような配列された配送を必要としないなら、多量のリソースがそれを提供する際に浪費されます。 例えば、バッファは、以前の一連番号があるセグメントが到着するまでデータをバッファリングしながら、タイアップされるかもしれません。 プロトコルはセグメントを配列する願望をアプリケーションに押しつけるべきではありません。
Page 4
4ページ
RDP Specification General Description
RDP仕様一般記述
RDP supports a much simpler set of functions than TCP. The
flow control, buffering, and connection management schemes of RDP
are considerably simpler and less complex. The goal is a
protocol that can be easily and efficiently implemented and that
will serve a range of applications.
RDPはTCPよりはるかに簡単な関数群を支えます。 RDPのフロー制御、バッファリング、および接続管理体系は、かなり簡単であって、それほど複雑ではありません。 目標は簡単に効率的に実装することができて、さまざまなアプリケーションに役立つプロトコルです。
RDP functions can also be subset to further reduce the size
of a particular implementation. For example, a target processor
requiring down-loading from another host might implement an RDP
module supporting only the passive Open function and a single
connection. The module might also choose not to implement out-
of-sequence acknowledgements.
また、RDP機能は特定の実装のサイズをさらに減少させる部分集合であるかもしれません。 例えば、別のホストからダウンロードするのを必要とする目標プロセッサはRDPモジュールが受け身のオープン機能だけをサポートして、単独結合であると実装するかもしれません。 また、モジュールは、系列の出ている承認を実装しないのを選ぶかもしれません。
2.2 Relation to Other Protocols
2.2 他のプロトコルとの関係
RDP is a transport protocol that fits into the layered
internet protocol environment. Figure 1 illustrates the place of
RDP in the protocol hierarchy:
RDPは層にされたインターネットプロトコル環境に収まるトランスポート・プロトコルです。 図1はプロトコル階層でRDPの場所を例証します:
+------+ +-----+ +-----+ +------+
|TELNET| | FTP | |Debug| ... |Loader| Application Layer
+------+ +-----+ +-----+ +------+
| | | |
+-----+----+ +------+------+
| |
+------+ +-------+
| TCP | | RDP | Transport Layer
+------+ +-------+
| |
+--------------------------------+
| Internet Protocol & ICMP | Internetwork Layer
+--------------------------------+
|
+-------------------------+
| Network Access Protocol | Network Layer
+-------------------------+
+------+ +-----+ +-----+ +------+ |telnet| | FTP| |デバッグ| ... |荷物を積む人| 応用層+------+ +-----+ +-----+ +------+ | | | | +-----+----+ +------+------+ | | +------+ +-------+ | TCP| | RDP| トランスポート層+------+ +-------+ | | +--------------------------------+ | インターネットプロトコルとICMP| インターネットワーク層+--------------------------------+ | +-------------------------+ | ネットワークアクセス・プロトコル| ネットワーク層+-------------------------+
Relation to Other Protocols
Figure 1
他のプロトコルとの関係は1について計算します。
Page 5
5ページ
RFC-908 July 1984
RFC-908 1984年7月
RDP provides the application layer with a reliable message
transport service. The interface between users and RDP transfers
data in units of messages. When implemented in the internet
environment, RDP is layered on the Internet Protocol (IP), which
provides an unreliable datagram service to RDP. Data is passed
across the RDP/IP interface in the form of segments. RDP uses
the standard IP interface primitives to send and receive RDP
segments as IP datagrams. At the internet level, IP exchanges
datagrams with the network layer. An internet packet may contain
an entire datagram or a fragment of a datagram.
RDPは信頼できるメッセージ輸送サービスを応用層に提供します。 ユーザとRDPとのインタフェースはユニットのメッセージのデータを移します。 インターネット環境で実装されると、RDPはインターネットプロトコル(IP)で層にされます。(それは、RDPへの頼り無いデータグラムサービスを提供します)。 データはセグメントの形でRDP/IPインタフェースの向こう側に通過されます。 RDPは、IPデータグラムとしてRDPセグメントを送って、受けるのに標準のIPインタフェース基関数を使用します。インターネットレベルでは、IPはネットワーク層とデータグラムを交換します。 インターネットパケットは全体のデータグラムかデータグラムの断片を含むかもしれません。
# %
? * !
@ )
+------+ +-----+ +----+ $ = ^ +
| |Messages | |Segments | | Datagrams *
| User |<------->| RDP |<------->| IP |<-------> Internet
| | | | | | , ?
+------+ +-----+ +----+ ! )
* % $
@ ^ !
# % ? * ! @ ) +------+ +-----+ +----+ $ = ^ + | |メッセージ| |セグメント| | データグラム*| ユーザ| <、-、-、-、-、-、--、>| RDP| <、-、-、-、-、-、--、>| IP| <、-、-、-、-、-、-->インターネット| | | | | | , ? +------+ +-----+ +----+ ! ) * % $ @ ^ !
Form of Data Exchange Between Layers
Figure 2
層の間のデータ交換のフォームは2について計算します。
If internetwork services are not required, it should be
possible to use the RDP without the IP layer. As long as the
encapsulating protocol provides the RDP with such necessary
information as addressing and protocol demultiplexing, it should
be possible to run RDP layered on a variety of different
protocols.
相互ネットワーク・サービスは必要でないなら、IP層なしでRDPを使用するのが可能であるべきです。 要約プロトコルがアドレシングとプロトコル逆多重化のような必要事項をRDPに提供する限り、さまざまな異なったプロトコルで層にされたRDPを実行するのは可能であるべきです。
Page 6
6ページ
RDP Specification Protocol Operation
RDP仕様プロトコル操作
CHAPTER 3
第3章
Protocol Operation
プロトコル操作
3.1 Protocol Service Objectives
3.1 プロトコルサービス目的
The RDP protocol has the following goals:
RDPプロトコルには、以下の目標があります:
o RDP will provide a full-duplex communications channel
between the two ports of each transport connection.
o RDPはそれぞれの輸送接続の2つのポートの間に全二重通信チャンネルを供給するでしょう。
o RDP will attempt to reliably deliver all user messages
and will report a failure to the user if it cannot
deliver a message. RDP extends the datagram service of
IP to include reliable delivery.
o RDPはすべてのユーザメッセージを確かに提供するのを試みて、伝言をもたらすことができないなら、失敗をユーザに報告するでしょう。 RDPは、信頼できる配信を含むようにIPのデータグラムサービスを広げています。
o RDP will attempt to detect and discard all damaged and
duplicate segments. It will use a checksum and sequence
number in each segment header to achieve this goal.
o RDPはすべての破損するのと写しセグメントを検出して、捨てるのを試みるでしょう。 それは、この目標を達成するのにそれぞれのセグメントヘッダーでチェックサムと一連番号を使用するでしょう。
o RDP will optionally provide sequenced delivery of
segments. Sequenced delivery of segments must be
specified when the connection is established.
o RDPは任意にセグメントの配列された配送を提供するでしょう。 接続が確立されると、セグメントの配列された配送は指定していなければなりません。
o RDP will acknowledge segments received out of sequence,
as they arrive. This will free up resources on the
sending side.
o RDPは到着するので順序が狂って受け取られたセグメントを承認するでしょう。 これは送付側でリソースを開けるでしょう。
3.2 RDP Connection Management
3.2 RDP接続管理
RDP is a connection-oriented protocol in which each
connection acts as a full-duplex communication channel between
two processes. Segments from a sender are directed to a port on
the destination host. The two 8-bit source and destination port
identifiers in the RDP header are used in conjunction with the
network source and destination addresses to uniquely identify
each connection.
RDPは2の間の全二重通信チャンネルが処理するとき各接続が行動する接続指向のプロトコルです。 送付者からのセグメントはあて先ホストの上のポートに向けられます。 RDPヘッダーの2の8ビットのソースと仕向港識別子は、唯一各接続を特定するのにネットワークソースと送付先アドレスに関連して使用されます。
Page 7
7ページ
RFC-908 July 1984
RFC-908 1984年7月
3.2.1 Opening a Connection
3.2.1 接続を開くこと。
Connections are opened by issuing the Open request, which
can be either active or passive. A passive Open request puts RDP
into the Listen state, during which it passively listens for a
request to open a connection from a remote site. The active Open
request attempts to establish a connection with a specified port
at a remote site.
コネクションズは、オープン要求を出すことによって、開かれます。(活発であるか、または要求は受け身である場合があります)。 受け身のオープン要求はListen状態にRDPを入れます。(それはそれの間、リモートサイトから接続を開くという要求の受け身に聞こうとします)。 活発なオープン要求は、指定されたポートがリモートサイトにある状態で取引関係を築くのを試みます。
The active Open request requires that a specific remote port
and host address be specified with the request. The passive Open
may optionally specify a specific remote port and network
address, or it may specify that an open be accepted from anyone.
If a specific remote port and host address were specified, an
arriving request to open a connection must exactly match the
specified remote port and address.
活発なオープン要求は、特定の遠く離れたポートとホスト・アドレスが要求で指定されるのを必要とします。 受け身のオープンが任意に特定の遠く離れたポートとネットワーク・アドレスを指定するかもしれませんか、またはだれからも戸外を受け入れるのは指定するかもしれません。 特定の遠く離れたポートとホスト・アドレスが指定されたなら、接続を開くという到着要求はまさに指定された遠く離れたポートとアドレスに合わなければなりません。
3.2.2 Ports
3.2.2 ポート
Valid port numbers range from 1 to 255 (decimal). There are
two types of ports: "well known" ports and "allocable" ports.
Well-known ports have numbers in the range 1 to 63 (decimal) and
allocable ports are given numbers in the range 64 to 255.
有効なポートナンバーは1〜255まで及びます(10進)。 2つのタイプのポートがあります: 「よく知られている」ポートと"allocable"ポート。 ウェルノウンポートは範囲に1〜63(10進)に数を持っています、そして、範囲で64〜255にallocableポートに数を与えます。
The user, when issuing an active Open request, must specify
both the remote host and port and may optionally specify the
local port. If the local port was not specified, RDP will select
an unused port from the range of allocable ports. When issuing a
passive Open request, the user must specify the local port
number. Generally, in this case the local port will be a well-
known port.
活発なオープン要求を出すとき、ユーザは、リモートホストとポートの両方を指定しなければならなくて、任意に地方のポートを指定するかもしれません。 地方のポートが指定されなかったなら、RDPはallocableポートの範囲から未使用のポートを選択するでしょう。 受け身のオープン要求を出すとき、ユーザは地方のポートナンバーを指定しなければなりません。 一般に、この場合、地方のポートはよく知られているポートになるでしょう。
3.2.3 Connection States
3.2.3 接続州
An RDP connection will progress through a series of states
during its lifetime. The states are shown in Figure 3 and are
individually described below. In Figure 3, the boxes represent
the states of the RDP FSM and the arcs represent changes in
state. Each arc is annotated with the event causing the state
change and the resulting output.
RDP接続は生涯一連の州を通って進歩をするでしょう。 州は、図3で見せられて、以下で個別に説明されます。 図3では、箱はRDP FSMの州を代表します、そして、アークは状態に変化を表します。 イベントが州の変化と結果として起こる出力を引き起こしていて、各アークは注釈されます。
Page 8
8ページ
RDP Specification Protocol Operation
RDP仕様プロトコル操作
CLOSED
閉じられます。
The CLOSED state exists when no connection exists and there
is no connection record allocated.
どんな接続も存在していなくて、また割り当てられた接続記録が全くないとき、CLOSED状態は存在しています。
LISTEN
聴いてください。
The LISTEN state is entered after a passive Open request is
processed. A connection record is allocated and RDP waits
for an active request to establish a connection from a
remote site.
受け身のオープン要求が処理された後にLISTEN状態は入られます。 接続記録を割り当てます、そして、RDPはリモートサイトから取引関係を築くという活発な要求を待っています。
SYN-SENT
SYNによって送られます。
The SYN-SENT state is entered after processing an active
Open request. A connection record is allocated, an initial
sequence number is generated, and a SYN segment is sent to
the remote site. RDP then waits in the SYN-SENT state for
acknowledgement of its Open request.
活発なオープン要求を処理した後に、SYN-SENT状態は入られます。 接続記録を割り当てます、そして、初期シーケンス番号は発生しています、そして、SYNセグメントをリモートサイトに送ります。 そして、RDPはSYN-SENT状態でオープン要求の承認を待っています。
SYN-RCVD
SYN-RCVD
The SYN-RCVD state may be reached from either the LISTEN
state or from the SYN-SENT state. SYN-RCVD is reached from
the LISTEN state when a SYN segment requesting a connection
is received from a remote host. In reply, the local RDP
generates an initial sequence number for its side of the
connection, and then sends the sequence number and an
acknowledgement of the SYN segment to the remote site. It
then waits for an acknowledgement.
SYN-RCVD状態にLISTENが述べるどちらかかSYN-SENT状態から達するかもしれません。 リモートホストから接続を要求するSYNセグメントを受け取るとき、SYN-RCVDにLISTEN状態から達しています。 回答では、地方のRDPは接続の側面の初期シーケンス番号を生成して、次に、SYNセグメントの一連番号と承認をリモートサイトに送ります。 そして、それは承認を待っています。
The SYN-RCVD state is reached from the SYN-SENT state when a
SYN segment is received from the remote host without an
accompanying acknowledgement of the SYN segment sent to that
remote host by the local RDP. This situation is caused by
simultaneous attempts to open a connection, with the SYN
segments passing each other in transit. The action is to
repeat the SYN segment with the same sequence number, but
now including an ACK of the remote host's SYN segment to
indicate acceptance of the Open request.
リモートホストから地方のRDPによってそのリモートホストに送られたSYNセグメントの付随の承認なしでSYNセグメントを受け取るとき、SYN-RCVD状態にSYN-SENT状態から達しています。 この状況はトランジットで互いを通過するSYNセグメントとの関係を開く同時の試みで引き起こされます。 同じ一連番号でSYNセグメントを繰り返しますが、動作はオープン要求の承認を示すためにリモートホストのSYNセグメントのACKを含んでいて、現在繰り返すことです。
Page 9
9ページ
RFC-908 July 1984
RFC-908 1984年7月
+------------+
Passive Open | |<-------------------------+
+----------------| CLOSED | |
| Request | |---------------+ |
V +------------+ | |
+------------+ | |
| | | |
| LISTEN | | |
| | | |
+------------+ | |
| Active | |
| rcv SYN Open Request | |
| ----------- ------------ | |
| snd SYN,ACK snd SYN | |
V rcv SYN V |
+------------+ ----------- +------------+ |
| | snd SYN,ACK | | |
| SYN-RCVD |<-------------------------------| SYN-SENT | |
| | | | |
+------------+ +------------+ |
| rcv ACK rcv SYN,ACK | |
| ---------- ------------- | |
| xxx +------------+ snd ACK | |
| | | | |
+--------------->| OPEN |<--------------+ |
| | |
+------------+ |
rcv RST | Close request |
----------- | --------------- |
xxx | snd RST |
V |
+------------+ |
| | |
| CLOSE-WAIT |--------------------------+
| | After a Delay
+------------+
+------------+ 開いている受動態| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ +----------------| 閉じられます。| | | 要求| |---------------+ | +に対して------------+ | | +------------+ | | | | | | | 聴いてください。| | | | | | | +------------+ | | | アクティブ| | | rcv SYNオープンRequest| | | ----------- ------------ | | | snd SYN、ACK snd SYN| | V rcv SYN V| +------------+ ----------- +------------+ | | | snd SYN、ACK| | | | SYN-RCVD|<-------------------------------| SYNによって送られます。| | | | | | | +------------+ +------------+ | | rcv ACK rcv SYN、ACK| | | ---------- ------------- | | | xxx+------------+ snd ACK| | | | | | | +--------------->| 戸外| <、-、-、-、-、-、-、-、-、-、-、-、-、--+ | | | | +------------+ | rcv RST| 要求を終えてください。| ----------- | --------------- | xxx| snd RST| V| +------------+ | | | | | 厳密な待ち|--------------------------+ | | 遅れ+の後に------------+
RDP Connection State Diagram
Figure 3
RDP接続州のダイヤグラムの数値3
Page 10
10ページ
RDP Specification Protocol Operation
RDP仕様プロトコル操作
OPEN
戸外
The OPEN state exists when a connection has been established
by the successful exchange of state information between the
two sides of the connection. Each side has exchanged and
received such data as initial sequence number, maximum
segment size, and maximum number of unacknowledged segments
that may be outstanding. In the Open state data may be sent
between the two parties of the connection.
接続が接続の2つの側面の間の州の情報のうまくいっている交換で確立されたとき、オープン状態は存在しています。 それぞれの側は、初期シーケンス番号(最大のセグメントサイズ、および最大数の傑出するかもしれない不承認のセグメント)としてそのようなデータを交換して、受け取りました。 オープン状態では、接続の2回のパーティーの間にデータを送るかもしれません。
CLOSE-WAIT
厳密な待ち
The CLOSE-WAIT state is entered from either a Close request
or from the receipt of an RST segment from the remote site.
RDP has sent an RST segment and is waiting a delay period
for activity on the connection to complete.
CLOSE-WAIT状態はClose要求かリモートサイトからのRSTセグメントの受領から入られます。 RDPはRSTセグメントを送って、接続の活動が完成する遅れの期間を待っています。
3.2.4 Connection Record
3.2.4 接続記録
The variables that define the state of a connection are
stored in a connection record maintained for each connection.
The following describes some of the variables that would be
stored in a typical RDP connection record. It is not intended to
be an implementation specification nor is it a complete
description. The purpose of naming and describing some of the
connection record fields is to simplify the description of RDP
protocol operation, particularly event processing.
接続の状態を定義する変数は各接続のために保守された接続記録に保存されます。 以下は典型的なRDP接続記録に保存される変数のいくつかについて説明します。 それは実装仕様であることを意図しません、そして、完全な記述ではありません。 接続記録分野のいくつかを命名して、説明する目的はRDPプロトコル操作(特にイベント処理)の記述を簡素化することです。
The connection record fields and their descriptions follow:
接続記録野原と彼らの記述は続きます:
STATE
状態
The current state of the connection. Legal values are OPEN,
LISTEN, CLOSED, SYN-SENT, SYN-RCVD, and CLOSE-WAIT.
接続の現状。 正当な値は、オープンと、LISTENと、CLOSEDと、SYN-SENTと、SYN-RCVDと、CLOSE-WAITです。
Send Sequence Number Variables:
一連番号変数を送ってください:
SND.NXT
SND.NXT
The sequence number of the next segment that is to be sent.
送られることになっている次のセグメントの一連番号。
Page 11
11ページ
RFC-908 July 1984
RFC-908 1984年7月
SND.UNA
SND.UNA
The sequence number of the oldest unacknowledged segment.
最も古い不承認のセグメントの一連番号。
SND.MAX
SND.MAX
The maximum number of outstanding (unacknowledged) segments
that can be sent. The sender should not send more than this
number of segments without getting an acknowledgement.
送ることができる傑出している(不承認の)セグメントの最大数。 承認を得ないで、送付者はこの数のセグメントほど発信するべきではありません。
SND.ISS
SND.ISS
The initial send sequence number. This is the sequence
number that was sent in the SYN segment.
初期は一連番号を送ります。 これはSYNセグメントで送られた一連番号です。
Receive Sequence Number Variables:
一連番号変数を受け取ってください:
RCV.CUR
RCV.CUR
The sequence number of the last segment received correctly
and in sequence.
正しく連続して受け取られた最後のセグメントの一連番号。
RCV.MAX
RCV.MAX
The maximum number of segments that can be buffered for this
connection.
この接続のためにバッファリングできるセグメントの最大数。
RCV.IRS
RCV.IRS
The initial receive sequence number. This is the sequence
number of the SYN segment that established this connection.
初期は一連番号を受けます。 これはこの接続を確立したSYNセグメントの一連番号です。
RCVDSEQNO[n]
RCVDSEQNO[n]
The array of sequence numbers of segments that have been
received and acknowledged out of sequence.
順序が狂って受け取られて、承認されたセグメントの一連番号の勢ぞろい。
Other Variables:
他の変数:
CLOSEWAIT
CLOSEWAIT
A timer used to time out the CLOSE-WAIT state.
タイマはCLOSE-WAIT状態をタイムアウトに使用しました。
SBUF.MAX
SBUF.MAX
The largest possible segment (in octets) that can legally be
sent. This variable is specified by the foreign host in the
法的に送ることができる可能な限り大きいセグメント(八重奏における)。 この変数は中で異種宿主によって指定されます。
Page 12
12ページ
RDP Specification Protocol Operation
RDP仕様プロトコル操作
SYN segment during connection establishment.
コネクション確立の間のSYNセグメント。
RBUF.MAX
RBUF.MAX
The largest possible segment (in octets) that can be
received. This variable is specified by the user when the
connection is opened. The variable is sent to the foreign
host in the SYN segment.
受け取ることができる可能な限り大きいセグメント(八重奏における)。 接続が開かれるとき、この変数はユーザによって指定されます。 SYNセグメントで変数を異種宿主に送ります。
Variables from Current Segment:
現在のセグメントからの変数:
SEG.SEQ
SEG.SEQ
The sequence number of the segment currently being
processed.
現在処理されるセグメントの一連番号。
SEG.ACK
SEG.ACK
The acknowledgement sequence number in the segment currently
being processed.
現在処理されるセグメントの承認一連番号。
SEG.MAX
SEG.MAX
The maximum number of outstanding segments the receiver is
willing to hold, as specified in the SYN segment that
established the connection.
受信機が接続を確立したSYNセグメントで指定されるように保持しても構わないと思っている傑出しているセグメントの最大数。
SEG.BMAX
SEG.BMAX
The maximum segment size (in octets) accepted by the foreign
host on a connection, as specified in the SYN segment that
established the connection.
最大のセグメントサイズ(八重奏における)は異種宿主で接続に受け入れました、接続を確立したSYNセグメントで指定されるように。
3.2.5 Closing a Connection
3.2.5 接続を終えること。
The closing of a connection can be initiated by a Close
request from the user process or by receipt of an RST segment
from the other end of the connection. In the case of the Close
request, RDP will send an RST segment to the other side of the
connection and then enter the CLOSE-WAIT state for a period of
time. While in the CLOSE-WAIT state, RDP will discard segments
received from the other side of the connection. When the time-
out period expires, the connection record is deallocated and the
connection ceases to exist. This simple connection closing
facility requires that users determine that all data has been
ユーザ・プロセスからのClose要求か接続のもう一方の端からのRSTセグメントの受領で接続の閉鎖を開始できます。 Close要求の場合では、RDPはRSTセグメントを接続の反対側に送って、次に、しばらく、CLOSE-WAIT状態に入れるでしょう。 RDPはCLOSE-WAIT状態で接続の反対側から受け取られたセグメントを捨てるでしょうが。 時間アウトの期間が期限が切れるとき、接続記録は「反-割り当て」られます、そして、接続は消滅します。 この接続の簡単な閉鎖施設は、ユーザが、すべてのデータがあったと決心しているのを必要とします。
Page 13
13ページ
RFC-908 July 1984
RFC-908 1984年7月
reliably delivered before requesting a close of the connection.
接続の閉鎖を要求する前に、確かに渡します。
3.2.6 Detecting an Half-Open Connection
3.2.6 半開きな接続を検出すること。
If one side of a connection crashes, the connection may be
left with the other side still active. This situation is termed
to be an half-open connection. For many cases, the active RDP
will eventually detect the half-open connection and reset. Two
examples of recovery from half-open connections are provided in
sections 5.7 and 5.8. Recovery is usually achieved by user
activity or by the crashed host's attempts to re-establish the
connection.
接続の半面がクラッシュするなら、接続は反対側がまだアクティブな状態でおかれるかもしれません。 この状況は、半開きな接続になるように呼ばれます。 多くのケースのために、アクティブなRDPは結局、半開きな接続とリセットを検出するでしょう。 セクション5.7と5.8で半開きな接続からの回復に関する2つの例を提供します。 通常、回復はユーザ活動か接続を復職させる墜落しているホストの試みで達成されます。
However, there are cases where recovery is not possible
without action by the RDP itself. For example, if all connection
blocks are in use, attempts to re-establish a broken connection
will be rejected. In this case, the RDP may attempt to free
resources by verifying that connections are fully open. It does
this by sending a NUL segment to each of the other RDPs. An
acknowledgement indicates the connection is still open and valid.
しかしながら、ケースが回復がRDP自身による動作なしで可能でないところにあります。 例えば、すべての接続ブロックが使用中であるなら、失意の接続を復職させる試みは拒絶されるでしょう。 この場合、RDPは、接続が完全にオープンであることを確かめることによってリソースを解放するのを試みるかもしれません。 それは、それぞれの他のRDPsにNULセグメントを送ることによって、これをします。 承認は、接続がまだオープンであって、有効であることを示します。
To minimize network overhead, verification of connections
should only be done when necessary to prevent a deadlock
situation. Only inactive connections should be verified. An
inactive connection is defined to be a connection that has no
outstanding unacknowledged segments, has no segments in the user
input or output queues, and that has not had any traffic for some
period of time.
行き詰まり状況を防ぐのに必要であるときにだけ、ネットワークオーバーヘッドを最小にするために、接続の検証をするべきです。 不活発な接続だけが確かめられるべきです。 不活発な接続は、どんな傑出している不承認のセグメントも持っていなくて、またユーザ入力か出力キューでセグメントを全く持っていなくて、またいつかの期間の間に少しの交通も持っていない接続になるように定義されます。
3.3 Data Communication
3.3 データ通信
Data flows through an RDP connection in the form of
segments. Each user message submitted with a Send request is
packaged for transport as a single RDP segment. Each RDP segment
is packaged as an RDP header and one or more octets of data. RDP
will not attempt to fragment a large user message into smaller
segments and re-assemble the message on the receiving end. This
differs from a byte-stream protocol such as TCP which supports
the transfer of an indeterminate length stream of data between
ports, buffering data until it is requested by the receiver.
データはセグメントの形のRDP接続で流れます。 Send要求で提出されたそれぞれのユーザメッセージは輸送のためにただ一つのRDPセグメントとしてパッケージされます。 それぞれのRDPセグメントはデータのRDPヘッダーと1つ以上の八重奏としてパッケージされます。 RDPは大きいユーザメッセージをより小さいセグメントに断片化して、受ける側になってメッセージを組み立て直すのを試みないでしょう。 これはポートの間のデータの不確定の長さのストリームの転送を支持するTCPなどのバイト・ストリームプロトコルと異なっています、それが受信機によって要求されるまでデータをバッファリングして。
Page 14
14ページ
RDP Specification Protocol Operation
RDP仕様プロトコル操作
At the RDP level, outgoing segments, as they are created,
are queued as input to the IP layer. Each segment is held by the
sending RDP until it is acknowledged by the foreign host.
Incoming segments are queued as input to the user process through
the user interface. Segments are acknowledged when they have
been accepted by the receiving RDP.
RDPレベルでは、それらが作成されるとき、外向的なセグメントはIP層に入力されるように列に並ばせられます。 それが異種宿主によって承認されるまで、各セグメントは発信しているRDPによって保持されます。 入って来るセグメントはユーザーインタフェースを通してユーザ・プロセスに入力されるように列に並ばせられます。 それらが受信RDPによって受け入れられたとき、セグメントは承認されます。
The receiving end of each connection specifies the maximum
segment size it will accept. Any attempt by the sender to
transmit a larger segment is an error. If RDP determines that a
buffer submitted with a Send request exceeds the maximum size
segment permitted on the connection, RDP will return an error to
the user. In addition, RDP will abort a connection with an RST
segment if an incoming segment contains more data than the
maximum acceptable segment size. No attempt will be made to
recover from or otherwise overcome this error condition.
それぞれの接続の犠牲者はそれが受け入れる最大のセグメントサイズを指定します。 より大きいセグメントを伝える送付者によるどんな試みも誤りです。 RDPが、Send要求で提出されたバッファが接続のときに受入れられた最大サイズセグメントを超えていることを決定すると、RDPは誤りをユーザに返すでしょう。 さらに、入って来るセグメントが最大の許容できるセグメントサイズより多くのデータを含んでいると、RDPはRSTセグメントとの関係を中止するでしょう。 どんな試みも、あるために回復するために人工であることで望んでもいませんし、そうでなければ、このエラー条件に打ち勝ちもしません。
If sequenced delivery of segments is necessary for a
connection, the requirement must be stated when the connection is
established. Sequenced delivery is specified when the Open
request is made. Sequenced delivery of segments will then be the
mode of delivery for the life of the connection.
セグメントの配列された配送が接続に必要であるなら、接続が確立されると、要件は述べなければなりません。 オープン要求をすると、配列された配送は指定しています。 そしてセグメントの配列された配送は接続の人生のための配送の方法になるでしょう。
3.4 Reliable Communication
3.4 信頼できるコミュニケーション
RDP implements a reliable message service through a number
of mechanisms. These include the insertion of sequence numbers
and checksums into segments, the positive acknowledgement of
segment receipt, and timeout and retransmission of missing
segments.
RDPは多くのメカニズムを通した信頼できるメッセージサービスを実行します。これらはなくなったセグメントのセグメントへの一連番号とチェックサムの挿入、セグメント領収書の積極的な承認、タイムアウト、および「再-トランスミッション」を含んでいます。
3.4.1 Segment Sequence Numbers
3.4.1 セグメント一連番号
Each segment transporting data has a sequence number that
uniquely identifies it among all other segments in the same
connection. The initial sequence number is chosen when the
connection is opened and is selected by reading a value from a
monotonically increasing clock. Each time a segment containing
data is transmitted, the sequence number is incremented.
Segments containing no data do not increment the sequence number.
However, the SYN and NUL segments, which cannot contain data, are
exceptions. The SYN segment is always sent with a unique
sequence number, the initial sequence number. The NUL segment is
データを輸送する各セグメントが同じ接続における他のすべてのセグメントの中で唯一それを特定する一連番号を持っています。 初期シーケンス番号はいつかが選ばれて、接続が開かれて、単調に増加する時計から値を読むことによって選ばれるということです。 データを含むセグメントが伝えられるたびに一連番号は増加されています。 データを全く含まないセグメントが一連番号を増加しません。 しかしながら、SYNとNULセグメント(データを含むことができない)は例外です。 ユニーク配列番号、初期シーケンス番号と共にSYNセグメントをいつも送ります。 NULセグメントはそうです。
Page 15
15ページ
RFC-908 July 1984
RFC-908 1984年7月
sent with the next valid sequence number.
次の有効な一連番号と共に発信しました。
3.4.2 Checksums
3.4.2 チェックサム
Each RDP segment contains a checksum to allow the receiver
to detect damaged segments. RDP uses a non-linear checksum
algorithm to compute a checksum that is 32-bits wide and operates
on data in units of four octets (32 bits). The area that is
covered by the checksum includes both the RDP header and the RDP
data area.
それぞれのRDPセグメントは破損しているセグメントを検出するために受信機を許容するチェックサムを含んでいます。 RDPは幅32ビットであるチェックサムを計算するのに非線形のチェックサムアルゴリズムを使用して、4つの八重奏(32ビット)のユニットのデータを作動させます。 チェックサムでカバーされている領域はRDPヘッダーとRDPデータ領域の両方を含んでいます。
If a segment contains a number of header and data octets
that is not an integral multiple of 4 octets, the last octet is
padded on the right with zeros to form a 32-bit quantity for
computation purposes. The padding zeros are not transmitted as
part of the segment. While computing the checksum, the checksum
field itself is replaced with zeros. The actual algorithm is
described in Section 4.2.1.
セグメントが4つの八重奏の不可欠の倍数でない多くのヘッダーとデータ八重奏を含んでいるなら、最後の八重奏は右でゼロで水増しされて、計算目的のための32ビットの量を形成します。 そっと歩いているゼロはセグメントの一部として伝えられません。 チェックサムを計算している間、チェックサム野原自体をゼロに取り替えます。 実際のアルゴリズムはセクション4.2.1で説明されます。
3.4.3 Positive Acknowledgement of Segments
3.4.3 セグメントの積極的な承認
RDP assumes it has only an unreliable datagram service to
deliver segments. To guarantee delivery of segments in this
environment, RDP uses positive acknowledgement and retransmission
of segments. Each segment containing data and the SYN and NUL
segments are acknowledged when they are correctly received and
accepted by the destination host. Segments containing only an
acknowledgement are not acknowledged. Damaged segments are
discarded and are not acknowledged. Segments are retransmitted
when there is no timely acknowledgement of the segment by the
destination host.
RDPは、セグメントを伝達するためにそれには頼り無いデータグラムサービスしかないと仮定します。 この環境における、セグメントの配送を保証するために、RDPはセグメントの積極的な承認と「再-トランスミッション」を使用します。 それらがあて先ホストによって正しく受け取られて、受け入れられるとき、データを含む各セグメント、SYN、およびNULセグメントは承認されます。 承認だけを含むセグメントが承認されません。 破損しているセグメントは、捨てられて、承認されません。 あて先ホストによるセグメントのどんなタイムリーな承認もないとき、セグメントは再送されます。
RDP allows two types of acknowledgement. A cumulative
acknowledgement is used to acknowledge all segments up to a
specified sequence number. This type of acknowledgement can be
sent using fixed length fields within the RDP header.
Specifically, the ACK control flag is set and the last
acknowledged sequence number is placed in the Acknowledgement
Number field.
RDPは2つのタイプの承認を許します。 累積している承認は、すべてのセグメントを指定された一連番号まで承認するのに使用されます。 このタイプの承認にRDPヘッダーの中に固定長電界を使用させることができます。 明確に、ACK指揮旗は設定されます、そして、最後に承認された一連番号はAcknowledgement Number分野に置かれます。
The extended or non-cumulative acknowledgement allows the
receiver to acknowledge segments out of sequence. This type of
acknowledgement is sent using the EACK control flag and the
広げられたか非累積している承認は、順序が狂ってセグメントを承認するために受信機を許容します。 そしてこのタイプの承認にEACK指揮旗を使用させる。
Page 16
16ページ
RDP Specification Protocol Operation
RDP仕様プロトコル操作
variable length fields in the RDP segment header. The variable
length header fields are used to hold the sequence numbers of the
acknowledged out-of-sequence segments.
RDPセグメントヘッダーの可変長フィールド。 可変長ヘッダーフィールドは、承認の一連番号が順序が狂ってセグメントであることを保持するのに使用されます。
The type of acknowledgement used is simply a function of the
order in which segments arrive. Whenever possible, segments are
acknowledged using the cumulative acknowledgement segment. Only
out-of-sequence segments are acknowledged using the extended
acknowledgement option.
使用される承認のタイプは単にセグメントが到達するオーダーの機能です。 可能であるときはいつも、セグメントは、累積している承認セグメントを使用することで承認されます。 順序が狂ってだけセグメントは、拡張承認オプションを使用することで承認されます。
The user process, when initiating the connection, cannot
restrict the type of acknowledgement used on the connection. The
receiver may choose not to implement out-of-sequence
acknowledgements. On the other hand, the sender may choose to
ignore out-of-sequence acknowledgements.
接続を開始するとき、ユーザ・プロセスは接続のときに使用された承認のタイプを制限しない場合があります。 受信機は、順序が狂って承認を実行しないのを選ぶかもしれません。 他方では、送付者は、順序が狂って承認を無視するのを選ぶかもしれません。
3.4.4 Retransmission Timeout
3.4.4 再送タイムアウト
Segments may be lost in transmission for two reasons: they
may be lost or damaged due to the effects of the lossy
transmission media; or they may be discarded by the receiving
RDP. The positive acknowledgement policy requires the receiver
to acknowledge a segment only when the segment has been correctly
received and accepted.
セグメントは2つの理由のためのトランスミッションで失われるかもしれません: それらは、損失性トランスミッションメディアの効果のため失われているか、または破損するかもしれません。 または、それらは受信RDPによって捨てられるかもしれません。 積極的な承認方針は、セグメントを正しく受け取って、受け入れたときだけ、セグメントを承認するために受信機を必要とします。
To detect missing segments, the sending RDP must use a
retransmission timer for each segment transmitted. The timer is
set to a value approximating the transmission time of the segment
in the network. When an acknowledgement is received for a
segment, the timer is cancelled for that segment. If the timer
expires before an acknowledgement is received for a segment, that
segment is retransmitted and the timer is restarted.
なくなったセグメント、RDPが使用しなければならない発信を検出するために、各セグメントのための再送信タイマーは送られました。 タイマはネットワークにおける、セグメントのトランスミッション時間に近似する値に設定されます。 セグメントのために承認を受けるとき、そのセグメントのためにタイマを取り消します。 セグメントのために承認を受ける前にタイマが期限が切れるなら、そのセグメントは再送されます、そして、タイマは再開されます。
3.5 Flow Control and Window Management
3.5フロー制御とウィンドウ管理
RDP employs a simple flow control mechanism that is based on
the number of unacknowledged segments sent and the maximum
allowed number of outstanding (unacknowledged) segments. Each
RDP connection has an associated set of flow control parameters
that include the maximum number of outstanding segments for each
side of a connection. These parameters are specified when the
connection is opened with the Open request, with each side of the
connection specifying its own parameters. The parameters are
RDPは送られた不承認のセグメントの数と傑出している(不承認の)セグメントの最大の許容数に基づいている簡単なフロー制御メカニズムを使います。 それぞれのRDP接続には、接続の各側面への傑出しているセグメントの最大数を含んでいる関連セットのフロー制御パラメタがあります。 接続がオープン要求で開かれると、これらのパラメタは指定されています、接続の各側面がそれ自身のパラメタを指定していて。 パラメタはそうです。
Page 17
17ページ
RFC-908 July 1984
RFC-908 1984年7月
passed from one host to another in the initial connection
segments.
初期の接続セグメントで1人のホストから別のホストまで通過されます。
The values specified for these parameters should be based on
the amount and size of buffers that the RDP is willing to
allocate to a connection. The particular RDP implementation can
set the parameters to values that are optimal for its buffering
scheme. Once these parameters are set they remain unchanged
throughout the life of the connection.
これらのパラメタに指定された値はRDPが割り当てても構わないと接続と思っているバッファの量とサイズに基づくべきです。 特定のRDP実現はバッファリング方式に、最適の値にパラメタを設定できます。 これらのパラメタがいったん設定されると、それらは接続の人生の間中変わりがありません。
RDP employs the concept of a sequence number window for
acceptable segment sequence numbers. The left edge of the window
is the number of the last in-sequence acknowledged sequence
number plus one. The right edge of the window is equal to the
left edge plus twice the allowed maximum number of outstanding
segments. The allowed maximum number of outstanding segments is
the number of segments the transmitting RDP software is allowed
to send without receiving any acknowledgement.
RDPは許容できるセグメント一連番号に一連番号ウィンドウの概念を使います。 窓の左の縁は最後に連続して承認された一連番号と1の数です。 窓の正しい縁は左の縁と許容最大数の2倍の傑出しているセグメントと等しいです。 許容最大数の傑出しているセグメントは伝わっているRDPソフトウェアがどんな承認も受けないで送ることができるセグメントの数です。
The flow control and window management parameters are used
as follows. The RDP module in the transmitting host sends
segments until it reaches the connection's segment limit
specified by the receiving process. Once this limit is reached,
the transmitting RDP module may only send a new segment for each
acknowledged segment.
フロー制御と窓の管理パラメタは以下の通り使用されます。 それが受信工程で指定された接続のセグメント限界に達するまで、伝わっているホストのRDPモジュールはセグメントを送ります。 この限界にいったん達していると、伝わっているRDPモジュールはそれぞれの承認されたセグメントのために新しいセグメントを送るだけであるかもしれません。
When a received segment has a sequence number that falls
within the acceptance window, it is acknowledged. If the
sequence number is equal to the left-hand edge (i.e., it is the
next sequence number expected), the segment is acknowledged with
a cumulative acknowledgement (ACK). The acceptance window is
adjusted by adding one to the value of the edges. If the
sequence number is within the acceptance window but is out of
sequence, it is acknowledged with a non-cumulative
acknowledgement (EACK). The window is not adjusted, but the
receipt of the out-of-sequence segment is recorded.
容認されたセグメントに承認ウィンドウの中に下がる一連番号があると、それは承認されます。 一連番号が左手の縁と等しいなら(すなわち、それは予想された次の一連番号です)、セグメントは累積している承認(ACK)で承認されます。 承認ウィンドウは、縁の値に1つを加えることによって、調整されます。 一連番号が承認ウィンドウの中にありますが、系列から脱しているなら、それは非累積している承認(EACK)で承認されます。 窓は調整されませんが、系列で出ているセグメントの領収書は記録されています。
When segments are acknowledged out of order, the
transmitting RDP module must not transmit beyond the acceptance
window. This could occur if one segment is not acknowledged but
all subsequent segments are received and acknowledged. This
condition will fix the left edge of the window at the sequence
number of the unacknowledged segment. As additional segments are
transmitted, the next segment to be sent will approach and
eventually overtake the right window edge. At this point all
transmission of new segments will cease until the unacknowledged
segment is acknowledged.
セグメントが故障していた状態で承認されるときRDPモジュールが承認ウィンドウを超えて送ってはいけない伝わること。 1つのセグメントが承認されませんが、すべてのその後のセグメントが受け取られて、承認されるなら、これは起こるかもしれません。 この状態は不承認のセグメントの一連番号で窓の左の縁を修理するでしょう。 追加セグメントが伝えられるのに従って、送られる次のセグメントは、アプローチして、結局、正しい窓の縁に追いつくでしょう。 ここに、不承認のセグメントが承認されるまで、新しいセグメントのすべての送信がやむでしょう。
Page 18
18ページ
RDP Specification Protocol Operation
RDP仕様プロトコル操作
3.6 User Interface
3.6 ユーザーインタフェース
The user interface to RDP is implementation dependent and
may use system calls, function calls or some other mechanism.
The list of requests that follows is not intended to suggest a
particular implementation.
RDPへのユーザーインタフェースは、実現に依存していて、システムコール、ファンクションコールまたはある他のメカニズムを使用するかもしれません。 従う要求のリストが特定の実現を示すことを意図しません。
OPEN Request
開いている要求
Opens a connection. Parameters include type (active or
passive), local port, remote port, remote host address,
maximum segment size, maximum number of unacknowledged
segments, delivery mode (sequenced or non-sequenced). The
connection id, including any allocated port number, is
returned to the user.
接続を開きます。 パラメタはタイプ(アクティブであるか受け身の)を含んでいます、地方のポート、遠く離れたポート、リモートホスト・アドレス、最大のセグメントサイズ、最大数の不承認のセグメント、配送モード(配列されたか非配列された)。 どんな割り当てられたポートナンバーも含む接続イドをユーザに返します。
SEND Request
要求を送ってください。
Sends a user message. Parameters include connection
identifier, buffer address and data count.
ユーザメッセージを送ります。 パラメタは接続識別子、バッファアドレスを含んでいます、そして、データは重要です。
RECEIVE Request
要求を受け取ってください。
Receives a user message. Parameters include connection
identifier, buffer address and data count.
ユーザメッセージを受け取ります。 パラメタは接続識別子、バッファアドレスを含んでいます、そして、データは重要です。
CLOSE Request
要求を終えてください。
Closes a specified connection. The single parameter is the
connection identifier.
指定された接続を終えます。 ただ一つのパラメタは接続識別子です。
STATUS Request
状態要求
Returns the status of a connection. The parameters include
the connection identifier and the address of the status
buffer.
接続の状態を返します。 パラメタは接続識別子と状態バッファのアドレスを含んでいます。
Page 19
19ページ
RFC-908 July 1984
RFC-908 1984年7月
3.7 Event Processing
3.7 イベント処理
This section describes one possible sequence for processing
events. It is not intended to suggest a particular
implementation, but any actual implementation should vary from
this description only in detail and not significantly in
substance. The following are the kinds of events that may occur:
このセクションは処理出来事のために1つの可能な系列について説明します。 それが特定の実現を示すことを意図しませんが、実のところ、どんな実際の実現もかなりと異なるのではなく、詳細だけこの記述と異なるべきです。 ↓これは起こるかもしれない出来事の種類です:
USER REQUESTS
ユーザ要求
Open
Send
Receive
Close
Status
オープンが発信する、近い状態を取ってください。
ARRIVING SEGMENT
到着セグメント
Segment Arrives
セグメントは到着します。
TIMEOUTS
タイムアウト
Retransmission Timeout
Close-Wait Timeout
再送タイムアウト厳密な待ちタイムアウト
User request processing always terminates with a return to
the caller, with a possible error indication. Error responses
are given as a character string. A delayed response is also
possible in some situations and is returned to the user by
whatever event or pseudo interrupt mechanism is available. The
term "signal" is used to refer to delayed responses.
ユーザ要求処理はいつも訪問者へのリターン、可能な誤り表示で終わります。 文字列として誤り応答を与えます。 遅延応答をまた、いくつかの状況で可能であり、いかなる利用可能なイベントか疑似中断メカニズムもユーザに返します。 「信号」という用語は、遅延応答について言及するのに使用されます。
Processing of arriving segments usually follows this general
sequence: the sequence number is checked for validity and, if
valid, the segment is queued and processed in sequence-number
order. For all events, unless a state change is specified, RDP
remains in the same state.
通常、到着セグメントの処理はこの一般的な順序に従います: 一連番号が正当性がないかどうかチェックされて、有効であるなら、セグメントは、一連番号オーダーで列に並ばせられて、処理されます。 すべてのイベントのために、州の変化が指定されない場合、RDPは同じ州に残っています。
Page 20
20ページ
RDP Specification Protocol Operation
RDP仕様プロトコル操作
3.7.1 User Request Events
3.7.1 ユーザ要求イベント
The following scenarios demonstrate the processing of events
caused by the issuance of user requests:
以下のシナリオはユーザ要求の発行によって引き起こされたイベントの処理を示します:
Open Request
開いている要求
CLOSED STATE
閉じている状態
Create a connection record
If none available
Return "Error - insufficient resources"
Endif
接続の記録的なIfのために利用可能ななにも作成しないでください、Return、「誤り--不十分なリソース」、Endif
If passive Open
If local port not specified
Return "Error - local port not specified"
Endif
Generate SND.ISS
Set SND.NXT = SND.ISS + 1
SND.UNA = SND.ISS
Fill in SND.MAX, RMAX.BUF from Open parameters
Set State = LISTEN
Return
Endif
受け身のオープンIf地方のポートがSND.MAXでSND.ISS+1「誤り--地方のポートは指定しなかった」というReturn Endif Generate SND.ISS Set SND.NXT=SND.UNA=SND.ISS Fillを指定しなかったなら、オープンパラメタSet州からのRMAX.BUFがLISTEN Return Endifと等しいです。
If active Open
If remote port not specified
Return "Error - remote port not specified"
Endif
Generate SND.ISS
Set SND.NXT = SND.ISS + 1
SND.UNA = SND.ISS
Fill in SND.MAX, RMAX.BUF from Open parameters
If local port not specified
Allocate a local port
Endif
Send <SEQ=SND.ISS><MAX=SND.MAX><MAXBUF=RMAX.BUF><SYN>
Set State = SYN-SENT
Return (local port, connection identifier)
Endif
アクティブなオープンIf遠く離れたポートがSND.MAXでSND.ISS+1「誤り--遠く離れたポートは指定しなかった」というReturn Endif Generate SND.ISS Set SND.NXT=SND.UNA=SND.ISS Fillを指定しなかったなら、オープンパラメタ指定されたAllocateではなく、Ifの地方のポートSND.MAX><MAXBUF=RMAX.BUF><SYN>Set地元のポートのEndif Send<SEQ=SND.ISS><マックス=州からのRMAX.BUFがSYN-SENT Return(地方のポート、接続識別子)Endifと等しいです。
Page 21
21ページ
RFC-908 July 1984
RFC-908 1984年7月
LISTEN STATE
SYN-SENT STATE
SYN-RCVD STATE
OPEN STATE
CLOSE-WAIT STATE
SYNによって送られた州の州のSYN-RCVD州の開口状態近い待ち状態を聴いてください。
Return "Error - connection already open"
「既にオープンな誤り--接続」を返してください。
Close Request
要求を終えてください。
OPEN STATE
開口状態
Send <SEQ=SND.NXT><RST>
Set State = CLOSE-WAIT
Start TIMWAIT Timer
Return
<SEQ=SND.NXT><RST>セット州=厳密な待ちスタートTIMWAITタイマリターンを送ってください。
LISTEN STATE
状態を聴いてください。
Set State = CLOSED
Deallocate connection record
Return
CLOSED Deallocate州=接続の記録的なReturnを設定してください。
SYN-RCVD STATE
SYN-SENT STATE
SYN-RCVDはSYNによって送られた状態を述べます。
Send <SEQ=SND.NXT><RST>
Set State = CLOSED
Return
閉じている<SEQ=SND.NXT><RST>セット状態=リターンを送ってください。
CLOSE-WAIT STATE
近い待ち状態
Return "Error - connection closing"
リターン、「誤り--接続は閉じます」。
CLOSE STATE
状態を閉じてください。
Return "Error - connection not open"
「オープンでない誤り--接続」を返してください。
Page 22
22ページ
RDP Specification Protocol Operation
RDP仕様プロトコル操作
Receive Request
要求を受け取ってください。
OPEN STATE
開口状態
If Data is pending
Return with data
else
Return with "no data" indication
Endif
Dataが「データがありません」指示EndifとデータのほかのReturnと未定のReturnであるなら
LISTEN STATE
SYN-RCVD STATE
SYN-SENT STATE
SYN-RCVD州が状態をSYN送った状態を聴いてください。
Return with "no data" indication
「データがありません」指示とともに帰ってください。
CLOSE STATE
CLOSE-WAIT STATE
州の近い待ち状態を閉じてください。
Return "Error - connection not open"
「オープンでない誤り--接続」を返してください。
Send Request
要求を送ってください。
OPEN STATE
開口状態
If SND.NXT < SND.UNA + SND.MAX
Send <SEQ=SND.NXT><ACK=RCV.CUR><ACK><Data>
Set SND.NXT = SND.NXT + 1
Return
else
Return "Error - insufficient resources to send data"
Endif
SND.NXT<SND.UNA+SND.MAX Send<SEQ=SND.NXT><ACK=RCV.CUR><ACK><Data>Set SND.NXTがSND.NXT+1のReturnのほかのReturnと等しい、「データを送る誤り--不十分なリソース」Endif
LISTEN STATE
SYN-RCVD STATE
SYN-SENT STATE
CLOSE STATE
CLOSE-WAIT STATE
SYN-RCVD州が州の近い州の近い待ち状態をSYN送った状態を聴いてください。
Return "Error - connection not open"
「オープンでない誤り--接続」を返してください。
Status Request
状態要求
Return with:
以下と共に戻ってください。
Page 23
23ページ
RFC-908 July 1984
RFC-908 1984年7月
State of connection (OPEN, LISTEN, etc.)
Number of segments unacknowledged
Number of segments received not given to user
Maximum segment size for the send side of the connection
Maximum segment size for the receive side of the connection
接続(オープン、LISTENなど)の状態 ユーザへのMaximumがサイズを区分する当然のことではなく、セグメントの不承認のNumberが受けたセグメントの数、Maximumがサイズを区分する接続の側面を送ってください、接続の側面を受け取ってください。
3.7.2 Segment Arrival Events
3.7.2 セグメント到着イベント
The following scenarios describe the processing of the event
caused by the arrival of a RDP segment from a remote host. The
assumption is made that the segment was addressed to the local
port associated with the connection record.
以下のシナリオはリモートホストからのRDPセグメントの到着で引き起こされたイベントの処理について説明します。 セグメントが接続記録に関連している地方のポートに扱われたという仮定はされます。
If State = CLOSED
状態=が休んだなら
If RST set
Discard segment
Return
Endif
RSTがDiscardセグメントReturn Endifを設定するなら
If ACK or NUL set
Send <SEQ=SEG.ACK + 1><RST>
Discard segment
Return
else
Send <SEQ=0><RST><ACK=RCV.CUR><ACK>
Discard segment
Return
Endif
ACKかNULがほかのSendの><ACK>Discard<SEQ=SEG.ACK+1><RST>DiscardセグメントReturn Send<SEQ=0><RST><ACK=RCV.CURセグメントReturn Endifを設定するなら
Endif
Endif
If State = CLOSE-WAIT
If RST set
Set State = CLOSED
Discard segment
Cancel TIMWAIT timer
Deallocate connection record
else
Discard segment
Endif
Return
Endif
州=CLOSE-WAIT If RSTがCLOSED DiscardのタイマのDeallocateの記録のほかのDiscardセグメントキャンセルTIMWAIT接続Set州=セグメントEndif Return Endifを設定するなら
Page 24
24ページ
RDP Specification Protocol Operation
RDP仕様プロトコル操作
If State = LISTEN
= 聴くように述べてくださいなら
If RST set
Discard the segment
Return
Endif
RSTがDiscardセグメントReturn Endifを設定するなら
If ACK or NUL set
Send <SEQ=SEG.ACK + 1><RST>
Return
Endif
ACKかNULがSend<SEQ=SEG.ACK+1><RST>Return Endifを設定するなら
If SYN set
Set RCV.CUR = SEG.SEQ
RCV.IRS = SEG.SEQ
SND.MAX = SEG.MAX
SBUF.MAX = SEG.BMAX
Send <SEQ=SND.ISS><ACK=RCV.CUR><MAX=RCV.MAX><BUFMAX=RBUF.MAX>
<ACK><SYN>
Set State = SYN-RCVD
Return
Endif
RCV.MAX><BUFMAX=RBUF.MAX><ACK><SYN>Set SEG.BMAX Send<SEQ=SND.ISS><ACK=RCV.CUR><SYNセットSet RCV.CUR=SEG.SEQ RCV.IRS=SEG.SEQ SND.MAX=SEG.MAX SBUF.MAX=マックス=州がSYN-RCVD Return Endifと等しいなら
If anything else (should never get here)
Discard segment
Return
Endif
Endif
他の何か(ここに決して到着するべきでない)であるなら、セグメントReturn Endif Endifを捨ててください。
If State = SYN-SENT
状態=がSYN発信したなら
If ACK set
If RST clear and SEG.ACK != SND.ISS
Send <SEQ=SEG.ACK + 1><RST>
Endif
Discard segment; Return
Endif
ACKがIf RSTを設定するなら、クリアしてください。そうすれば、SEG.ACK!はSND.ISS Send<SEQ=SEG.ACK+1><RST>Endif Discardセグメントと等しいです。 リターンEndif
If RST set
If ACK set
Signal "Connection Refused"
Set State = CLOSED
Deallocate connection record
Endif
Discard segment
Return
Endif
RSTセットIf ACKがSignal「接続は拒否した」Set州=CLOSED Deallocate接続記録Endif DiscardセグメントReturn Endifを設定するなら
Page 25
25ページ
RFC-908 July 1984
RFC-908 1984年7月
If SYN set
Set RCV.CUR = SEG.SEQ
RCV.IRS = SEG.SEQ
SND.MAX = SEG.MAX
RBUF.MAX = SEG.BMAX
If ACK set
Set SND.UNA = SEG.ACK
State = OPEN
Send <SEQ=SND.NXT><ACK=RCV.CUR><ACK>
else
Set State = SYN-RCVD
Send <SEQ=SND.ISS><ACK=RCV.CUR><MAX=RCV.MAX><BUFMAX=RBUF.MAX>
<SYN><ACK>
Endif
Return
Endif
SYN-RCVD Send<SEQ=SND.ISS><ACK=RCV.CUR><オープンの<のACKの>のほかのSet Send<SEQ=SND.NXT><ACK=RCV.CUR>SEG.ACK SEG.BMAX If ACKセットSYNセットSet RCV.CUR=SEG.SEQ RCV.IRS=SEG.SEQ SND.MAX=SEG.MAX RBUF.MAX=Set SND.UNA=州=州=マックスがRCV.MAX><BUFMAX=RBUF.MAX><SYN><ACK>Endif Return Endifと等しいなら
If anything else
Discard segment
Return
Endif
Endif
どちらかと言えば、DiscardはほかのReturn Endif Endifを区分します。
If State = SYN-RCVD
状態がSYN-RCVDと等しいなら
If RCV.IRS < SEG.SEQ =< RCV.CUR + (RCV.MAX * 2)
Segment sequence number acceptable
else
Send <SEQ=SND.NXT><ACK=RCV.CUR><ACK>
Discard segment
Return
Endif
RCV.IRS<SEG.SEQが(RCV.MAX*2)セグメント一連番号<RCV.CUR+許容できるほかのSendの><ACK>Discard<SEQ=SND.NXT><ACK=RCV.CURセグメントReturn Endifと等しいなら
If RST set
If passive Open
Set State = LISTEN
else
Set State = CLOSED
Signal "Connection Refused"
Discard segment
Deallocate connection record
Endif
Return
Endif
RSTがCLOSED Signal「接続は拒否した」DiscardセグメントDeallocate LISTENのほかのSet Ifの受け身のオープンSet州=州=接続の記録的なEndif Return Endifを設定するなら
Page 26
26ページ
RDP Specification Protocol Operation
RDP仕様プロトコル操作
If SYN set
Send <SEQ=SEG.ACK + 1><RST>
Set State = CLOSED
Signal "Connection Reset"
Discard segment
Deallocate connection record
Return
Endif
SYNがCLOSED Signal「接続リセット」DiscardセグメントDeallocate Send<SEQ=SEG.ACK+1><RST>Set州=接続の記録的なReturn Endifを設定するなら
If EACK set
Send <SEQ=SEG.ACK + 1><RST>
Discard segment
Return
Endif
EACKがSend<SEQ=SEG.ACK+1><RST>DiscardセグメントReturn Endifを設定するなら
If ACK set
If SEG.ACK = SND.ISS
Set State = OPEN
else
Send <SEQ=SEG.ACK + 1><RST>
Discard segment
Return
Endif
else
Discard segment
Return
Endif
SND.ISS Set ACKセットIf SEG.ACK=州がほかのオープンのDiscardセグメントReturn EndifほかのDiscard Send<SEQ=SEG.ACK+1><RST>セグメントReturn Endifと等しいなら
If Data in segment or NUL set
If the received segment is in sequence
Copy the data (if any) to user buffers
Set RCV.CUR=SEG.SEQ
Send <SEQ=SND.NXT><ACK=RCV.CUR><ACK>
else
If out-of-sequence delivery permitted
Copy the data (if any) to user buffers
Endif
Send <SEQ=SND.NXT><ACK=RCV.CUR><ACK><EACK><RCVDSEQNO1>
...<RCVDSEQNOn>
Endif
Endif
系列Copyでは、セグメントのDataかNULがIfを設定するなら、容認されたセグメントはユーザバッファの>の<のACKの>のほかのSet RCV.CUR=SEG.SEQ Send<SEQ=SND.NXT><ACK=RCV.CUR Ifへのデータ(もしあれば)です。順序が狂って配送はユーザバッファEndif Send<SEQ=SND.NXT><ACK=RCV.CUR><ACK><EACK><RCVDSEQNO1>にデータ(もしあれば)をCopyに可能にしました…<RCVDSEQNOn>Endif Endif
Endif
Endif
Page 27
27ページ
RFC-908 July 1984
RFC-908 1984年7月
If State = OPEN
状態が戸外と等しいなら
If RCV.CUR < SEG.SEQ =< RCV.CUR + (RCV.MAX * 2)
Segment sequence number acceptable
else
Send <SEQ=SND.NXT><ACK=RCV.CUR><ACK>
Discard segment and return
Endif
RCV.CUR<SEG.SEQが(RCV.MAX*2)セグメント一連番号<RCV.CUR+許容できるほかのSendの><ACK>Discard<SEQ=SND.NXT><ACK=RCV.CURセグメントと等しく、Endifを返すなら
If RST set
Set State = CLOSE-WAIT
Signal "Connection Reset"
Return
Endif
RSTがCLOSE-WAIT Signal「接続リセット」Set州=Return Endifを設定するなら
If NUL set
Set RCV.CUR=SEG.SEQ
Send <SEQ=SND.NXT><ACK=RCV.CUR><ACK>
Discard segment
Return
Endif
NULがSet RCV.CUR=SEG.SEQ Send<SEQ=SND.NXT><ACK=RCV.CUR><ACK>DiscardセグメントReturn Endifを設定するなら
If SYN set
Send <SEQ=SEG.ACK + 1><RST>
Set State = CLOSED
Signal "Connection Reset"
Discard segment
Deallocate connection record
Return
Endif
SYNがCLOSED Signal「接続リセット」DiscardセグメントDeallocate Send<SEQ=SEG.ACK+1><RST>Set州=接続の記録的なReturn Endifを設定するなら
If ACK set
If SND.UNA =< SEG.ACK < SND.NXT
Set SND.UNA = SEG.ACK
Flush acknowledged segments
Endif
Endif
<SEG.ACK<ACKセットIf SND.UNA=SND.NXT Set SND.UNA=SEG.ACK FlushがセグメントEndif Endifを承認したなら
If EACK set
Flush acknowledged segments
Endif
EACKセットFlushがセグメントEndifを承認したなら
Page 28
28ページ
RDP Specification Protocol Operation
RDP仕様プロトコル操作
If Data in segment
If the received segment is in sequence
Copy the data to user buffers
Set RCV.CUR=SEG.SEQ
Send <SEQ=SND.NXT><ACK=RCV.CUR><ACK>
else
If out-of-sequence delivery permitted
Copy the data to user buffers
Endif
Send <SEQ=SND.NXT><ACK=RCV.CUR><ACK><EACK><RCVDSEQNO1>
...<RCVDSEQNOn>
Endif
Endif
Endif
系列Copyでは、セグメントIfでのDataであるなら、容認されたセグメントはユーザバッファの>の<のACKの>のほかのSet RCV.CUR=SEG.SEQ Send<SEQ=SND.NXT><ACK=RCV.CUR Ifへのデータです。順序が狂って配送はユーザバッファEndif Send<SEQ=SND.NXT><ACK=RCV.CUR><ACK><EACK><RCVDSEQNO1>にデータをCopyに可能にしました…<RCVDSEQNOn>Endif Endif Endif
3.7.3 Timeout Events
3.7.3 タイムアウトイベント
Timeout events occur when a timer expires and signals the
RDP. Two types of timeout events can occur, as described below:
タイマがRDPを吐き出して、合図するとき、タイムアウトイベントは起こります。 2つのタイプのタイムアウトイベントは以下で説明されるように起こることができます:
RETRANSMISSION TIMEOUTS
再送タイムアウト
If timeout on segment at head of retransmission queue
Resend the segment at head of queue
Restart the retransmission timer for the segment
Requeue the segment on retransmission queue
Return
Endif
タイムアウトである、オンである、再送キューResendのヘッドで待ち行列Restartのヘッドにおけるセグメントを区分してください、「再-トランスミッション」の上のセグメントが列に並ばせるセグメントRequeueのための再送信タイマー、Return Endif
CLOSE-WAIT TIMEOUTS
厳密な待ちタイムアウト
Set State = CLOSED
Deallocate connection record
Return
CLOSED Deallocate州=接続の記録的なReturnを設定してください。
Page 29
29ページ
RFC-908 July 1984
RFC-908 1984年7月
Page 30
30ページ
RDP Specification RDP Segments and Formats
RDP仕様RDPセグメントと形式
CHAPTER 4
第4章
RDP Segments and Formats
RDPセグメントと形式
The segments sent by the application layer are encapsulated
in headers by the transport, internet and network layers, as
follows:
応用層で送られたセグメントは以下の通りヘッダーで輸送、インターネット、およびネットワーク層によってカプセル化されます:
+----------------+
| Network Access |
| Header |
+----------------+
| IP Header |
+----------------+
| RDP Header |
+----------------+
| D |
| A |
| T |
| A |
+----------------+
+----------------+ | ネットワークアクセス| | ヘッダー| +----------------+ | IPヘッダー| +----------------+ | RDPヘッダー| +----------------+ | D| | A| | T| | A| +----------------+
Segment Format
Figure 4
セグメント形式図4
4.1 IP Header Format
4.1 IPヘッダー形式
When used in the internet environment, RDP segments are sent
using the version 4 IP header as described in RFC791, "Internet
Protocol." The RDP protocol number is ??? (decimal). The time-
to-live field should be set to a reasonable value for the
network.
インターネット環境で使用すると、RDPセグメントにRFC791、「インターネットプロトコル」で説明されるようにバージョン4IPヘッダーを使用させます。 RDPプロトコル番号はそうですか?(10進。) 時間、-生きてください、分野はネットワークのための適正価値に設定されるべきです。
All other fields should be set as specified in RFC-791.
他のすべての分野がRFC-791で指定されるように設定されるべきです。
Page 31
31ページ
RFC-908 July 1984
RFC-908 1984年7月
4.2 RDP Header Format
4.2 RDPヘッダー形式
Every RDP segment is prefaced with an RDP header. The
format of the header is shown in Figure 5 below. The RDP header
is variable in length and its size is indicated by a field in a
fixed location within the header.
あらゆるRDPセグメントがRDPヘッダーと共に前書きされます。 ヘッダーの書式は以下の図5に示されます。 RDPヘッダーは長さで可変です、そして、サイズはヘッダーの中に固定ロケーションで分野によって示されます。
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 | Dest. Port |
+---------------+---------------+
2 | Data Length |
+---------------+---------------+
3 | |
+--- Sequence Number ---+
4 | |
+---------------+---------------+
5 | |
+--- Acknowledgement Number ---+
6 | |
+---------------+---------------+
7 | |
+--- Checksum ---+
8 | |
+---------------+---------------+
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 | ソースポート| Dest。 ポート| +---------------+---------------+ 2 | データの長さ| +---------------+---------------+ 3 | | +--- 一連番号---+ 4 | | +---------------+---------------+ 5 | | +--- 承認番号---+ 6 | | +---------------+---------------+ 7 | | +--- チェックサム---+ 8 | | +---------------+---------------+ 9 | 可変ヘッダー領域| . . . . | | +---------------+---------------+
RDP Header Format
Figure 5
RDPヘッダー形式数値5
Page 32
32ページ
RDP Specification RDP Segments and Formats
RDP仕様RDPセグメントと形式
4.2.1 RDP Header Fields
4.2.1 RDPヘッダーフィールド
Control Flags
指揮旗
This 8-bit field occupies the first octet of word one in the
header. It is bit encoded with the following bits currently
defined:
この8ビットの分野はヘッダーにおける、Word1の最初の八重奏を占領します。 それは以下のビットが現在定義されている状態でコード化されたビットです:
Bit # Bit Name Description
噛み付いている#ビット名前記述
0 SYN Establish connection and
synchronize sequence numbers.
1 ACK Acknowledge field significant.
2 EACK Non-cumulative (Extended) acknowledgement.
3 RST Reset the connection.
4 NUL This is a null (zero data length) segment.
5 Unused.
そして、0SYN Establish接続、一連番号を同期させてください。 1 ACK Acknowledge分野重要です。 2 EACK Non累積している(拡張)承認。 3 接続のRST Reset。 4NUL Thisがヌル(データの長さがない)のセグメントです。 5 未使用です。
Note that the SYN and RST are sent as separate segments and
may not contain any data. The ACK may accompany any
message. The NUL segment must have a zero data length, but
may be accompanied by ACK and EACK information. The other
control bit is currently unused and is defined to be zero.
SYNとRSTが別々のセグメントとして送られて、少しのデータも含まないかもしれないことに注意してください。 ACKはどんなメッセージにも伴うかもしれません。 aにデータの長さのゼロを合わせなければなりませんが、NULセグメントは、ACKとEACK情報によって伴われるかもしれません。 もう片方のコントロールビットは、現在、未使用であり、ゼロになるように定義されます。
Version Number
バージョン番号
This field occupies bits 6-7 of the first octet. It
contains the version number of the protocol described by
this document. Current value is one (1).
この分野は最初の八重奏のビット6-7を占領します。 それはこのドキュメントによって説明されたプロトコルのバージョン番号を含んでいます。 現行価値は1つ(1)です。
Header Length
ヘッダ長
The length of the RDP header in units of two (2) octets,
including this field. This field allows RDP to find the
start of the Data field, given a pointer to the head of the
segment. This field is 8 bits in length. For a segment
with no variable header section, the header length field
will have the value 9.
この分野を含むユニットの2(2)八重奏における、RDPヘッダーの長さ。 RDPはこの分野でData分野の始まりを見つけることができます、セグメントのヘッドへの指針を考えて。 長さはこの分野が8ビットです。 可変ヘッダー部分のないセグメントのために、ヘッダ長分野には、値9があるでしょう。
Source and Destination Ports
ソースと仕向港
The Source and Destination Ports are used to identify the
processes in the two hosts that are communicating with each
other. The combination of the port identifiers with the
source and destination addresses in the network access
SourceとDestination Portsは、互いにコミュニケートしている2人のホストでプロセスを特定するのに使用されます。 ソースと送付先アドレスへのポート識別子のネットワークアクセスにおける、組み合わせ
Page 33
33ページ
RFC-908 July 1984
RFC-908 1984年7月
protocol header serves to fully qualify the connection and
constitutes the connection identifier. This permits RDP to
distinguish multiple connections between two hosts. Each
field is 8 bits in length, allowing port numbers from 0 to
255 (decimal).
プロトコルヘッダーは、接続に完全に資格を与えるのに勤めて、接続識別子を構成します。 これは、RDPが2人のホストの間の複数の接続を区別することを許可します。 0〜255までのポートナンバー(10進)を許容する長さは各分野が8ビットです。
Data Length
データの長さ
The length in octets of the data in this segment. The data
length does not include the RDP header. This field is 16
bits in length.
このセグメントにおける、データの八重奏における長さ。 データの長さはRDPヘッダーを含んでいません。 長さはこの分野が16ビットです。
Sequence Number
一連番号
The sequence number of this segment. This field is 32 bits
in length.
このセグメントの一連番号。 長さはこの分野が32ビットです。
Acknowledgement Number
承認番号
If the ACK bit is set in the header, this is the sequence
number of the segment that the sender of this segment last
received correctly and in sequence. Once a connection is
established this should always be sent. This field is 32
bits in length.
ACKビットがヘッダーに設定されるなら、これはこのセグメントの送付者が最後に正しく連続して受けたセグメントの一連番号です。 いったん接続を確立すると、いつもこれを送るべきです。 長さはこの分野が32ビットです。
Checksum
チェックサム
This field is a 32-bit checksum of the segment header and
data. The algorithm description below includes two
variables, the checksum accumulator and the checksum
pointer. The checksum accumulator is an actual 32-bit
register in which the checksum is formed. The checksum
pointer is included for purposes of description, to
represent the operation of advancing through the data four
octets (32-bits) at a time. It need not be maintained in a
register by an implementation.
この分野はセグメントヘッダーとデータの32ビットのチェックサムです。 以下でのアルゴリズム記述は2つの変数、チェックサムアキュムレータ、およびチェックサム指針を含んでいます。 チェックサムアキュムレータはチェックサムが形成される実際の32ビットのレジスタです。 チェックサム指針は記述の目的のために含まれていて、aでデータを通して4つの八重奏(32ビット)を進める操作を表すために、調節してください。 それはレジスタで実装によって維持される必要はありません。
1) The checksum pointer is set to zero, to correspond to the
beginning of the area to be checksummed. The checksum
accumulator is also initialized to zero before beginning the
computation of the checksum.
1) ゼロにチェックサム指針がchecksummedされるように領域の始まりに相当するように設定されます。 また、チェックサムの計算を始める前に、チェックサムアキュムレータはゼロに初期化されます。
2) The 32-bit memory word located at the address referenced
by the checksum pointer is added arithmetically to the
checksum accumulator. Any carry propagated out of the
checksum accumulator is ignored. The checksum field itself
is replaced with zeros when being added to the checksum
2) チェックサム指針によって参照をつけられるアドレスに位置する32ビットのメモリ単語はチェックサムアキュムレータに算術で加えられます。 チェックサムアキュムレータから伝播されたどんなキャリーも無視されます。 チェックサムに加えると、チェックサム野原自体をゼロに取り替えます。
Page 34
34ページ
RDP Specification RDP Segments and Formats
RDP仕様RDPセグメントと形式
accumulator.
アキュムレータ。
3) The checksum accumulator is rotated left one bit
position. The checksum pointer is advanced to correspond to
the address of the next 32-bit word in the segment.
3) チェックサムアキュムレータは左の1ビットの回転する位置です。 チェックサム指針は、セグメントで次の32ビットの単語のアドレスに相当するように進められます。
4) Steps 2 and 3 are repeated until the entire segment has
been summed. If a segment contains a number of header and
data octets that is not an integral multiple of 4 octets,
the last octet is padded on the right with zeros to form a
32-bit quantity for computation purposes.
4) 全体のセグメントがまとめられるまで、ステップ2と3は繰り返されます。 セグメントが4つの八重奏の不可欠の倍数でない多くのヘッダーとデータ八重奏を含んでいるなら、最後の八重奏は右でゼロで水増しされて、計算目的のための32ビットの量を形成します。
Variable Header Area
可変ヘッダー領域
This area is used to transmit parameters for the SYN and
EACK segments.
この領域は、SYNとEACKセグメントのためのパラメタを伝えるのに使用されます。
Page 35
35ページ
RFC-908 July 1984
RFC-908 1984年7月
4.3 SYN Segment
4.3 SYNセグメント
The SYN is used to establish a connection and synchronize
sequence numbers between two hosts. The SYN segment also
contains information to inform the remote host of the maximum
number of segments the local RDP is willing to accept and the
maximum segment size it can accept. The SYN may be combined with
an ACK in a segment but is never combined with user data.
SYNは、取引関係を築いて、2人のホストの間の一連番号を同期させるのに使用されます。 また、SYNセグメントは地方のRDPが受け入れても構わないと思っているセグメントの最大数とそれが受け入れることができる最大のセグメントサイズについてリモートホストに知らせる情報を含んでいます。 SYNはセグメントでACKに結合されるかもしれませんが、利用者データに決して結合されません。
4.3.1 SYN Segment Format
4.3.1 SYNセグメント形式
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+---+---------------+
0 |1|0|0|0|0|0|0 1| Header Length |
+-+-+-+-+-+-+---+---------------+
1 | Source Port | Dest. Port |
+---------------+---------------+
2 | Data Length = 0 |
+---------------+---------------+
3 | |
+--- Sequence Number ---+
4 | |
+---------------+---------------+
5 | |
+--- Acknowledgement Number ---+
6 | |
+---------------+---------------+
7 | |
+--- Checksum ---+
8 | |
+---------------+---------------+
9 | Max. # of Outstanding Segments|
+---------------+---------------+
10 | Max. Segment Size |
+-------------------------------+
11 | Options Flag Field |
+---------------+---------------+
0 0 0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+---+---------------+ 0 |1|0|0|0|0|0|0 1| ヘッダ長| +-+-+-+-+-+-+---+---------------+ 1 | ソースポート| Dest。 ポート| +---------------+---------------+ 2 | データの長さ=0| +---------------+---------------+ 3 | | +--- 一連番号---+ 4 | | +---------------+---------------+ 5 | | +--- 承認番号---+ 6 | | +---------------+---------------+ 7 | | +--- チェックサム---+ 8 | | +---------------+---------------+ 9 | マックス。 # 傑出しているセグメントについて| +---------------+---------------+ 10 | マックス。 セグメントサイズ| +-------------------------------+ 11 | オプションは分野に旗を揚げさせます。| +---------------+---------------+
SYN Segment Format
Figure 6
SYNセグメント形式数値6
Page 36
36ページ
RDP Specification RDP Segments and Formats
RDP仕様RDPセグメントと形式
4.3.2 SYN Segment Fields
4.3.2 SYNセグメント分野
Sequence Number
一連番号
Contains the initial sequence number selected for this
connection.
この接続のために選択された初期シーケンス番号を含んでいます。
Acknowledgement Number
承認番号
This field is valid only if the ACK flag is set. In that
case, this field will contain the sequence number of the SYN
segment received from the other RDP.
ACK旗が設定される場合にだけ、この分野は有効です。 その場合、この分野はもう片方のRDPから受け取られたSYNセグメントの一連番号を含むでしょう。
Maximum Number of Outstanding Segments
最大数の傑出しているセグメント
The maximum number of segments that should be sent without
getting an acknowledgement. This is used by the receiver as
a means of flow control. The number is selected during
connection initiation and may not be changed later in the
life of the connection.
承認を得ないで送られるべきであるセグメントの最大数。 これはフロー制御の手段として受信機によって使用されます。 数は、接続開始の間、選択されて、後で接続の寿命で変えられないかもしれません。
Maximum Segment Size
最大のセグメントサイズ
The maximum size segment in octets that the sender should
send. It informs the sender how big the receiver's buffers
are. The specified size includes the length of the IP
header, RDP header, and data. It does not include the
network access layer's header length.
送付者が送るべきである八重奏における最大サイズセグメント。 それは、受信機のバッファがどれくらい大きいかを送付者に知らせます。 指定されたサイズはIPヘッダー、RDPヘッダー、およびデータの長さを含んでいます。 それはネットワークアクセス層のヘッダ長を含んでいません。
Options Flag Field
オプションは分野に旗を揚げさせます。
This field of two octets contains a set of options flags
that specify the set of optional functions that are desired
for this connection. The flags are defined as follows:
2つの八重奏のこの分野はこの接続のために望まれている任意の機能のセットを指定する1セットのオプション旗を含んでいます。 旗は以下の通り定義されます:
Bit # Bit Name Description
噛み付いている#ビット名前記述
0 SDM Sequenced delivery mode.
0 SDM Sequenced配送モード。
The sequenced delivery mode flag specifies whether delivery
of segments to the user is sequenced (delivered in
sequence-number order) or non-sequenced (delivered in
arrival order, regardless of sequence number). A value of 0
specifies non-sequenced delivery of segments, and a value of
1 specifies sequenced delivery.
配列された配送モード旗は、ユーザへのセグメントの配送が配列(系列番号では、注文品を提供する)にされますかそれとも非配列されているかを(到着命令では、一連番号にかかわらず、提供されます)指定します。 0の値はセグメントの非配列された配送を指定します、そして、1の値は配列された配送を指定します。
Page 37
37ページ
RFC-908 July 1984
RFC-908 1984年7月
4.4 ACK Segment
4.4 ACKセグメント
The ACK segment is used to acknowledge in-sequence segments.
It contains both the next send sequence number and the
acknowledgement sequence number in the RDP header. The ACK
segment may be sent as a separate segment, but it should be
combined with data whenever possible. Data segments must always
include the ACK bit and Acknowledgement Number field.
ACKセグメントは、連続してセグメントを承認するのに使用されます。 それは次がRDPヘッダーで一連番号と承認一連番号を送る両方を含んでいます。 別々のセグメントとしてACKセグメントを送るかもしれませんが、可能であるときはいつも、それをデータに結合するべきです。 データ・セグメントはいつもACKビットとAcknowledgement Number分野を含まなければなりません。
4.4.1 ACK Segment Format
4.4.1 ACKセグメント形式
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+---+---------------+
0 |0|1|0|0|0|0|0 1| Header Length |
+-+-+-+-+-+-+---+---------------+
1 | Source Port | Dest. Port |
+---------------+---------------+
2 | Data Length |
+---------------+---------------+
3 | |
+--- Sequence Number ---+
4 | |
+---------------+---------------+
5 | |
+--- Acknowledgement Number ---+
6 | |
+---------------+---------------+
7 | |
+--- Checksum ---+
8 | |
+---------------+---------------+
| |
| Data |
. .
. .
+---------------+---------------+
0 0 0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+---+---------------+ 0 |0|1|0|0|0|0|0 1| ヘッダ長| +-+-+-+-+-+-+---+---------------+ 1 | ソースポート| Dest。 ポート| +---------------+---------------+ 2 | データの長さ| +---------------+---------------+ 3 | | +--- 一連番号---+ 4 | | +---------------+---------------+ 5 | | +--- 承認番号---+ 6 | | +---------------+---------------+ 7 | | +--- チェックサム---+ 8 | | +---------------+---------------+ | | | データ| . . . . +---------------+---------------+
ACK Segment Format
Figure 7
ACKセグメント形式数値7
Page 38
38ページ
RDP Specification RDP Segments and Formats
RDP仕様RDPセグメントと形式
4.4.2 ACK Segment Fields
4.4.2 ACKセグメント分野
Data Length
データの長さ
A non-zero Data Length field indicates that there is data
present in the segment.
非ゼロData Length分野は、セグメントにおける現在のデータがあるのを示します。
Sequence Number
一連番号
The value of the Sequence Number field is advanced to the
next sequence number only if there is data present in the
segment. An ACK segment without data does not use sequence
number space.
セグメントにおける現在のデータがある場合にだけ、Sequence Number分野の値は次の一連番号に達せられます。 データのないACKセグメントは一連番号スペースを使用しません。
Acknowledgement Number
承認番号
The Acknowledgement Number field contains the sequence
number of the last segment received in sequential order.
Acknowledgement Number分野は連続したオーダーに受け取られた最後のセグメントの一連番号を含んでいます。
Page 39
39ページ
RFC-908 July 1984
RFC-908 1984年7月
4.5 Extended ACK Segment
4.5 拡張ACKセグメント
The EACK segment is used to acknowledge segments received
out of sequence. It contains the sequence numbers of one or more
segments received with a correct checksum, but out of sequence.
The EACK is always combined with an ACK in the segment, giving
the sequence number of the last segment received in sequence.
The EACK segment may also include user data.
EACKセグメントは、順序が狂って受け取られたセグメントを承認するのに使用されます。 それは正しいチェックサムにもかかわらず、系列から受け取られた1つ以上のセグメントの一連番号を含んでいます。 EACKはセグメントでACKにいつも結合されます、連続して受け取られた最後のセグメントの一連番号を与えて。 また、EACKセグメントは利用者データを含むかもしれません。
4.5.1 EACK Segment Format
4.5.1 EACKセグメント形式
The EACK segment has the format shown in Figure 8.
EACKセグメントには、図8に示された書式があります。
4.5.2 EACK Segment Fields
4.5.2 EACKセグメント分野
Data Length
データの長さ
A non-zero Data Length field indicates that there is data
present in the segment.
非ゼロData Length分野は、セグメントにおける現在のデータがあるのを示します。
Sequence Number
一連番号
The value of the Sequence Number field is advanced to the
next sequence number only if there is data present in the
segment. An EACK segment without data does not use sequence
number space.
セグメントにおける現在のデータがある場合にだけ、Sequence Number分野の値は次の一連番号に達せられます。 データのないEACKセグメントは一連番号スペースを使用しません。
Acknowledgement Number
承認番号
The Acknowledgement Number field contains the sequence
number of the last segment received in sequential order.
Acknowledgement Number分野は連続したオーダーに受け取られた最後のセグメントの一連番号を含んでいます。
Sequence # Received OK
系列#はOKを受けました。
Each entry is the sequence number of a segment that was
received with a correct checksum, but out of sequence.
各エントリーは正しいチェックサムにもかかわらず、系列から受け取られたセグメントの一連番号です。
Page 40
40ページ
RDP Specification RDP Segments and Formats
RDP仕様RDPセグメントと形式
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+---+---------------+
0 |0|1|1|0|0|0|0 1| Header Length |
+-+-+-+-+-+-+---+---------------+
1 | Source Port | Dest. Port |
+---------------+---------------+
2 | Data Length |
+---------------+---------------+
3 | |
+--- Sequence Number ---|
4 | |
+---------------+---------------+
5 | |
+--- Acknowledgement Number ---+
6 | |
+---------------+---------------+
7 | |
+--- Checksum ---+
8 | |
+---------------+---------------+
9 | |
+--- Sequence # Received OK ---+
10 | |
+---------------+---------------+
11 | |
+--- Sequence # Received OK ---+
12 | |
+---------------+---------------+
: . :
: . :
: . :
+---------------+---------------+
| |
| Data |
| |
+---------------+---------------+
0 0 0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+---+---------------+ 0 |0|1|1|0|0|0|0 1| ヘッダ長| +-+-+-+-+-+-+---+---------------+ 1 | ソース港| Dest。 ポート| +---------------+---------------+ 2 | データの長さ| +---------------+---------------+ 3 | | +--- 一連番号---| 4 | | +---------------+---------------+ 5 | | +--- 承認番号---+ 6 | | +---------------+---------------+ 7 | | +--- チェックサム---+ 8 | | +---------------+---------------+ 9 | | +--- 系列#はOKを受けました。---+ 10 | | +---------------+---------------+ 11 | | +--- 系列#はOKを受けました。---+ 12 | | +---------------+---------------+ : . : : . : : . : +---------------+---------------+ | | | データ| | | +---------------+---------------+
EACK Segment Format
Figure 8
EACKセグメント形式エイト環
Page 41
41ページ
RFC-908 July 1984
RFC-908 1984年7月
4.6 RST Segment
4.6 RSTセグメント
The RST segment is used to close or reset a connection.
Upon receipt of an RST segment, the sender must stop sending and
must abort any unserviced requests. The RST is sent as a
separate segment and does not include any data.
RSTセグメントは、接続を終えるか、またはリセットするのに使用されます。 RSTセグメントを受け取り次第、送付者は、発信するのを止めなければならなくて、どんな非修理された要求も中止しなければなりません。 RSTは別々のセグメントとして送られて、少しのデータも含んでいません。
4.6.1 RST Segment Format
4.6.1 RSTセグメント形式
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+---+---------------+
0 |0|0|0|1|0|0|0 1| Header Length |
+-+-+-+-+-+-+---+---------------+
1 | Source Port | Dest. Port |
+---------------+---------------+
2 | Data Length = 0 |
+---------------+---------------+
3 | |
+--- Sequence Number ---+
4 | |
+---------------+---------------+
5 | |
+--- Acknowledgement Number ---+
6 | |
+---------------+---------------+
7 | |
+--- Checksum ---+
8 | |
+-------------------------------+
0 0 0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+---+---------------+ 0 |0|0|0|1|0|0|0 1| ヘッダ長| +-+-+-+-+-+-+---+---------------+ 1 | ソース港| Dest。 ポート| +---------------+---------------+ 2 | データの長さ=0| +---------------+---------------+ 3 | | +--- 一連番号---+ 4 | | +---------------+---------------+ 5 | | +--- 承認番号---+ 6 | | +---------------+---------------+ 7 | | +--- チェックサム---+ 8 | | +-------------------------------+
RST Segment Format
Figure 9
RSTセグメント形式数値9
Page 42
42ページ
RDP Specification RDP Segments and Formats
RDP仕様RDPセグメントと形式
4.7 NUL Segment
4.7 NULセグメント
The NUL segment is used to determine if the other side of a
connection is still active. When a NUL segment is received, an
RDP implementation must acknowledge the segment if a valid
connection exists and the segment sequence number falls within
the acceptance window. The segment is then discarded. The NUL
may be combined with an ACK in a segment but is never combined
with user data.
NULセグメントは、接続の反対側がまだアクティブであるかどうか決定するのに使用されます。 NULセグメントが受け取られているとき、有効な接続が存在していて、セグメント一連番号が承認ウィンドウの中に下がるなら、RDP実現はセグメントを承認しなければなりません。 そして、セグメントは捨てられます。 NULはセグメントでACKに結合されるかもしれませんが、利用者データに決して結合されません。
4.7.1 NUL segment format
4.7.1 NULセグメント形式
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+---+---------------+
0 |0|0|0|0|1|0|0 1| Header Length |
+-+-+-+-+-+-+---+---------------+
1 | Source Port | Dest. Port |
+---------------+---------------+
2 | Data Length = 0 |
+---------------+---------------+
3 | |
+--- Sequence Number ---+
4 | |
+---------------+---------------+
5 | |
+--- Acknowledgement Number ---+
6 | |
+---------------+---------------+
7 | |
+--- Checksum ---+
8 | |
+-------------------------------+
0 0 0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+---+---------------+ 0 |0|0|0|0|1|0|0 1| ヘッダ長| +-+-+-+-+-+-+---+---------------+ 1 | ソース港| Dest。 ポート| +---------------+---------------+ 2 | データの長さ=0| +---------------+---------------+ 3 | | +--- 一連番号---+ 4 | | +---------------+---------------+ 5 | | +--- 承認番号---+ 6 | | +---------------+---------------+ 7 | | +--- チェックサム---+ 8 | | +-------------------------------+
NUL Segment Format
Figure 10
NULセグメント形式数値10
Page 43
43ページ
RFC-908 July 1984
RFC-908 1984年7月
Page 44
44ページ
RDP Specification Examples of Operation
操作に関するRDP仕様の例
CHAPTER 5
第5章
Examples of Operation
操作に関する例
5.1 Connection Establishment
5.1 コネクション確立
This is an example of a connection being established between
Host A and Host B. Host B has done a passive Open and is in
LISTEN state. Host A does an active Open to establish the
connection.
これは、Host AとHost B.Host Bの間に設立されるのが受け身のオープンをした接続に関する例であり、LISTEN状態にあります。 ホストAは、接続を証明するために活発なオープンをします。
Host A Host B
ホストBを接待してください。
Time State State
時間州の状態
1. CLOSED LISTEN
1. 閉じられて、聴いてください。
2. SYN-SENT <SEQ=100><SYN> --->
2. SYNによって送られた<SEQ=100><SYN>。--->。
3. <--- <SEQ=200><ACK=100><SYN,ACK>
SYN-RCVD
3. <-- <SEQ=200><ACK=100><SYN、ACK>SYN-RCVD
4. OPEN <SEQ=101><ACK=200> ---> OPEN
4. 開いている<SEQ=101><ACK=200>。--->戸外
5. <SEQ=101><ACK=200><Data> --->
5. <SEQ=101><ACK=200><データ>。--->。
6. <--- <SEQ=201><ACK=101>
6. <-- <SEQ=201><ACK=101>。
Page 45
45ページ
RFC-908 July 1984
RFC-908 1984年7月
5.2 Simultaneous Connection Establishment
5.2 同時接続設立
This is an example of two hosts trying to establishing
connections to each other at the same time. Host A sends a SYN
request to Host B at the same time Host B sends a SYN request to
Host A.
これは同時に互いに関係を樹立するのに試みる2人のホストの例です。 ホストAはHost BがSYN要求をHost Aに送る同時代にSYN要求をHost Bに送ります。
Host A Host B
ホストBを接待してください。
Time State State
時間州の状態
1. CLOSED CLOSED
1. 閉じられた状態で、閉じられます。
2. SYN-SENT <SEQ=100><SYN> --->
<--- <SEQ=200><SYN> SYN-SENT
2. SYNによって送られた<SEQ=100><SYN>。---><。--- <SEQ=200><SYN>はSYN発信しました。
3. SYN-RCVD SYN-RCVD
<SEQ=100><ACK=200><SYN,ACK> --->
<--- <SEQ=200><ACK=100><SYN,ACK>
3. SYN-RCVD SYN-RCVD<SEQ=100><ACK=200><SYN、ACK>。---><。--- <SEQ=200><ACK=100><SYN、ACK>。
4. OPEN OPEN
4. 開いている戸外
Page 46
46ページ
RDP Specification Examples of Operation
操作に関するRDP仕様の例
5.3 Lost Segments
5.3 無くなっているセグメント
This is an example of what happens when a segment is lost.
It shows how segments can be acknowledged out of sequence and
that only the missing segment need be retransmitted. Note that
in this and the following examples "EA" stands for "Out of
Sequence Acknowledgement."
これはセグメントが無くなるとき、何が起こるかに関する例です。 それは、どう順序が狂ってセグメントを承認できるか、そして、なくなったセグメントだけが再送されなければならないのを示します。 "EA"というこれと以下の例のそれが「順序が狂って承認」を表すことに注意してください。
Time Host A Host B
時間はホストBを接待します。
1. <SEQ=100><ACK=200><Data> --->
1. <SEQ=100><ACK=200><データ>。--->。
2. <--- <SEQ=201><ACK=100>
2. <-- <SEQ=201><ACK=100>。
3. <SEQ=101><ACK=200><Data> (segment lost)
3. <SEQ=101><ACK=200><データ>。(失われたセグメント)
4.
4.
5. <SEQ=102><ACK=200><Data> --->
5. <SEQ=102><ACK=200><データ>。--->。
6. <-- <SEQ=201><ACK=100><EA=102>
6. <-- <SEQ=201><ACK=100><EA=102>。
7. <SEQ=103><ACK=200><Data> --->
7. <SEQ=103><ACK=200><データ>。--->。
8. <--- <SEQ=201><ACK=100>
<EA=102,103>
8. <-- <SEQ=201><ACK=100><EA=102,103>。
9. <SEQ=101><ACK=200><Data> --->
9. <SEQ=101><ACK=200><データ>。--->。
10. <--- <SEQ=201><ACK=103>
10. <-- <SEQ=201><ACK=103>。
11. <SEQ=104><ACK=200><Data> --->
11. <SEQ=104><ACK=200><データ>。--->。
12. <--- <SEQ=201><ACK=104>
12. <-- <SEQ=201><ACK=104>。
Page 47
47ページ
RFC-908 July 1984
RFC-908 1984年7月
5.4 Segments Received Out of Order
5.4のセグメントが故障していた状態で受信されました。
This an example of segments received out of order. It
further illustrates the use of acknowledging segments out of
order to prevent needless retransmissions.
これ、セグメントに関する例は故障していた状態で受信されました。 それはさらに不必要な「再-トランスミッション」を防ぐためには故障していた状態で承認セグメントの使用を例証します。
Time Host A Host B
時間はホストBを接待します。
1. <SEQ=100><ACK=200><Data> --->
1. <SEQ=100><ACK=200><データ>。--->。
2. <--- <SEQ=201><ACK=100>
2. <-- <SEQ=201><ACK=100>。
3. <SEQ=101><ACK=200><Data> (delayed)
3. <SEQ=101><ACK=200><データ>。(延着します)
4.
4.
5. <SEQ=102><ACK=200><Data> --->
5. <SEQ=102><ACK=200><データ>。--->。
6. <--- <SEQ=201><ACK=100><EA=102>
6. <-- <SEQ=201><ACK=100><EA=102>。
7. <SEQ=103><ACK=200><Data> --->
---> (delayed segment 101 arrives)
7. <SEQ=103><ACK=200><データ>。--->。--->。(遅れたセグメント101は到着します)
8. <--- <SEQ=201><ACK=103>
8. <-- <SEQ=201><ACK=103>。
9. <SEQ=104><ACK=200><Data> --->
9. <SEQ=104><ACK=200><データ>。--->。
10. <--- <SEQ=201><ACK=104>
10. <-- <SEQ=201><ACK=104>。
Page 48
48ページ
RDP Specification Examples of Operation
操作に関するRDP仕様の例
5.5 Communication Over Long Delay Path
5.5 長時間の遅延経路の上のコミュニケーション
This is an example of a data transfer over a long delay
path. In this example, Host A is permitted to have as many as
five unacknowledged segments. The example shows that it is not
necessary to wait for an acknowledgement in order to send
additional data.
これは長時間の遅延経路の上のデータ転送に関する例です。 この例では、Host Aには最大5つの不承認のセグメントがあることが許可されています。 例は、追加データを送るために承認を待つのは必要でないことを示します。
Time Host A Host B
時間はホストBを接待します。
1. <SEQ=100><ACK=200><Data> -1->
2. <SEQ=101><ACK=200><Data> -2->
3. <SEQ=102><ACK=200><Data> -3->
-1-> (received)
4. <-4- <SEQ=201><ACK=100>
5. <SEQ=103><ACK=200><Data> -5->
-2-> (received)
6. <-6- <SEQ=201><ACK=101>
7. <SEQ=104><ACK=200><Data> -7->
-3-> (received)
8. <-8- <SEQ=201><ACK=102>
(received) <-4-
9. <SEQ=105><ACK=200><Data> -9->
-5-> (received)
10. <-10- <SEQ=201><ACK=103>
(received) <-6-
11. <SEQ=106><ACK=200><Data> -11->
-7-> (received)
12. <-12- <SEQ=201><ACK=104>
(received) <-8-
13. -9-> (received)
14. <-13- <SEQ=201><ACK=105>
(received) <-10-
15. -11-> (received)
16. <-14- <SEQ=201><ACK=106>
(received) <-12-
17. (received) <-13-
18. (received) <-14-
1. <SEQ=100><ACK=200><データ>-1>2。 <SEQ=101><ACK=200><データ>-2>3。 <SEQ=102><ACK=200><データ>-3>-1>(受信する)4。 <。4 <SEQ=201><ACK=100>5。 <SEQ=103><ACK=200><データ>-5>-2>(受信する)6。 <。6 <SEQ=201><ACK=101>7。 <SEQ=104><ACK=200><データ>-7>-3>(受信する)8。 <。8 <SEQ=201><ACK=102>(受信する)<-4- 9。 <SEQ=105><ACK=200><データ>-9>-5>(受信する)10。 <。10 <SEQ=201><ACK=103>(受信する)<-6- 11。 <SEQ=106><ACK=200><データ>-11>-7>(受信する)12。 <。12 <SEQ=201><ACK=104>(受信する)<-8- 13。 -9>(受信する)14。 <。13 <SEQ=201><ACK=105>(受信する)<-10- 15。 -11>(受信する)16。 <。14 <SEQ=201><ACK=106>(受信する)<-12- 17。 (受け取られている)です。 <。13- 18. (受け取られている)です。 <。14-
Page 49
49ページ
RFC-908 July 1984
RFC-908 1984年7月
5.6 Communication Over Long Delay Path With Lost Segments
5.6 無くなっているセグメントがある長時間の遅延経路の上のコミュニケーション
This is an example of communication over a long delay path
with a lost segment. It shows that by acknowledging segments out
of sequence, only the lost segment need be retransmitted.
これは無くなっているセグメントがある長時間の遅延経路の上のコミュニケーションに関する例です。 それは、順序が狂ってセグメントを承認することによって、無くなっているセグメントだけが再送されなければならないのを示します。
Time Host A Host B
時間はホストBを接待します。
1. <SEQ=100><ACK=200><Data> -1->
2. <SEQ=101><ACK=200><Data> -2->
3. <SEQ=102><ACK=200><Data> -3->
-1-> (received)
4. <-4- <SEQ=201><ACK=100>
5. <SEQ=103><ACK=200><Data> (segment lost)
-2-> (received)
6. <-5- <SEQ=201><ACK=101>
7. <SEQ=104><ACK=200><Data> -6->
-3-> (received)
8. <-7- <SEQ=201><ACK=102>
(received) <-4-
9. <SEQ=105><ACK=200><Data> -8->
10.
(received) <-5-
11. <SEQ=106><ACK=200><Data> -10->
-6-> (received)
12. <-11- <SEQ=201><ACK=102><EA=104>
(received) <-7-
-8-> (received)
13. <-12- <SEQ=201><ACK=102><EA=104,105>
-10-> (received)
14. <-13- <SEQ=201><ACK=102><EA=104-106>
(received) <-11-
15. <SEQ=103><ACK=200><Data> -14->
(received) <-12-
16. (received) <-13-
-14-> (received)
17. <-15- <SEQ=201><ACK=106>
18.
19. (received) <-15-
1. <SEQ=100><ACK=200><データ>-1>2。 <SEQ=101><ACK=200><データ>-2>3。 <SEQ=102><ACK=200><データ>-3>-1>(受信する)4。 <。4 <SEQ=201><ACK=100>5。 <SEQ=103><ACK=200><Data>(セグメントは損をした)2>(受信する)6。 <。5 <SEQ=201><ACK=101>7。 <SEQ=104><ACK=200><データ>-6>-3>(受信する)8。 <。7 <SEQ=201><ACK=102>(受信する)<-4- 9。 <SEQ=105><ACK=200><データ>-8>10。 (受け取られている)です。 <。5- 11. <SEQ=106><ACK=200><データ>-10>-6>(受信する)12。 <。11 <SEQ=201><ACK=102><EA=104>(受信する)<7- -8>(受信する)13。 <。12 <SEQ=201><ACK=102><EA=104,105>-10>(受信する)14。 <。13 <SEQ=201><ACK=102><EA=104-106>(受信する)<-11- 15。 <SEQ=103><ACK=200><>-14データ>(受信する)<-12- 16。 (受け取られている)です。 <。13- -14->(受信する)17。 <。15 <SEQ=201><ACK=106>18。 19. (受け取られている)です。 <。15-
Page 50
50ページ
RDP Specification Examples of Operation
操作に関するRDP仕様の例
5.7 Detecting a Half-Open Connection on Crash Recovery
5.7 クラッシュリカバリに半開きな接続を検出すること。
This is an example of a host detecting a half-open
connection due to the crash and subsequent restart of the host.
In this example, Host A crashes during a communication session,
then recovers and tries to reopen the connection. During the
reopen attempt, it discovers that a half-open connection still
exists and it then resets the other side. Both sides were in the
OPEN state prior to the crash.
これはホストの速成の、そして、その後の再開による半開きな接続を検出するホストの例です。 この例では、Host Aはコミュニケーションセッションの間、クラッシュして、次に、回復して、接続を再開させようとします。 半開きな接続がまだ存在していると発見します、そして、試みを再開させてください、そして、次に、それは反対側をリセットします。 両側がクラッシュの前にオープン状態にありました。
Host A Host B
ホストBを接待してください。
Time
時間
1. OPEN OPEN
(crash!) <--- <SEQ=200><ACK=100><ACK>
1. 開いている戸外(クラッシュしてください!) <-- <SEQ=200><ACK=100><ACK>。
2. CLOSED OPEN
(recover)
2. 閉じている戸外(回復します)
3. SYN-SENT OPEN
<SEQ=400><SYN> ---> (?)
3. SYNによって送られた開いている<SEQ=400><SYN>。--->。(?)
4. SYN-SENT OPEN
(!) <--- <SEQ=200><ACK=100><ACK>
4. SYNによって送られた開いている(!) <-- <SEQ=200><ACK=100><ACK>。
5. SYN-SENT OPEN
<SEQ=101><RST> ---> (abort)
5. SYNによって送られた開いている<SEQ=101><RST>。--->。(アボート)
6. SYN-SENT CLOSED
6. 閉じられた状態でSYN発信します。
7. SYN-SENT <SEQ=400><SYN> --->
7. SYNによって送られた<SEQ=400><SYN>。--->。
Page 51
51ページ
RFC-908 July 1984
RFC-908 1984年7月
5.8 Detecting a Half-Open Connection from the Active Side
5.8 アクティブ側から半開きな接続を検出すること。
This is another example of detecting a half-open connection
due to the crash and restart of a host involved in a connection.
In this example, host A again crashes and restarts. Host B is
still active and tries to send data to host A. Since host A has
no knowledge of the connection, it rejects the data with an RST
segment, causing host B to reset the connection.
これは接続にかかわるホストのクラッシュと再開による半開きな接続を検出する別の例です。 この例では、ホストAは、再びクラッシュして、再開します。 ホストBは、まだアクティブであり、ホストA.にデータを送ろうとします。SinceホストAには、接続に関する知識が全くなくて、RSTセグメントでデータを拒絶します、ホストBが接続をリセットすることを引き起こして。
Host A Host B
ホストBを接待してください。
Time
時間
1. (crash!) OPEN
1. (クラッシュしてください!) 戸外
2. CLOSED <--- <SEQ=200><ACK=100><Data> OPEN
2. 閉じている<。--- <SEQ=200><ACK=100><データ>は開きます。
3. CLOSED <SEQ=101><RST> ---> (abort)
3. 閉じている<SEQ=101><RST>。--->。(アボート)
4. CLOSED CLOSED
4. 閉じられた状態で、閉じられます。
Page 52
52ページ
RDP Specification Examples of Operation
操作に関するRDP仕様の例
APPENDIX A
付録A
Implementing a Minimal RDP
最小量のRDPを実行します。
It is not necessary to implement the entire RDP
specification to be able to use RDP. For simple applications
such as a loader, where size of the protocol module may be
important, a subset of RDP may be used. For example, an
implementation of RDP for loading may employ the following
restrictions:
RDPを使用できるように全体のRDP仕様を履行するのは必要ではありません。 荷物を積む人などの簡単な塗布のために、RDPの部分集合は使用されるかもしれません。そこでは、プロトコルモジュールのサイズが重要であるかもしれません。 例えば、ローディングのためのRDPの実現は以下の制限を使うかもしれません:
o Only one connection and connection record is supported.
This is the connection used to load the device.
o 1つの接続と接続記録だけが支持されます。 これは装置を積み込むのに使用される接続です。
o A single, well-known port is used as the loader port.
Allocable ports are not implemented.
o シングルであり、ウェルノウンポートは荷物を積む人ポートとして使用されます。 Allocableポートは実行されません。
o Only the passive Open request is implemented. Active Opens
are not supported.
o 受け身のオープン要求だけが実行されます。 アクティブなOpensは支持されません。
o The sequenced delivery option is not supported. Messages
arriving out of order are delivered in the order they
arrive.
o 配列された配送オプションはサポートされません。 故障していた状態で到着するメッセージはオーダーを果たされて、到着するということです。
o If efficiency is less important than protocol size, the
extended acknowledgement feature need not be supported.
o 効率がプロトコルサイズほど重要でないなら、拡張承認機能は支持される必要はありません。
Page 53
53ページ
RFC-908 July 1984
RFC-908 1984年7月
INDEX
インデックス
ACK.......................................... 16, 33, 34, 38
ACK segment format....................................... 38
acknowledgement number field......... 16, 34, 37, 38, 39, 40
byte-stream protocols................................. 4, 14
checksum................................................. 16
checksum field........................................... 34
Close request............................................ 13
Closed state.......................................... 9, 10
CLOSEWAIT................................................ 12
Close-Wait state................................. 10, 11, 13
CLOSE-WAIT timeouts...................................... 29
connection, closing of............................... 13, 42
connection, establishment of...................... 8, 11, 45
connection identifier................................. 7, 33
connection management..................................... 7
connection record..................................... 9, 11
connection state diagram................................. 10
connection states......................................... 8
control flags field...................................... 33
cumulative acknowledgement............................... 16
data communication....................................... 14
data length field................................ 34, 39, 40
datagrams................................................. 6
debugging.............................................. 1, 3
dumping................................................... 3
EACK......................................... 16, 33, 35, 40
EACK segment format...................................... 40
event processing......................................... 20
extended acknowledgement................................. 16
flow control............................................. 17
half-open connection, detection of............... 14, 51, 52
initial sequence number....................... 9, 11, 12, 15
internet protocols........................................ 5
IP................................................ 6, 15, 31
IP header............................................ 31, 37
Listen state................................... 8, 9, 10, 45
loading................................................ 1, 3
maximum segment size..................... 11, 12, 13, 15, 37
maximum unacknowledged segments.............. 11, 12, 17, 37
message fragmentation.................................... 14
non-cumulative acknowledgement........................... 16
ACK… 16、33、34、38ACKセグメント形式… 38 承認ナンバーフィールド… 16、34、37、38、39、40のバイト・ストリームプロトコル… 4、14チェックサム… 16チェックサム分野… 34 要求を終えてください… 13 状態を閉じます… 9、10CLOSEWAIT… 12 近い待ち状態… 10 11 13 CLOSE-WAITタイムアウト… 29接続、閉鎖、… 13、42接続、設立、… 8、11、45接続識別子… 7 33 接続管理… 7接続記録… 9、11接続州のダイヤグラム… 10 接続州… 8 コントロールは分野に旗を揚げさせます… 33 累積している承認… 16データ通信… 14データ長さの分野… 34、39、40個のデータグラム… 6 デバッグします。 1、3ダンピング… 3EACK… 16、33、35、40EACKセグメント形式… 40 イベント処理… 20 承認を広げています… 16フロー制御… 17の半開きな接続、検出、… 14、51、52は一連番号に頭文字をつけます… 9、11、12、15のインターネットプロトコル… 5IP… 6、15、31IPヘッダー… 31、37Listen状態… 8、9、10、45ローディング… 1、3の最大のセグメントサイズ… 11、12、13、15、37の最大の不承認のセグメント… 11、12、17、37メッセージ断片化… 14 非累積している承認… 16
Page 54
54ページ
RDP Specification Examples of Operation
操作に関するRDP仕様の例
NUL.................................................. 33, 43
NUL segment format....................................... 43
Open request.......................................... 8, 17
Open request, active................................... 8, 9
Open request, passive.................................. 8, 9
Open state....................................... 10, 11, 45
options flag field....................................... 37
out-of-sequence acknowledgement.................. 12, 16, 18
ports................................................. 7, 33
ports, well-known......................................... 8
positive acknowledgement............................. 15, 16
RBUF.MAX................................................. 13
RCV.CUR.................................................. 12
RCVDSEQNO................................................ 12
RCV.IRS.................................................. 12
RCV.MAX.................................................. 12
RDP connection........................................... 14
RDP header................................... 14, 16, 32, 37
RDP header length........................................ 33
RDP segment format....................................... 31
reliable communication................................... 15
retransmission of segments....................... 15, 16, 17
retransmission timeout............................... 17, 29
RST.................................................. 33, 42
RST segment.......................................... 13, 52
RST segment format....................................... 42
SBUF.MAX................................................. 12
SDM...................................................... 37
SEG.ACK.................................................. 13
SEG.BMAX................................................. 13
SEG.MAX.................................................. 13
segment arrival events............................... 20, 24
segments................................................. 14
SEG.SEQ.................................................. 13
Send request......................................... 14, 15
sequence number...................................... 12, 15
sequence number acceptance window........................ 18
sequence number field........................ 34, 37, 39, 40
sequenced delivery................................. 3, 4, 37
sequential acknowledgement................................ 4
SND.ISS.................................................. 12
SND.MAX.................................................. 12
SND.NXT.................................................. 11
SND.UNA.................................................. 12
STATE.................................................... 11
SYN.................................. 12, 13, 15, 33, 35, 36
SYN segment........................................... 9, 36
NUL… 33、43NULセグメント形式… 43 要求を開いてください… 8、17オープン要求で、アクティブ… 8、9オープン要求、受動態… 8、9オープン状態… 10 11 45のオプションが分野に旗を揚げさせます… 37 系列で出ている承認… 12、16、18のポート… 7、33のポートで、周知… 8 積極的な承認… 15 16 RBUFマックス… 13 RCV野良犬… 12RCVDSEQNO… 12RCV.IRS… 12 RCVマックス… 12 RDP接続… 14RDPヘッダー… 14、16、32、37RDPヘッダ長… 33 RDPセグメント形式… 31 信頼できるコミュニケーション… 15 セグメントの「再-トランスミッション」… 15、16、17再送タイムアウト… 17、29RST… 33、42RSTセグメント… 13、52RSTセグメント形式… 42 SBUFマックス… 12SDM… 37SEG.ACK… 13SEG.BMAX… 13 SEGマックス… 13 セグメント到着出来事… 20、24のセグメント… 14SEG.SEQ… 13 要求を送ってください… 14、15一連番号… 12、15一連番号承認ウィンドウ… 18一連番号分野… 34、37、39、40は配送を配列しました… 3、4、37の連続した承認… 4SND.ISS… 12 SNDマックス… 12SND.NXT… 11 SNDウナ… 12 状態… 11SYN… 12、13、15、33、35、36SYNセグメント… 9, 36
Page 55
55ページ
RFC-908 July 1984
RFC-908 1984年7月
Syn-Rcvd state........................................ 9, 10
Syn-Sent state........................................ 9, 10
TCP................................................... 4, 14
three-way handshake....................................... 4
user request events.................................. 20, 21
version number field..................................... 33
Syn-Rcvd状態… 9、10のSynによって送られた状態… 9、10TCP… 4、14 3方向ハンドシェイク… 4 ユーザ要求イベント… 20、21バージョンナンバーフィールド… 33
Page 56
56ページ
RDP Specification Examples of Operation
操作に関するRDP仕様の例
Page 57
57ページ
一覧
スポンサーリンク
