RFC983 日本語訳
0983 ISO transport arrives on top of the TCP. D.E. Cass, M.T. Rose. April 1 1986. (Format: TXT=59819 bytes) (Obsoleted by RFC1006) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. E. Cass (NRTC)
Request for Comments: 983 M. T. Rose (NRTC)
April 1986
キャス(NRTC)がコメントのために要求するワーキンググループD.E.をネットワークでつないでください: 983 M.T.は(NRTC)1986年4月に上昇しました。
ISO Transport Services on Top of the TCP
TCPの上のISO輸送サービス
Status of This Memo
このメモの状態
This memo describes a proposed protocol standard for the ARPA Internet community. The intention is that hosts in the ARPA-Internet that choose to implement ISO TSAP services on top of the TCP be expected to adopt and implement this standard. Suggestions for improvement are encouraged. Distribution of this memo is unlimited.
このメモはARPAインターネットコミュニティの提案されたプロトコル標準について説明します。 意志はARPA-インターネットのTCPの上でISO TSAPにサービスを実装するのを選ぶホストがこの規格を採用して、実装すると予想されるということです。 改善提案は奨励されます。 このメモの分配は無制限です。
1. Introduction and Philosophy
1. 序論と哲学
The ARPA Internet community has a well-developed, mature set of transport and internetwork protocols (TCP/IP), which are quite successful in offering network and transport services to end-users. The CCITT and the ISO have defined various session, presentation, and application recommendations which have been adopted by the international community and numerous vendors. To the largest extent possible, it is desirable to offer these higher level services directly in the ARPA Internet, without disrupting existing facilities. This permits users to develop expertise with ISO and CCITT applications which previously were not available in the ARPA Internet. It also permits a more graceful transition strategy from TCP/IP-based networks to ISO-based networks in the medium- and long-term.
ARPAインターネットコミュニティには、よく開発されて、熟している輸送とインターネットワークプロトコル(TCP/IP)があります。(プロトコルはネットワークとエンドユーザへの輸送サービスを提供するのにかなり成功しています)。 CCITTとISOは国際社会によって採用された様々なセッション、プレゼンテーション、およびアプリケーション推薦と多数のベンダーを定義しました。 可能な最も大きい範囲に、直接存在を混乱させることのないARPAインターネットでのこれらのより高い平らなサービスに施設を提供するのは望ましいです。 これは、ユーザが以前にARPAインターネットで利用可能でなかったISOとCCITTアプリケーションで専門知識を伸ばすことを許可します。 また、それは媒体と長期にTCP/IPを拠点とするネットワークからISOを拠点とするネットワークまで、より優雅な変遷戦略を可能にします。
There are two basic approaches which can be taken when "porting" an ISO or CCITT application to a TCP/IP environment. One approach is to port each individual application separately, developing local protocols on top of the TCP. Although this is useful in the short-term (since special-purpose interfaces to the TCP can be developed quickly), it lacks generality.
ISOかCCITTアプリケーションをTCP/IP環境に「移植する」とき取ることができる2つの基本的なアプローチがあります。 1つのアプローチはTCPの上でローカルのプロトコルを開発して、別々にそれぞれの個々のアプリケーションを移植することです。 これは短期的で役に立ちますが(すぐにTCPへの専用インタフェースを開発できるので)、それは一般性を欠いています。
A second approach is based on the observation that both the ARPA Internet protocol suite and the ISO protocol suite are both layered systems (though the former uses layering from a more pragmatic perspective). A key aspect of the layering principle is that of layer-independence. Although this section is redundant for most readers, a slight bit of background material is necessary to introduce this concept.
2番目のアプローチはARPAインターネット・プロトコル群とISOプロトコル群の両方が両方の階層構造(前者は、より実践的な見解からレイヤリングを使用しますが)であるという観測に基づいています。 レイヤリング原則の特徴は層独立のものです。 ほとんどの読者にとって、このセクションは余分ですが、バックグラウンドの材料のわずかなかけらが、この概念を紹介するのに必要です。
Externally, a layer is defined by two definitions:
外部的に、層は2つの定義で定義されます:
a service-offered definition, which describes the services
provided by the layer and the interfaces it provides to access
those services; and,
サービスで提供された定義(それらのサービスにアクセスするために層とインタフェースのそばで提供するなら、それは、サービスについて説明します)。 そして
Cass & Rose [Page 1]
キャスとローズ[1ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
a service-required definitions, which describes the services used
by the layer and the interfaces it uses to access those services.
それがそれらのサービスにアクセスするのに使用するサービスで必要な定義、どれが層によって利用されたサービスについて説明するか、そして、およびインタフェース。
Collectively, all of the entities in the network which co-operate to provide the service are known as the service-provider. Individually, each of these entities is known as a service-peer.
一括して、協力する、サービスを提供するネットワークにおける実体のすべてがサービスプロバイダーとして知られています。 個別に、それぞれのこれらの実体はサービス同輩として知られています。
Internally, a layer is defined by one definition:
本質的に、層は1つの定義で定義されます:
a protocol definition, which describes the rules which each
service-peer uses when communicating with other service-peers.
プロトコル定義。(そのプロトコル定義は他のサービス同輩とコミュニケートするときそれぞれのサービス同輩が使用する規則について説明します)。
Putting all this together, the service-provider uses the protocol and services from the layer below to offer the its service to the layer above. Protocol verification, for instance, deals with proving that this in fact happens (and is also a fertile field for many Ph.D. dissertations in computer science).
このすべてをまとめて、サービスプロバイダーが提供するためには以下の層からプロトコルとサービスを利用する、上の層に対するそのサービス。 検証、例えば事実上、これが起こると立証するとの取引について議定書の中で述べてください(肥よくな分野もコンピュータサイエンスの多くの博士号論文のためのものです)。
The concept of layer-independence quite simply is:
層独立の概念は全く単に以下の通りです。
IF one preserves the services offered by the service-provider
1つがサービスプロバイダーによって提供されたサービスを保持するなら
THEN the service-user is completely naive with respect to the
protocol which the service-peers use
サービス利用者のTHENはサービス同輩が使用するプロトコルに関して完全にナイーブです。
For the purposes of this memo, we will use the layer-independence to define a Transport Service Access Point (TSAP) which appears to be identical to the services and interfaces offered by the ISO/CCITT TSAP (as defined in [ISO-8072]), but we will base the internals of this TSAP on TCP/IP (as defined in [RFC-793,RFC791]), not on the ISO/CCITT transport and network protocols. Hence, ISO/CCITT higher level layers (all session, presentation, and application entities) can operate fully without knowledge of the fact that they are running on a TCP/IP internetwork.
このメモの目的のために、ISO/CCITT TSAPによって提供されたサービスとインタフェースと同じであるように見えるTransport Service Access Point(TSAP)を定義するのに層独立を使用するつもりですが([ISO-8072]で定義されるように)、私たちはこのTSAPのインターナルをISO/CCITT輸送とネットワーク・プロトコルではなく、TCP/IP([RFC-793、RFC791]で定義されるように)に基礎づけるつもりです。 したがって、ISO/CCITTの、より高い平らな層(すべてのセッション、プレゼンテーション、およびアプリケーション実体)はTCP/IPインターネットワークで動いているという事実に関する知識なしで完全に作動できます。
The authors hope that the preceding paragraph will not come as a shock to most readers. However, an ALARMING number of people seem to think that layering is just a way of cutting up a large problem into smaller ones, *simply* for the sake of cutting it up. Although layering tends to introduce modularity into an architecture, and modularity tends to introduce sanity into implementations (both conceptual and physical implementations), modularity, per se, is not the end goal. Flexibility IS.
作者は、先行のパラグラフがショックとしてほとんどの読者に来ないことを望んでいます。 しかしながら、人々のALARMING番号はレイヤリングがただより小さいものに大問題を切り刻む方法であると思うように思えます、**単にそれを切る日本酒が上昇するので。 レイヤリングは、アーキテクチャにモジュール方式を取り入れる傾向があります、そして、モジュール方式は実装(概念的なものと同様に物理的な実装)に正気を取り入れる傾向がありますが、モジュール方式はそういうものとして最終目標ではありません。 柔軟性はそうです。
Cass & Rose [Page 2]
キャスとローズ[2ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
2. Motivation
2. 動機
In migrating from the use of TCP/IP to the ISO protocols, there are several strategies that one might undertake. This memo was written with one particular strategy in mind.
TCP/IPの使用からISOプロトコルまで移行するのにおいて、1つが引き受けるかもしれないいくつかの戦略があります。 このメモは念頭に1つの特定の戦略で書かれました。
The particular migration strategy which this memo uses is based on the notion of gatewaying between the TCP/IP and ISO protocol suites at the transport layer. There are two strong arguments for this approach:
このメモが使用する特定の移行戦略はトランスポート層のTCP/IPとISOプロトコル群の間でgatewayingするという概念に基づいています。 このアプローチのための2つの強い議論があります:
a. Experience teaches us that it takes just as long to get good
implementations of the lower level protocols as it takes to get
good implementations of the higher level ones. In particular, it
has been observed that there is still a lot of work being done at
the ISO network and transport layers. As a result,
implementations of protocols above these layers are not being
aggressively pursued. Thus, something must be done "now" to
provide a medium in which the higher level protocols can be
developed. Since TCP/IP is mature, and essentially provides
identical functionality, it is an ideal medium to support this
development.
a。 経験は、それが高い平らなものの良い実装を得るにはかかるとき下のレベルプロトコルの良い実装を得るにはちょうど同じくらい長い間かかることを私たちに教えます。 特に、ISOネットワークとトランスポート層に行われる多くの仕事がまだあるのが観測されました。 その結果、これらの層を超えたプロトコルの実装は積極的に追求されていません。 したがって、「現在、」より高い平らなプロトコルを開発できる媒体を供給するために何かをしなければなりません。 TCP/IPが熟して、本質的には同じ機能性を提供するので、この開発をサポートするのは、理想的な媒体です。
b. Implementation of gateways at the IP and ISO IP layers are
probably not of general use in the long term. In effect, this
would require each Internet host to support both TP4 and TCP. As
such, a better strategy is to implement a graceful migration path
from TCP/IP to ISO protocols for the ARPA Internet when the ISO
protocols have matured sufficiently.
b。 IPのゲートウェイの実装とISO IP層は長期でたぶんどんな一般的使用のものではありません。 事実上、これは、各インターネット・ホストがTP4とTCPの両方をサポートするのを必要とするでしょう。 そういうものとして、より良い戦略はISOプロトコルが十分熟したとき、TCP/IPからISOプロトコルまでARPAインターネットに優雅な移行パスを実装することです。
Both of these arguments indicate that gatewaying should occur at or above the transport layer service access point. Further, the first argument suggests that the best approach is to perform the gatewaying exactly AT the transport service access point to maximize the number of ISO layers which can be developed.
これらの議論の両方が、gatewayingがサービスアクセスポイントにおいて、または、トランスポート層サービスアクセスポイントの上に起こるべきであるのを示します。 さらに、最初の議論が、最も良いアプローチがまさにgatewayingを実行することであることを示す、AT、発生できるISO層の数を最大にする輸送サービスアクセスポイント。
NOTE: This memo does not intend to act as a migration or
intercept document. It is intended ONLY to meet the needs
discussed above. However, it would not be unexpected that the
protocol described in this memo might form part of an overall
transition plan. The description of such a plan however is
COMPLETELY beyond the scope of this memo.
以下に注意してください。 このメモは移行かインタセプトドキュメントとして機能しないつもりです。 上で議論した需要を満たすのが意図しているだけです。 しかしながら、このメモで説明されたプロトコルが総合的な変遷プランの一部を形成するのは、予期していなくないでしょう。 しかしながら、そのようなプランの記述はこのメモの範囲を超えたCOMPLETELYです。
Finally, in general, building gateways between other layers in the TCP/IP and ISO protocol suites is problematic, at best.
最終的で、一般に、TCP/IPとISOの他の層の間のゲートウェイにプロトコル群を建設するのはせいぜい問題が多いです。
To summarize: the primary motivation for the standard described in
まとめるために: 中で説明された規格に関するプライマリ動機
Cass & Rose [Page 3]
キャスとローズ[3ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
this memo is to facilitate the process of gaining experience with higher-level ISO protocols (session, presentation, and application). The stability and maturity of TCP/IP are ideal for providing solid transport services independent of actual implementation.
このメモは、よりハイレベルのISOプロトコル(セッション、プレゼンテーション、およびアプリケーション)と共に経験を積むプロセスを容易にすることです。 実際の実装の如何にかかわらず確実な輸送サービスを提供するのに、TCP/IPの安定性と円熟は理想的です。
3. The Model
3. モデル
The [ISO-8072] standard describes the ISO transport service definition, henceforth called TP.
TPは、今後は、[ISO-8072]規格がISO輸送サービス定義について説明すると呼びました。
ASIDE: This memo references the ISO specifications rather than
the CCITT recommendations. The differences between these parallel
standards are quite small, and can be ignored, with respect to
this memo, without loss of generality. To provide the reader with
the relationships:
傍らに: このメモはCCITT推薦よりむしろISO仕様に参照をつけます。 これらの並行本位制度の違いは、かなり小さく、無視できます、このメモに関して、一般性の喪失なしで。 関係を読者に提供するために:
Transport service [ISO-8072] [X.214]
Transport protocol [ISO-8073] [X.224]
Session protocol [ISO-8327] [X.225]
輸送サービス[ISO-8072][X.214]トランスポート・プロトコル[ISO-8073][X.224]セッションプロトコル[ISO-8327][X.225]
The ISO transport service definition describes the services offered by the TS-provider (transport service) and the interfaces used to access those services. This memo focuses on how the ARPA Transmission Control Protocol (TCP) [RFC-793] can be used to offer the services and provide the interfaces.
ISO輸送サービス定義はTS-プロバイダー(輸送サービス)によって提供されたサービスとそれらのサービスにアクセスするのに使用されるインタフェースについて説明します。 このメモはサービスを提供して、インタフェースを提供するのに、どう、ARPA通信制御プロトコル(TCP)[RFC-793]を使用できるかに焦点を合わせます。
+-------------+ +-------------+
| TS-user | | TS-user |
+-------------+ +-------------+
| |
| TSAP interface TSAP interface |
| [ISO-8072] |
| |
+------------+ ISO Transport Services on the TCP +------------+
| client |----------------------------------------| server |
+------------+ (this memo) +------------+
| |
| TCP interface TCP interface |
| [RFC-793] |
| |
+-------------+ +-------------+ | tユーザ| | tユーザ| +-------------+ +-------------+ | | | TSAPインタフェースTSAPインタフェース| | [ISO-8072]| | | +------------+ TCP+におけるISO輸送サービス------------+ | クライアント|----------------------------------------| サーバ| +------------+ (このメモ)+------------+ | | | TCPインタフェースTCPインタフェース| | [RFC-793]| | |
For expository purposes, the following abbreviations are used:
解説の目的のために、以下の略語は使用されています:
TS-peer a process which implements the protocol
described by this memo
このメモで説明されたプロトコルを実装するTS-同輩aプロセス
Cass & Rose [Page 4]
キャスとローズ[4ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
TS-user a process talking using the services of a
TS-peer
TS-ユーザはTS-同輩のサービスを利用することで話すプロセスです。
TS-provider the black-box entity implementing the protocol
described by this memo
TS-プロバイダーはこのメモで説明されたプロトコルを実装するブラックボックス実体です。
For the purposes of this memo, which describes version 1 of the TSAP protocol, all aspects of [ISO-8072] are supported with one exception:
TSAPプロトコルのバージョン1について説明するこのメモの目的のために、[ISO-8072]の全面はただ1つを例外としてサポートされます:
Quality of Service parameters
Serviceパラメタの品質
In the spirit of CCITT, this is left "for further study". Version 2 of the TSAP protocol will most likely support the QOS parameters for TP by mapping these onto various TCP parameters.
CCITTの精神では、これは「さらなる研究」に残されます。 TSAPプロトコルのバージョン2は、たぶんQOSがTPのためのパラメタであると様々なTCPパラメタにこれらを写像することによって、サポートするでしょう。
Since TP supports the notion of a session port (termed a TSAP ID), but the list of reserved ISO TSAP IDs is not clearly defined at this time, this memo takes the philosophy of isolating the TCP port space from the TSAP ID space and uses a single TCP port. This memo reserves TCP port 102 for this purpose. This protocol manages its own TSAP ID space independent of the TCP. Appendix A of this memo lists reserved TSAP IDs for version 1 of this TSAP protocol. It is expected that future editions of the "Assigned Numbers" document [RFC-960] will contain updates to this list. (Interested readers are encouraged to read [ISO-8073] and try to figure out exactly what a TSAP ID is.)
TPがセッションポート(TSAP IDと呼ばれる)の概念をサポートしますが、予約されたISO TSAP IDのリストがこのとき明確に定義されないので、このメモは、TSAP IDスペースからTCPポートスペースを隔離する哲学を取って、単一のTCPポートを使用します。 このメモ蓄えのTCPはこのために102を移植します。 このプロトコルはTCPの如何にかかわらずそれ自身のTSAP IDスペースを管理します。 このメモの付録AはこのTSAPプロトコルのバージョン1のために予約されたTSAP IDを記載します。 「規定番号」というドキュメント[RFC-960]の将来の版がこのリストにアップデートを含むと予想されます。 (興味のある読者は、[ISO-8073]を読んで、TSAP IDがまさに何であるかを理解しようとするよう奨励されます。)
Finally, the ISO TSAP is fundamentally symmetric in behavior. There is no underlying client/server model. Instead of a server listening on a well-known port, when a connection is established, the TS-provider generates an INDICATION event which, presumably the TS-user catches and acts upon. Although this might be implemented by having a server "listen" by hanging on the INDICATION event, from the perspective of the ISO TSAP, all TS-users just sit around in the IDLE state until they either generate a REQUEST or accept an INDICATION.
最終的に、ISO TSAPは振舞いで基本的に左右対称です。 基本的なクライアント/サーバモデルが全くありません。 接続が確立されるときウェルノウンポートで聴かれるサーバの代わりにTS-プロバイダーがINDICATIONイベントを生成する、どれ、おそらく、TS-ユーザは、捕らえて、作用するか。 サーバがINDICATIONイベントに掛かることによって「聴かれること」を持っていることによって、これは実装されるかもしれませんが、ISO TSAPの見解から、彼らがREQUESTを生成するか、またはINDICATIONを受け入れるまで、すべてのTS-ユーザがIDLE状態でただ何もせずに座っています。
Cass & Rose [Page 5]
キャスとローズ[5ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
4. The Primitives
4. 基関数
The protocol assumes that the TCP [RFC-793] offers the following service primitives:
プロトコルは、TCP[RFC-793]が以下のサービス基関数を提供すると仮定します:
Events
イベント
connected - open succeeded (either ACTIVE or PASSIVE)
接続、--戸外が成功した(アクティブであるか受動)です。
connect fails - ACTIVE open failed
やり損ないを接続してください--ACTIVE戸外は失敗しました。
data ready - data can be read from the connection
データ、準備して、接続からデータを読むことができます。
errored - the connection has errored and is now closed
erroredする、--接続がerroredして、現在閉店する
closed - an orderly disconnection has started
閉鎖、--規則的な断線が始めであった
Actions
動作
listen on port - PASSIVE open on the given port
ポートの上で聴いてください--PASSIVEは与えられたポートの上で開きます。
open port - ACTIVE open to the given port
開港--与えられたポートに開かれているACTIVE
read data - data is read from the connection
データを読んでください--データは接続から読まれます。
send data - data is sent on the connection
送信データ--データを接続に送ります。
close - the connection is closed (pending data is sent)
閉じてください--接続は閉じられます。(未定のデータを送ります)
The protocol offers the following service primitives, as defined in [ISO-8072], to the TS-user:
プロトコルは[ISO-8072]でTS-ユーザと定義されるように以下のサービス基関数を提供します:
Events
イベント
T-CONNECT.INDICATION
T-CONNECT.INDICATION
- a TS-user (server) is notified that connection establishment
is in progress
- TS-ユーザ(サーバ)はコネクション確立が進行しているように通知されます。
T-DISCONNECT.INDICATION
T-DISCONNECT.INDICATION
- a TS-user is notified that the connection is closed
- TS-ユーザは接続が閉じられるように通知されます。
T-CONNECT.CONFIRMATION
T-CONNECT.CONFIRMATION
- a TS-user (client) is notified that the connection has been
established
- TS-ユーザ(クライアント)は接続が確立されたことに通知されます。
Cass & Rose [Page 6]
キャスとローズ[6ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
T-DATA.INDICATION
T-DATA.INDICATION
- a TS-user is notified that data can be read from the
connection
- TS-ユーザは接続からデータを読むことができるように通知されます。
T-EXPEDITED DATA.INDICATION
Tで速められたDATA.INDICATION
- a TS-user is notified that "expedited" data can be read from
the connection
- TS-ユーザは接続から「速められた」データを読むことができるように通知されます。
Actions
動作
T-CONNECT.RESPONSE
T-CONNECT.RESPONSE
- a TS-user (server) indicates that it will honor the request
- TS-ユーザ(サーバ)は、要求を光栄に思うのを示します。
T-DISCONNECT.REQUEST
T-DISCONNECT.REQUEST
- a TS-user indicates that the connection is to be closed
- TS-ユーザは、接続が閉店していることになっているのを示します。
T-CONNECT.REQUEST
T-CONNECT.REQUEST
- a TS-user (client) indicates that it wants to establish a
connection
- TS-ユーザ(クライアント)は、取引関係を築きたがっているのを示します。
T-DATA.REQUEST
T-DATA.REQUEST
- a TS-user sends data
- TS-ユーザはデータを送ります。
T-EXPEDITED DATA.REQUEST
Tで速められたDATA.REQUEST
- a TS-user sends "expedited" data
- TS-ユーザは「速められた」データを送ります。
Cass & Rose [Page 7]
キャスとローズ[7ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
5. The Protocol
5. プロトコル
It is the goal of this memo to offer a TP interface on top of the TCP. Fortunately, the TCP does just about everything that TS-provider offers to the TS-user, so the hard parts of the transport layer (e.g., three-way handshakes, choice of ISS, windowing, multiplexing, ad infinitum) are all taken care of by the TCP.
それはTCPの上でTPインタフェースを提供するこのメモの目標です。 幸い、TCPがほとんどTS-プロバイダーがTS-ユーザに提供するすべてをするので、トランスポート層(例えば、3方向ハンドシェイク、ISS、ウインドーの選択が永久に多重送信されて)の固い一部がすべてTCPによって世話をされます。
Despite the symmetry of TP, it is useful to consider the protocol with the perspective of a client/server model.
TPの対称にもかかわらず、クライアント/サーバモデルの見解があるプロトコルを考えるのは役に立ちます。
The information exchanged between TSAP-peers is in the form of packets termed "TPKT"s. The format of these packets is described in the next section. For the purposes of the description below, a TPKT has a code which is one of:
TSAP-同輩の間で交換された情報が呼ばれたパケットの形にある、「TPKT「s。」 これらのパケットの形式は次のセクションで説明されます。 TPKTには、以下の記述の目的のために、以下について1であるコードがあります。
CR - request connection
CC - confirm connection
DR - request disconnection
DT - data
ED - expedited data
CR--接続CCを要求してください--接続DRを確認してください--断線DT(データED)がデータを速めたよう要求してください。
A TSAP server begins by LISTENing on TCP port 102. When a TSAP client successfully connects to this port, the protocol begins.
TSAPサーバはTCPポート102の上のLISTENingで始まります。 TSAPクライアントが首尾よくこのポートに接続するとき、プロトコルは始まります。
A client decides to connect to the port when a TS-user issues a T-CONNECT.REQUEST action. This action specifies the TSAP ID of the remote TS-user, whether expedited data is to be supported, and (optionally) some initial TS-user data. The client consults the TSAP ID given to ascertain the IP address of the server. If the expedited data option was requested, the client opens a passive TCP port, in non-blocking mode, noting the port number. This TCP port is termed the "expedited port". The client then tries to open a TCP connection to the server on port 102. If not successful, the client fires T-DISCONNECT.INDICATION for the TS-user specifying the reason for failure (and, closes the expedited port, if any). If successful, the client sends a TPKT with code CR containing:
クライアントは、TS-ユーザがT-CONNECT.REQUEST動作を発行するとき、ポートに接続すると決めます。 この動作はリモートTS-ユーザのTSAP IDを指定します、速められたデータがサポートされることであり、(任意に)或るものがTS-利用者データに頭文字をつけるか否かに関係なく。 クライアントはサーバのIPアドレスを確かめるために与えられているTSAP IDに相談します。速められたデータオプションが要求されたなら、クライアントは受け身のTCPポートを開けます、非ブロッキングモードで、ポートナンバーに注意して。 このTCPポートは「速められたポート」と呼ばれます。 そして、クライアントはポート102の上のサーバにTCP接続を開こうとします。 そして、うまくいきます、そうでなければ、クライアントがTS-ユーザのために失敗の理由を指定しながらT-DISCONNECT.INDICATIONを首にする、(速めるのがもしあれば移植する閉鎖) うまくいくなら、クライアントはコードCR含有と共にTPKTを送ります:
- the TSAP ID of the TS-user on the client's host (the "caller")
- the TSAP ID of the TS-user that the client wants to talk to
(the "called")
- if the expedited data option was requested, the TSAP ID of the
expedited port for the client's host
- any TS-user data from the T-CONNECT.REQUEST
- クライアントのホスト(「訪問者」)の上のTS-ユーザのTSAP ID--速められたデータオプションが要求されたならクライアントが(「呼ぶ」)と話したがっているTS-ユーザのTSAP ID、クライアントのホストのための速められたポートのTSAP ID--T-CONNECT.REQUESTからのどんなTS-利用者データ
The client now awaits a response.
クライアントは現在、応答を待ちます。
Cass & Rose [Page 8]
キャスとローズ[8ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
The server, upon receipt of the TPKT, validates the contents of the TPKT (checking the version number, verifying that the code is CR, and so forth). If the packet is invalid, the server sends a TPKT with code DR specifying "PROTOCOL ERROR", closes the TCP connection, and goes back to the LISTEN state.
TPKTを受け取り次第、サーバはTPKTのコンテンツを有効にします(コードがCRなどであることを確かめて、バージョン番号をチェックして)。 パケットが無効であるなら、サーバがコードDRが「プロトコル誤り」を指定しているa TPKTを送って、TCP接続を終えて、戻るようになる、状態を聴いてください。
If the packet is valid, the server examines the TSAP ID that the remote TS-user wants to communicate with. If the TS-user specified can be located and started (e.g., the appropriate program which implements the indicated protocol is present), then the server starts this TS-user by firing T-CONNECT.INDICATION. Otherwise, the server sends a TPKT with code DR specifying "SESSION ENTITY NOT ATTACHED TO TSAP" or "REMOTE TRANSPORT ENTITY CONGESTED AT CONNECT REQUEST TIME" as appropriate, closes the TCP connection, and goes back to the LISTEN state.
パケットが有効であるなら、サーバはリモートTS-ユーザがコミュニケートしたがっているTSAP IDを調べます。 指定されたTS-ユーザを見つけていて、始めることができるなら(例えば、示されたプロトコルを実装する適切なプログラムは存在しています)、サーバは、T-CONNECT.INDICATIONを首にすることによって、このTS-ユーザを始めます。 さもなければ、サーバが「セッション実体NOTはTSAPに付いた」か、適切な同じくらい「充血するリモート輸送実体は要求時間を同じくらい接続する」閉鎖を指定するコードDRとのTCP接続のTPKTを送って、戻る、状態を聴いてください。
The server now waits for a T-CONNECT.RESPONSE or T-DISCONNECT.REQUEST from the TS-user it started. if the latter is given, the server sends a TPKT with code DR containing the reason for the disconnect as supplied by the TS-user.
サーバは現在、それが始めたTS-ユーザからT-CONNECT.RESPONSEかT-DISCONNECT.REQUESTを待ちます。後者を与えるなら、サーバはTS-ユーザによって供給されるようにコードDRが分離の理由を含んでいるTPKTを送ります。
The server then closes the TCP connection and goes back to the LISTEN state.
サーバは、次に、TCP接続を終えて、LISTEN状態に戻ります。
Instead, if T-CONNECT.RESPONSE is given, the server sees if an expedited port was specified in the connection request. If so, the server opens a second TCP connection and connects to the specified port. If the connection fails, the server sends a TPKT with code DR specifying "CONNECTION NEGOTIATION FAILED", closes the TCP connection, and goes back to the LISTEN state. If the connection succeeded, the server notes the local port number used to connect to the expedited port.
代わりに、T-CONNECT.RESPONSEを与えるなら、サーバは、速められたポートが接続要求で指定されたかどうかわかります。 そうだとすれば、サーバは、2番目のTCP接続を開いて、指定されたポートに接続します。 接続が失敗するなら、サーバがコードDRが「交渉が失敗した接続」を指定しているa TPKTを送って、TCP接続を終えて、戻るようになる、状態を聴いてください。 接続が成功したなら、サーバは、地方のポートナンバーが速められたポートに接続していたことに注意します。
If an expedited port was not specified in the TPKT with code CR, and the server's TS-user indicates that it wants to use expedited data, then the server sends a TPKT with code DR specifying "CONNECTION NEGOTIATION FAILED", fires T-DISCONNECT.INDICATION with this error to the TS-user, closes the TCP connection, and goes back to the LISTEN state.
速められたポートがコードCRと共にTPKTで指定されないで、サーバのTS-ユーザが、閉鎖のtユーザ、TCP接続、およびゴエスへのこの誤りがあるT-DISCONNECT.INDICATIONに戻っていて速められたデータ(コードDRが「交渉が失敗した接続」を指定している状態でサーバがTPKTを送るその時)が発火させる使用に欲しいのを示す、状態を聴いてください。
The server now sends a TPKT with code CC containing:
サーバは現在、コードCC含有と共にTPKTを送ります:
- the TSAP ID of the TS-user responding to the connection
(usually the "called")
- if an expedited port was specified in the TPKT with code CR,
- 速められたポートがコードCRと共にTPKTで指定されたなら接続(通常「呼ぶ」)に応じているTS-ユーザのTSAP ID
Cass & Rose [Page 9]
キャスとローズ[9ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
the TSAP ID of the port number on the server's host that was
used to connect to the expedited port
- any TS-user data from the T-CONNECT.RESPONSE
速められたポートに接続するのに使用されたサーバのホストのポートナンバーのTSAP ID--T-CONNECT.RESPONSEからのどんなTS-利用者データ
After sending the TPKT, the server enters the SYMMETRIC PEER state.
TPKTを送った後に、サーバはSYMMETRIC PEER状態に入ります。
The client, upon receipt of the TPKT, validates the contents of the TPKT (checking the version number, verifying that the code is CC or DR, and so forth). If the packet is invalid, the client sends a TPKT with code DR specifying "PROTOCOL ERROR", fires T-DISCONNECT.INDICATION with this error to the TS-user, and closes the TCP connection (and the expedited port, if any).
TPKTを受け取り次第、クライアントはTPKTのコンテンツを有効にします(コードがCCかDRなどであることを確かめて、バージョン番号をチェックして)。 そして、パケットが無効であるなら、クライアントがコードDRが「プロトコル誤り」を指定しているTPKTを送って、この誤りでtユーザにT-DISCONNECT.INDICATIONを首にして、TCP接続を終える、(速められたポートどんなであるも
If the packet's code is DR, the client fires T-DISCONNECT.INDICATION with the reason given in the TPKT to the TS-user, and closes the TCP connection (and the expedited port, if any).
そして、クライアントがパケットのコードがDRであるなら、理由がTPKTでTS-ユーザにあげられている状態でT-DISCONNECT.INDICATIONを首にして、TCP接続を終える、(速められたポートどんなであるも
If the packet's code is CC, the client checks if an expedited port was specified and that a connection is waiting on the expedited port. If not, a protocol error has occurred, a TPKT with code DR is returned, T-DISCONNECT.INDICATION is fired, and so on. Otherwise, the client checks the remote address that connected to the expedited port. If it differs from the port listed in the TPKT with code CC, a protocol error has occurred. Otherwise, all is well, two TCP connections have been established, one for all TPKTs except expedited data, and the second for the exclusive use of expedited data.
クライアントは、パケットのコードがCCであるなら、速められたポートが指定されたかどうかチェックします、そして、接続は速められたポートで待っています。 T-DISCONNECT.INDICATIONはそうでなければ、プロトコル誤りが発生して、コードDRとTPKTを返して、発火していて、とてもオンです。 さもなければ、クライアントは速められたポートに接続したリモートアドレスをチェックします。 TPKTにコードCCで記載されたポートと異なっているなら、プロトコル誤りは発生しました。 2つのTCP接続が、さもなければ、すべてが順調であり、確立していて速められたデータ以外のすべてのTPKTsのためのものと、速められたデータの専用のための秒です。
The client now fires T-CONNECT.CONFIRMATION, and enters the SYMMETRIC PEER state.
クライアントは、今T-CONNECT.CONFIRMATIONを首にして、SYMMETRIC PEER状態に入れます。
Once both sides have reached the SYMMETRIC PEER state, the protocol is completely symmetric, the notion of client/server is lost. Both TS-peers act in the following fashion:
両側がいったんSYMMETRIC PEER状態に達すると、プロトコルが完全に左右対称である、クライアント/サーバの概念は無くなっています。 両方のTS-同輩は以下のファッションで行動します:
If the TCP indicates that data can be read, the TS-peer, upon receipt of the TPKT, validates the contents. If the packet is invalid, the TS-peer sends a TPKT with code DR specifying "PROTOCOL ERROR", fires T-DISCONNECT.INDICATION with this error to the TS-user, and closes the TCP connection (and expedited data connection, if any). If the TS-peer was the server, it goes back to the LISTEN state.
TCPが、データを読むことができるのを示すなら、TPKTを受け取り次第、TS-同輩はコンテンツを有効にします。 パケットが無効であるなら、TS-同輩は、コードDRが「プロトコル誤り」を指定しているTPKTを送って、この誤りでtユーザにT-DISCONNECT.INDICATIONを首にして、TCP接続(そして、もしあればデータ接続を速める)を終えます。 TS-同輩がサーバであったなら、それはLISTEN状態に戻ります。
NOTE: If the expedited data option was requested, then there are
two TCP connections that can supply data for reading. The
dialogue below assumes that only ED TPKTs are read from the
expedited data connection. For simplicity's sake, when reading
from TCP the relation between connections and TPKTs is unimportant
and this memo URGES all implementations to be very lenient in this
以下に注意してください。 速められたデータオプションが要求されたなら、読書するために資料を提供できる2つのTCP接続があります。 以下での対話は、ED TPKTsだけが速められたデータ接続から読まれると仮定します。 TCPから読むとき、接続とTPKTsとの関係は重要ではありません、そして、簡単さのために、このメモURGESはこれで非常に寛大であるすべての実装が重要ではありません。
Cass & Rose [Page 10]
キャスとローズ[10ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
regard. When writing to TCP, implementations should use the
expedited data connection only to send TPKTs with code ED.
Section 7 of this memo discusses the handling of expedited data in
greater detail.
関係。 TCPに書くとき、実装は速められたデータ接続を使用するべきですが、コードEDとTPKTsを送ります。 このメモのセクション7は、よりすばらしい詳細における速められたデータの取り扱いについて論じます。
If the packet's code is DR, the TS-peer fires T-DISCONNECT.INDICATION with the reason given in the TPKT to the TS-user, and closes the TCP connection (and expedited data connection, if any). If the TS-peer was the server, it goes back to the LISTEN state.
パケットのコードがDRであるなら、TS-同輩は、理由がTPKTでTS-ユーザにあげられている状態でT-DISCONNECT.INDICATIONを首にして、TCP接続(そして、もしあればデータ接続を速める)を終えます。 TS-同輩がサーバであったなら、それはLISTEN状態に戻ります。
If the packet's code is ED or DT, the TS-peer fires T-DATA.INDICATION or T-EXPEDITED DATA.INDICATION as appropriate with the enclosed user data for the TS-user. It then goes back to the SYMMETRIC PEER state.
パケットのコードがEDかDTであるなら、TS-同輩はTS-ユーザのために同封の利用者データで適宜T-DATA.INDICATIONかT-EXPEDITED DATA.INDICATIONを首にします。 そして、それはSYMMETRIC PEER状態に戻ります。
If the packet is invalid, the TS-peer sends a TPKT with code DR specifying "PROTOCOL ERROR", fires T-DISCONNECT.INDICATION with this error to the TS-user, and closes the TCP connection (and expedited data connection, if any). If the TS-peer was the server, it goes back to the LISTEN state.
パケットが無効であるなら、TS-同輩は、コードDRが「プロトコル誤り」を指定しているTPKTを送って、この誤りでtユーザにT-DISCONNECT.INDICATIONを首にして、TCP接続(そして、もしあればデータ接続を速める)を終えます。 TS-同輩がサーバであったなら、それはLISTEN状態に戻ります。
If the TCP indicates that an error has occurred and the connection has closed, then the TS-peer fires T-DISCONNECT.INDICATION to the TS-user specifying the reason for the failure. If the expedited data connection, if any, is still open, it is closed. If the TS-peer was the server, it goes back to the LISTEN state.
TCPが、誤りが発生して、接続が閉じたのを示すなら、TS-同輩は、失敗の理由を指定しながら、TS-ユーザにT-DISCONNECT.INDICATIONを首にします。 もしあれば速められたデータ接続がまだオープンであるなら、閉じられます。 TS-同輩がサーバであったなら、それはLISTEN状態に戻ります。
If the TS-user issues a T-DATA.REQUEST or T-EXPEDITED DATA.REQUEST action, the TS-peer sends a TPKT with code DT or ED containing the TS-user data. It then goes back to the SYMMETRIC PEER state.
TS-ユーザがT-DATA.REQUESTかT-EXPEDITED DATA.REQUESTに動作を発行するなら、TS-同輩はコードDTかEDがTS-利用者データを含んでいるTPKTを送ります。 そして、それはSYMMETRIC PEER状態に戻ります。
If the TS-user issues a T-DISCONNECT.REQUEST action, the TS-peer sends a TPKT with code DR containing the reason for the disconnect as supplied by the TS-user. The TS-peer then closes the TCP connection, (and expedited data connection, if any). If the TS-peer was the server, it goes back to the LISTEN state.
TS-ユーザがT-DISCONNECT.REQUEST動作を発行するなら、TS-同輩はTS-ユーザによって供給されるようにコードDRが分離の理由を含んでいるTPKTを送ります。 次に、TS-同輩がTCP接続を終える、(そして、もしあればデータ接続を速めます。) TS-同輩がサーバであったなら、それはLISTEN状態に戻ります。
In terms of (augmented) state tables, the protocol can be explained as follows. The server starts in state S0, the client starts in state C0. "TCP:" refers to an event or action from the TCP service, "SS:" refers to an event or action from the TS-user (e.g., the ISO session service [ISO-8327]).
(増大します)ステートテーブルに関して、以下の通りプロトコルについて説明できます。 サーバは州のS0で始まって、クライアントは州のC0で始めます。 「TCP:」 TCPサービスからイベントか動作について言及する、「SS:」 TS-ユーザ(例えば、ISOセッション・サービス[ISO-8327])からイベントか動作について言及します。
Cass & Rose [Page 11]
キャスとローズ[11ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
S E R V E R S T A T E S
S E R V E R S TはT E Sです。
state event action goto ----- ----- ------ ---- S0 TCP: listen on port 102 S1
州のイベント動作goto----- ----- ------ ---- S0 TCP: ポートの上で102S1を聴いてください。
S1 TCP: connected TCP: read TPKT
parse, on error
TCP: send DR, close S0
code is CR
start session server
SS: T-CONNECT S2
.INDICATION
otherwise,
TCP: send DR, close S0
S1 TCP: 接続TCP: 読まれて、TPKTは誤りTCPのときに分析します: DRを送ってください、そして、近いS0コードはCRスタートセッションサーバSSです: T-CONNECT S2 .INDICATION、そうでなければ、TCP、: DR、近いS0を送ってください。
S2 SS: T-CONNECT.RESPONSE if expedited option,
TCP: open port EXPD
TCP: send CC P0
S2 SS: T-CONNECT.RESPONSE、速められたオプション、TCPであるなら: ポートEXPD TCPを開いてください: CC P0を送ってください。
S2 SS: T-DISCONNECT TCP: send DR, close S0
.REQUEST
S2 SS: T-分離TCP: DR、近いS0 .REQUESTを送ってください。
Any event occuring for a state not listed above is considered an error, and handled thusly:
上に記載されなかった状態へのどんなイベント存在も、誤りであると考えられて、このようにして扱われます:
state event action goto
----- ----- ------ ----
S* TCP: other if TCP is open, TCP: close S0
otherwise ignore S0
S* SS: other SS: T-DISCONNECT
.INDICATION
if TCP is open, close S0
州のイベント動作goto----- ----- ------ ---- S*TCP: TCP、もう一方はTCPであるなら開いています: 近くでは、S0が別の方法でS0 S*SSを無視します: 他のSS: TCPであるなら、T-DISCONNECT .INDICATIONは開いていて、近いS0です。
Cass & Rose [Page 12]
キャスとローズ[12ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
C L I E N T S T A T E S
C L I E N T S t A T E S
state event action goto
----- ----- ------ ----
C0 SS: T-CONNECT.REQUEST if expedited option,
TCP: non-blocking
listen on port EXPD
TCP: open port 102 C1
州のイベント動作goto----- ----- ------ ---- C0 SS: T-CONNECT.REQUEST、速められたオプション、TCPであるなら: 非ブロッキングはポートEXPD TCPで聴かれます: 開港102C1
C1 TCP: connected TCP: send CR C2
C1 TCP: 接続TCP: CR C2を送ってください。
C1 TCP: connect fails TCP: close
SS: T-DISCONNECT C0
.INDICATION
C1 TCP: やり損ないTCPを接続してください: SSを閉じてください: T-分離C0 .INDICATION
C2 TCP: data ready TCP: read TPKT
parse, on error
TCP: send DR, close
SS: T-DISCONNECT C0
.INDICATION
code is CC
if expedited option,
verify port EXPD
connected correctly,
if not, treat as error
SS: T-CONNECT P0
.CONFIRMATION
code is DR
TCP: close
SS: T-DISCONNECT C0
.INDICATION
otherwise
TCP: send DR, close
SS: T-DISCONNECT C0
.INDICATION
C2 TCP: データの持ち合わせのTCP: 読まれて、TPKTは誤りTCPのときに分析します: DR、近いSSを送ってください: そうでなければ正しく接続されたポートEXPDは、速められたオプションであるならT-DISCONNECT C0 .INDICATIONコードがCCであることを確かめて、誤りとしての御馳走はSSです: T-CONNECT P0 .CONFIRMATIONコードはDR TCPです: SSを閉じてください: T-DISCONNECT C0 .INDICATION、そうでなければ、TCP: DR、近いSSを送ってください: T-分離C0 .INDICATION
Cass & Rose [Page 13]
キャスとローズ[13ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
Any event occuring for a state not listed above is considered an error, and handled thusly:
上に記載されなかった状態へのどんなイベント存在も、誤りであると考えられて、このようにして扱われます:
state event action goto
----- ----- ------ ----
C* TCP: other if TCP is open, close C0
otherwise ignore C0
州のイベント動作goto----- ----- ------ ---- C*TCP: TCPが開くなら、別に、近いC0は別の方法でC0を無視します。
C* SS: other SS: T-DISCONNECT
.INDICATION
if TCP is open, close C0
C*SS: 他のSS: TCPであるなら、T-DISCONNECT .INDICATIONは開いていて、近いC0です。
Cass & Rose [Page 14]
キャスとローズ[14ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
P E E R S T A T E S
P E E R S TはT E Sです。
state event action goto
----- ----- ------ ----
P0 TCP: data ready TCP: read TPKT
parse, on error
TCP: send DR, close
SS: T-DISCONNECT end
.INDICATION
code is DT
SS: T-DATA.INDICATION P0
code is ED
SS: T-EXPEDITED DATA P0
.INDICATION
code is DR
TCP: close
SS: T-DISCONNECT end
.INDICATION
otherwise
TCP: send DR, close
SS: T-DISCONNECT end
.INDICATION
州のイベント動作goto----- ----- ------ ---- P0 TCP: データの持ち合わせのTCP: 読まれて、TPKTは誤りTCPのときに分析します: DR、近いSSを送ってください: T-DISCONNECT終わりの.INDICATIONコードはDT SSです: T-DATA.INDICATION P0コードはED SSです: T-EXPEDITED DATA P0 .INDICATIONコードはDR TCPです: SSを閉じてください: そうでなければ、T-DISCONNECTが.INDICATIONを終わらせる、TCP: DR、近いSSを送ってください: T-DISCONNECT終わりの.INDICATION
P0 TCP: other TCP: close
SS: T-DISCONNECT end
.INDICATION
P0 TCP: 他のTCP: SSを閉じてください: T-DISCONNECT終わりの.INDICATION
P0 SS: T-DATA.REQUEST TCP: send DT P0
P0 SS: T-DATA.REQUEST TCP: DT P0を送ってください。
P0 SS: T-EXPEDITED DATA TCP: send ED P0
.REQUEST
P0 SS: Tで速められたデータTCP: ED P0 .REQUESTを送ってください。
P0 SS: T-DISCONNECT TCP: send DR, close end
.REQUEST
P0 SS: T-分離TCP: DR、近い終わりの.REQUESTを送ってください。
P0 SS: other TCP: send DR, close
SS: T-DISCONNECT end
.INDICATION
P0 SS: 他のTCP: DR、近いSSを送ってください: T-DISCONNECT終わりの.INDICATION
Cass & Rose [Page 15]
キャスとローズ[15ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
6. Packet Format
6. パケット・フォーマット
Two TS-peers exchange information over a TCP connection by encapsulating information in well-defined packets. A packet, denoted as "TPKT" in the previous sections, is viewed as an object composed of an integral number of octets, of variable length.
2人のTS-同輩が、TCP接続の上で明確なパケットで情報をカプセル化することによって、情報交換します。 オブジェクトが整数の八重奏、可変長で構成されたので、"TPKT"として前項で指示されたパケットは見られます。
NOTE: For the purposes of presentation, these objects are shown
as being 4 octets (32 bits wide). This representation is an
artifact of the style of this memo and should not be interpreted
as requiring that a TPDU be a multiple of 4 octets in length.
以下に注意してください。 プレゼンテーションの目的のために、これらのオブジェクトは4つの八重奏であるとして(幅32ビット)で見せられます。 この表現をこのメモのスタイルの人工物であり、TPDUが長さが4つの八重奏の倍数であることが必要でありながら、解釈するべきではありません。
A packet consists of two parts: a packet-header and a pseudo-TPDU. The format of the header is constant regardless of the type of packet. The format of the pseudo-TPDU follows the [ISO-8073] recommendation very closely with the exceptions listed below. As per [ISO-8073], each TPDU consists of two parts: header and data.
パケットは2つの部品から成ります: パケットのヘッダーと疑似TPDU。 ヘッダーの形式はパケットのタイプにかかわらず一定です。 例外が以下に記載されている状態で、疑似TPDUの形式は非常に密接に[ISO-8073]推薦に続きます。 [ISO-8073]に従って、各TPDUは2つの部品から成ります: ヘッダーとデータ。
It is EXTREMELY important to observe that TPKTs represent "indivisible" units of data to the TS-user. That is, a T-DATA.REQUEST initiated by the TS-user at the sending end of a connection should result in exactly one T-DATA.INDICATION being generated (with exactly that data) for the TS-user at the receiving end. To ensure this behavior, it is critical that any INDICATION event resulting from a TPKT be initiated ONLY after the entire TPKT is fully received. Furthermore, exactly one such INDICATION event should be generated by the TS-peer. The packet length field, as described below, can accommodate on the order of 65K octets of user data. This should be well above the requirements of the size of any SPDU (Session Protocol Data Unit) for any real implementation. As a result, version 1 of this protocol has no need to either fragment or re-assemble TS-user data. If an application arises which requires an SPDU of size greater than 65K octets, this memo will be revised.
それはTPKTsが「分割できません、な」ユニットのデータをTS-ユーザに表すのを観測するために重要なEXTREMELYです。 すなわち、接続の送信側にTS-ユーザによって開始されたT-DATA.REQUESTはちょうど犠牲者のTS-ユーザのために生成される(まさにそのデータで)1T-DATA.INDICATIONをもたらすはずです。 この振舞いを確実にするために、全体のTPKTを完全に受け取っただけである後にTPKTから生じるどんなINDICATIONイベントも開始するのは重要です。 その上、まさにそのようなイベントのINDICATION1つはTS-同輩によって生成されるべきです。 以下で説明されるパケット長分野は65Kの注文ときに利用者データの八重奏を収容できます。 これはかなりどんな本当の実装のためのどんなSPDU(セッションプロトコルData Unit)のサイズの要件を超えているべきです。 その結果、このプロトコルのバージョン1には、TS-利用者データを断片化するか、または組み立て直す必要が全くありません。 サイズの65K以上の八重奏をSPDUに要求するアプリケーションが起こると、このメモは改訂されるでしょう。
The format of the packet-header is as follows:
パケットのヘッダーの形式は以下の通りです:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| vrsn | reserved | packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | vrsn| 予約されます。| パケット長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
どこ:
1. vrsn 8 bits
1. vrsn8ビット
This field is always 1 for this memo.
いつもこの分野はこのメモのための1です。
Cass & Rose [Page 16]
キャスとローズ[16ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
2. packet length 16 bits (min=8, max=65535)
2. 16ビットのパケット長(分=8、最大=65535)
The length of entire packet in octets, including packet-header.
パケットのヘッダーを含む八重奏における、全体のパケットの長さ。
The format of the TPDU (to re-phrase from [ISO-8073]) depends on the type of a TPDU. All TPDUs start with a fixed-part header length and the code. The information following after the code varies, depending on the value of the code. In the context of this memo, the following codes are valid:
TPDU([ISO-8073]から言い直す)の形式はTPDUのタイプに頼っています。 すべてのTPDUsが固定部分ヘッダ長とコードから始まります。 コードの値によって、コードのあとについて行く情報は異なります。 このメモの文脈では、以下のコードは有効です:
CR: connect request
CC: connect confirm
DR: disconnect request
DT: data
ED: expedited data
CR: 要求CC:を接続してください。 接続してください。DRを確認してください: 要求DTから切断してください: データED: 速められたデータ
The format of a CR or CC TPDU is:
CRかCC TPDUの形式は以下の通りです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header length | code | credit| destination reference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source reference | class |options| variable data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | ... | ... |
| ... | ... | ... | ... |
| ... | user data | ... | ... |
| ... | ... | ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ヘッダ長| コード| クレジット| 目的地参照| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソース参照| クラス|オプション| 可変データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | ... | ... | | ... | ... | ... | ... | | ... | 利用者データ| ... | ... | | ... | ... | ... | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
どこ:
3. header length 8 bits (min=6, max=min(254,packet
length-6))
3. ヘッダ長8ビット(最大=分=6、分(254、パケット長さ-6))
The TPDU-header length in octets including parameters but
excluding the header length field and user data (if any).
パラメタを含んでいますが、ヘッダ長分野を除く八重奏と(もしあれば)の利用者データのTPDU-ヘッダ長。
Cass & Rose [Page 17]
キャスとローズ[17ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
4. code 4 bits
4. 4ビットをコード化してください。
The type of TPDU. Values, in the context of this memo, are:
TPDUのタイプ。 このメモの文脈では、値は以下の通りです。
value meaning
----- -------
14 CR: connection request (binary 1110)
13 CC: connection confirm (binary 1101)
8 DR: disconnect request (binary 1000)
15 DT: data (binary 1111)
1 ED: expedited data (binary 0001)
all other reserved
値の意味----- ------- 14CR: 接続要求(2進の1110)13CC: 接続は8DRを確認します(2進の1101): 要求(2進の1000)夏時間15から切断してください: データ(2進の1111)1ED: すべてのもう一方が予約した速められたデータ(2進の0001)
5. credit 4 bits
5. 4ビットを掛けてください。
This field is always ZERO on output and ignored on input.
いつもこの分野は出力であって入力に無視されるところのZEROです。
6. destination reference 16 bits
6. 目的地参照16ビット
This field is always ZERO on output and ignored on input.
いつもこの分野は出力であって入力に無視されるところのZEROです。
7. source reference 16 bits
7. ソース参照16ビット
This field is always ZERO on output and ignored on input.
いつもこの分野は出力であって入力に無視されるところのZEROです。
8. class 4 bits
8. クラス4ビット
This field is always 4 (binary 0100) on output and ignored on
input. It is anticipated that future versions of this protocol
will make use of this field.
いつもこの分野は出力であって入力に無視されるところの4(2進の0100)です。 このプロトコルの将来のバージョンがこの分野を利用すると予期されます。
9. options 4 bits
9. オプション4ビット
This field is always ZERO on output and ignored on input.
いつもこの分野は出力であって入力に無視されるところのZEROです。
10. variable data (header length - 6) octets
10. 可変データ(ヘッダ長--6)八重奏
This portion of the TPDU is of variable length. For most
TPDUs, this portion is empty (the header length field of the
TPDU is exactly 6). The contents of the variable data consist
of zero or more "parameters". Each parameter has the following
format:
TPDUのこの一部が可変長のものです。 ほとんどのTPDUsに関しては、この部分は空です(TPDUのヘッダ長分野はまさに6です)。 可変データの内容はゼロか、より多くの「パラメタ」から成ります。 各パラメタには、以下の形式があります:
parameter code 1 octet in size
parameter length 1 octet in size, value is the number
of octets in parameter value
parameter value parameter data
サイズにおけるサイズ・パラメータ長さの1八重奏におけるパラメタコード1八重奏、値はパラメタ値のパラメタ値のパラメタデータの八重奏の数です。
Cass & Rose [Page 18]
キャスとローズ[18ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
Normally, the parameter length is 1 octet. Any implementation
conforming to this version of the protocol must recognize all
parameter types listed in [ISO-8073]. With the exception of
the parameters listed below, these parameters are simply
ignored.
通常、パラメタの長さは1つの八重奏です。 プロトコルのこのバージョンに従うどんな実装も[ISO-8073]に記載されたすべてのパラメータの型を見分けなければなりません。 以下にリストアップされたパラメタを除いて、これらのパラメタは単に無視されます。
o Parameter name: Transport service access point
identifier (TSAP-ID) of the client
TSAP
o パラメタ名: クライアントTSAPに関する輸送サービスアクセスポイント識別子(TSAP-ID)
Parameter code: 193 (binary 1100 0001)
Parameter length: variable
Parameter value: TSAP-ID attributes
パラメタコード: 193 (2進の1100 0001) パラメタの長さ: 可変Parameter値: TSAP-ID属性
Each TSAP-ID consists of 1 or more attributes. Each
attribute has this format:
各TSAP-IDは1以上属性から成ります。 各属性に、この形式があります:
Attribute code 1 octet in size
Attribute length 1 octet in size, value is the number
of octets in attribute value
Attribute value attribute data
サイズにおけるサイズAttribute長さの1八重奏における属性コード1八重奏、値は属性値Attribute値の属性データの八重奏の数です。
In version 1 of this protocol, only two attributes are
defined. All others are reserved.
このプロトコルのバージョン1では、2つの属性だけが定義されます。 すべての他のものが控え目です。
Attribute name: Internet Address
名前を結果と考えてください: インターネットアドレス
Attribute code: 1
Attribute length: 6
Attribute value: IP address (4 octets)
session port (2 octets, unsigned
integer)
コードを結果と考えてください: 1 長さを結果と考えてください: 6 値を結果と考えてください: IPアドレス(4つの八重奏)セッション港(2つの八重奏、符号のない整数)
This attribute is ALWAYS required. Values for session
port can be found in Appendix A of this memo.
この属性は必要であるALWAYSです。 このメモのAppendix Aでセッションポートへの値を見つけることができます。
Attribute name: Internet Address for Expedited Data
名前を結果と考えてください: 速められたデータのためのインターネットアドレス
Attribute code: 2
Attribute length: 6
Attribute value: IP address (4 octets)
TCP port (2 octets, unsigned integer)
コードを結果と考えてください: 2 長さを結果と考えてください: 6 値を結果と考えてください: IPアドレス(4つの八重奏)TCP港(2つの八重奏、符号のない整数)
This attribute is required ONLY if expedited data is
to be exchanged. The attribute value is an <IP
address, TCP port> pair designated by the TS-peer for
use with expedited data.
速められたデータが交換するだけであることであるならこの属性を必要とします。 属性値が<IPアドレスである、TCPは速められたデータで使用のためにTS-同輩によって任命された>組を移植します。
Cass & Rose [Page 19]
キャスとローズ[19ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
o Parameter name: TSAP-ID of the server TSAP
o パラメタ名: サーバTSAPのTSAP-ID
Parameter code: 194 (binary 1100 0010)
Parameter length: variable
Parameter value: TSAP-ID attributes
パラメタコード: 194 (2進の1100 0010) パラメタの長さ: 可変Parameter値: TSAP-ID属性
o Parameter name: Additional option selection
o パラメタ名: 追加オプション選択
Parameter code: 198 (binary 1100 0110)
Parameter length: 1
Parameter value: additional flags
パラメタコード: 198 (2進の1100 0110) パラメタの長さ: 1 パラメタ値: 追加旗
The additional flags octet consists of 8-bits of optional
flags. Only one bit is of interest to this memo, the
remaining bits should be ZERO on output and ignored on
input. This bit indicates if the transport expedited data
service is to be used. If this bit is set (bit mask 0000
0001) or this parameter does not appear in the TPDU, then
the expedited data service is requested. If this parameter
appears in the TPDU and the bit is not set then the service
is disabled. If the service is requested, then the TSAP-ID
of the sender of the TPDU must include an attribute
indicating the internet address to use for expedited data.
追加旗の八重奏は任意の旗の8ビットから成ります。 1ビットだけがこのメモに興味がある、残っているビットは出力であって入力に無視されるところのZEROであるべきです。 このビットは、サービスが輸送がデータを速めたなら使用されていることであることを示します。 このビットが設定されるか(マスク0000 0001に噛み付きます)、またはこのパラメタがTPDUに現れないなら、速められたデータサービスは要求されます。 このパラメタがTPDUに現れて、ビットが設定されないなら、サービスは障害があります。 サービスが要求されるなら、TPDUの送付者のTSAP-IDは速められたデータに使用するインターネットアドレスを示す属性を含まなければなりません。
o Parameter name: Alternative protocol classes
o パラメタ名: 代替のプロトコルのクラス
Parameter code: 199 (binary 1100 0111)
パラメタコード: 199 (2進の1100 0111)
Parameter length: variable
Parameter value: 64 (binary 0100 0000) in each octet
パラメタの長さ: 可変Parameter値: 64 各八重奏における(2進の0100 0000)
This is used as a NOOP in the variable data. Its use is
HIGHLY discouraged, but for those implementors who wish
to align the user data portion of the TPDU on word (or
page) boundaries, use of this parameter for filling is
recommended.
これはNOOPとして可変データで使用されます。 使用はがっかりするHIGHLYですが、単語(または、ページ)限界にTPDUのユーザデータ部を並べたがっている作成者にとって、このパラメタの充填の使用はお勧めです。
11. user data (packet length - header length - 5)
octets
11. 利用者データ(パケット長--ヘッダ長--5)八重奏
This portion of the TPDU is actual user data, most probably one
or more SPDUs (session protocol data units).
TPDUのこの一部が実際の利用者データ、最もたぶん1SPDUs(セッションプロトコルデータ単位)です。
Cass & Rose [Page 20]
キャスとローズ[20ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
The format of a DR TPDU is:
DR TPDUの形式は以下の通りです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header length | code | credit| destination reference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source reference | reason | variable data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | ... | ... |
| ... | ... | ... | ... |
| ... | user data | ... | ... |
| ... | ... | ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ヘッダ長| コード| クレジット| 目的地参照| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソース参照| 理由| 可変データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | ... | ... | | ... | ... | ... | ... | | ... | 利用者データ| ... | ... | | ... | ... | ... | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the fields is identical to those of a CR or CC TPDU, with the following exceptions:
分野の形式はCRのものか以下の例外があるCC TPDUと同じです:
where:
どこ:
8. reason 8 bits
8. 8ビットを推論してください。
This replaces the class/option fields of the CR or CC TPDU. Any
value, as specified in [ISO-8073], may be used in this field.
This memo makes use of several:
これはCRかCC TPDUのクラス/オプション・フィールドを取り替えます。 [ISO-8073]で指定されるどんな値もこの分野で使用されるかもしれません。 このメモは数個を利用します:
value meaning
----- -------
1 Congestion at TSAP
2 Session entity not attached to TSAP
3 Address unknown (at TCP connect time)
128+0 Normal disconnect initiated by the session
entity
128+1 Remote transport entity congestion at connect
request time
128+3 Connection negotiation failed
128+5 Protocol Error
128+8 Connection request refused on this network
connection
値の意味----- ------- 1 128+1Remoteが実体混雑を輸送するセッション実体によって開始されたTSAP3のAddressの未知(TCP接続時間の)の128+0Normal分離に付けられなかったTSAP2Session実体における混雑は失敗した128+5プロトコルError128+8Connection要求がこのネットワーク接続のときに拒否した要求時間128+3Connection交渉を接続します。
Cass & Rose [Page 21]
キャスとローズ[21ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
The format of a DT or ED TPDU is:
DTかED TPDUの形式は以下の通りです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+
| header length | code | credit| TPDU-NR and EOT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| user data | ... | ... | ... |
| ... | ... | ... | ... |
| ... | ... | ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ | ヘッダ長| コード| クレジット| TPDU-NRとEOT| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 利用者データ| ... | ... | ... | | ... | ... | ... | ... | | ... | ... | ... | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
どこ:
After the credit field (which is always ZERO on output and ignored
on input), there is one additional field prior to the user data:
クレジット分野(いつも出力であって入力に無視されるところのZEROである)の後に、利用者データの前に、1つの追加分野があります:
6. TPDU-NR and EOT 16 bits
6. TPDU-NRとEOT16ビット
This field is always ZERO on output and ignored on input.
いつもこの分野は出力であって入力に無視されるところのZEROです。
7. Expedited Data
7. 速められたデータ
This memo utilizes a second TCP connection to handle expedited data and does not make use of the TCP URGENT mechanism. The primary disadvantage of this decision is that single-threaded implementations of TCP may have some difficulty in supporting two simultaneous connections. There are however several advantages to this approach:
このメモは、速められたデータを扱うのに2番目のTCP接続を利用して、TCP URGENTメカニズムを利用しません。 この決定のプライマリ不都合はTCPのシングルで糸を通された実装が2つの同時接続をサポートする際に苦労するかもしれないということです。 しかしながら、このアプローチのいくつかの利点があります:
a. Use of a single connection to implement the semantics of
expedited data implies that the TSAP peer manage a set of buffers
independent from TCP. The peer would, upon indication of TCP
urgent information, have to buffer all preceeding TPKTs until the
TCP buffer was empty. Expedited data would then be given to the
TS-user. When the expedited data was flushed, then the buffered
(non-expedited) data could be passed up to the receiving user.
a。 速められたデータの意味論を実装する単独結合の使用は、TSAP同輩がTCPから独立しているバッファのセットを経営するのを含意します。 TCPの緊急の情報のしるしのときに、TCPバッファが空になるまで、同輩はすべてのpreceeding TPKTsをバッファリングしなければならないでしょう。 そして、TS-ユーザに速められたデータを与えるでしょう。 速められたデータが洗い流されると、バッファリングされた(非速められた)データを受信ユーザまで通過できるでしょうに。
b. It assumes that implementations support TCP urgency correctly.
This is perhaps an untrue assumption, particular in the case of
TCP urgency occuring when the send window is zero-sized. Further,
it assumes that the implementations can signal this event to the
TCP-user in a meaningful fashion. In a single-threaded
implementation, this is not likely.
b。 それは、実装が、TCPが緊急であると正しくサポートすると仮定します。 発信してください。これが恐らく虚偽の仮定であり、TCP緊急存在の場合における事項がいつか、窓無大きさで分けられます。 さらに、それは、実装が重要なファッションでTCP-ユーザにこのイベントを示すことができると仮定します。 シングルで糸を通された実装では、これは傾向がありません。
Given a reasonable TCP implementation, the TS-peer need listen on two
妥当なTCP実装を考えて、TS-同輩は2で聴かなければなりません。
Cass & Rose [Page 22]
キャスとローズ[22ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
TCP sockets in either polling or interrupt mode. When the TS-peer is given data, the TCP must indicate which connection should be read from.
世論調査かホールド・モードのどちらかによるTCPソケット。 TS-同輩にデータを与えるとき、TCPは、接続がどれから読まれるべきであるかを示さなければなりません。
The only tricky part of the protocol is that the client must be able to start a passive OPEN for the expedited port, and then wait to read from another connection. In between the passive OPEN and the other connection supplying data, the server will connect to the expedited port, prior to sending data on the other connection. To summarize from Section 5, the sequence of events, with respect to TCP, is:
プロトコルの唯一の油断のならない部分はクライアントが、速められたポートのための受け身のオープンを始めて、次に、別の接続から読むのを待つことができなければならないということです。 受け身のオープンと資料を提供する他の接続の間では、サーバは速められたポートに接続するでしょう、もう片方の接続にデータを送る前に。 セクションから5をまとめるために、TCPに関して、イベントの系列は以下の通りです。
time client Server
---- ------ ------
0. passive OPEN of port 102
時間クライアントServer---- ------ ------ 0. ポート102の受け身のオープン
1. T-CONNECT.REQUEST from user
passive OPEN of expedited
port (non-blocking)
1. 速められたポートのユーザの受け身のオープンからのT-CONNECT.REQUEST(非ブロッキング)
2. active OPEN of port 102
2. ポート102の活発なオープン
3. send CC TPKT
3. CC TPKTを送ってください。
4. port 102 connected
4. ポート102は接続しました。
5. receive CC TPKT
T-CONNECT.INDICATION to
user
T-CONNECT.RESPONSE from
user
5. ユーザからCC TPKT T-CONNECT.INDICATIONをユーザT-CONNECT.RESPONSEに受けてください。
6. active OPEN to expedited
port
6. 速められたポートへの活発なオープン
7. expedited port connected
7. 速められたポートは接続しました。
8. send CR TPKT
8. CR TPKTを送ってください。
9. receive CR TPKT
verify expedited port
connected correctly
9. 受信してください、CR TPKTは正しくつなげられた速められたポートについて確かめます。
Multi-threaded implementations of TCP should be able to support this sequence of events without any great difficulty.
TCPのマルチスレッド化された実装は少しも大きな困難なしでイベントのこの系列をサポートできるべきです。
Cass & Rose [Page 23]
キャスとローズ[23ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
8. Conclusions
8. 結論
There are two design decisions which should be considered. The first deals with particular packet format used. It should be obvious to the reader that the TP packet format was adopted for use in this memo. Although this results in a few fields being ignored (e.g., source reference), it does not introduce an unacceptable amount of overhead. For example, on a connection request packet (the worst case) there are 6 bytes of "zero on output, ignore on input" fields. Considering that the packet overhead processing is fixed, requiring that implementations allocate an additional 1.5 words is not unreasonable! Of course, it should be noted that some of these fields (i.e., class) may be used in future versions of the protocol as experience is gained.
考えられるべきである2つのデザイン決定があります。 使用される特定のパケット・フォーマットとの最初の取引。 読者にとって、TPパケット・フォーマットがこのメモにおける使用のために採用されたのは、明白であるべきです。 これは無視されるいくつかの分野(例えば、ソース参照)をもたらしますが、それは容認できない量のオーバーヘッドを導入しません。 例えば、接続リクエスト・パケット(最悪の場合)の上に、6バイトがある、「出力のときに、入力のときに」 分野を無視してください。 パケットオーバーヘッド処理が固定されていると考える場合、実装が追加1.5の単語を割り当てるのが必要であるのは無理ではありません! もちろん、経験するのに従ってこれらの分野(すなわち、クラス)のいくつかがプロトコルの将来のバージョンで使用されるかもしれないことに注意されるべきです。
The second decision deals with how the TCP and TSAP port space is administered. It is probably a very bad idea to take any responsibility, whatsoever, for managing this addressing space, even after ISO has stabilized. There are two issues involved. First, at what level do the TCP and TSAP port spaces interact; second, who defines what this interaction looks like. With respect to the first, it wholly undesirable to require that each TSAP port map to a unique TCP port. The administrative problems for the TCP "numbers czar (and czarina)" would be non-trivial. Therefore, it is desirable to allocate a single TCP port, namely port 102, as the port where the "ISO Transport Services" live in the TCP domain. Second, the interaction defined in Appendix A of this memo is embryonic at best. It will no doubt be replaced as soon as the ISO world reaches convergence on how services are addressed in ISO TP. Therefore readers (and implementors) are asked to keep in mind that this aspect of the memo is guaranteed to change. Unfortunately, the authors are not permitted the luxury of waiting for a consensus in ISO. As a result, the minimal effort approach outlined in the appendix below was adopted.
2番目の決定はTCPとTSAPポートスペースがどう管理されるかに対処します。 どんな責任も取るのは、たぶん非常に悪い考えです、全く、このアドレシングスペースを管理するために、ISOが安定した後にさえ。 かかわった2冊があります。 まず最初に、どんなレベルにTCPをしてください。そうすれば、TSAPが空間を移植するかは相互作用します。 2番目。(その2はこの相互作用が似ていることを定義します)。 1番目に関してそれ、各TSAPがユニークなTCPポートに地図を移植するのが必要であるのにおいて完全に望ましくありません。 TCPのための「数皇帝(そして、帝政ロシア皇后)」が重要であるだろうという管理問題。 したがって、単一のTCPポートを割り当てて、すなわち、102を移植するのは望ましいです、「ISO輸送サービス」がTCPドメインで生活するポートとして。 2番目に、このメモのAppendix Aで定義された相互作用はせいぜい胎児です。 ISO世界がサービスがISO TPでどう扱われるかにおける集合に達するとすぐに、間違いなくそれを取り替えるでしょう。 したがって、読者(そして、作成者)が、メモのこの局面が変化するように保証されるのを覚えておくように頼まれます。 残念ながら、ISOでコンセンサスを待つぜいたくは作者に受入れられません。 その結果、以下の付録に概説された最小量の取り組みアプローチは取られました。
A prototype implementation of the protocol described by this memo is available for 4.2BSD UNIX. Interested parties should contact the authors for a copy. To briefly mention its implementation, a given ISO service is implemented as a separate program. A daemon listens on TCP port 102, consults a database when a connection request packet is received, and fires the appropriate program for the ISO service requested. Of course, given the nature of the BSD implementation of TCP, as the child fires, responsibility of that particular connection is delegated to the child; the daemon returns to listening for new connection requests. The prototype implementation consists of both the daemon program and subroutine libraries which are loaded with programs providing ISO services.
このメモで説明されたプロトコルのプロトタイプ実装は4.2BSD UNIXに利用可能です。 利害関係者はコピーのために作者に連絡するべきです。 簡潔に実装について言及するために、与えられたISOサービスは別々のプログラムとして実装されます。 デーモンは、TCPでポート102を聴いて、接続リクエスト・パケットが受け取られているとき、データベースに相談して、サービスが要求したISOのために適切なプログラムを適用します。 もちろん、TCPのBSD実装の本質を考えて、子供が発火するとき、その特定の接続の責任を子供へ代表として派遣します。 デーモンは新しい接続要求の聞こうとするのに戻ります。 プロトタイプ実装はサービスをISOに供給するデーモンプログラムとプログラムが積まれるサブルーチンライブラリの両方から成ります。
Cass & Rose [Page 24]
キャスとローズ[24ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
9. References
9. 参照
[ISO-8072] ISO.
"International Standard 8072. Information Processing
Systems -- Open Systems Interconnection: Transport
Service Definition."
(June, 1984)
[ISO-8072]ISO。 「国際規格8072。」 情報処理システム--オープン・システム・インターコネクション: 「サービス定義を輸送してください。」 (1984年6月)
[ISO-8073] ISO.
"International Standard 8073. Information Processing
Systems -- Open Systems Interconnection: Transport
Protocol Specification."
(June, 1984)
[ISO-8073]ISO。 「国際規格8073。」 情報処理システム--オープン・システム・インターコネクション: 「プロトコル仕様を輸送してください。」 (1984年6月)
[ISO-8327] ISO.
"International Standard 8327. Information Processing
Systems -- Open Systems Interconnection: Session
Protocol Specification."
(June, 1984)
[ISO-8327]ISO。 「国際規格8327。」 情報処理システム--オープン・システム・インターコネクション: 「セッションプロトコル仕様。」 (1984年6月)
[RFC-791] Internet Protocol.
Request for Comments 791
(September, 1981)
(See also: MIL-STD-1777)
[RFC-791]インターネットプロトコル。 コメント791のために、(1981年9月)を要求してください。(参照: 軍規格-1777)
[RFC-793] Transmission Control Protocol.
Request for Comments 793
(September, 1981)
(See also: MIL-STD-1778)
[RFC-793]通信制御プロトコル。 コメント793のために、(1981年9月)を要求してください。(参照: 軍規格-1778)
[RFC-960] Assigned Numbers.
Request for Comments 960
(December, 1985)
[RFC-960]は数を割り当てました。 コメント960を求める要求(1985年12月)
[X.214] CCITT.
"Recommendation X.214. Transport Service Definitions
for Open Systems Interconnection (OSI) for CCITT
Applications."
(October, 1984)
[X.214]CCITT。 「推薦X.214。」 「CCITTアプリケーションのためのオープン・システム・インターコネクション(OSI)のためにサービス定義を輸送してください。」 (1984年10月)
[X.224] CCITT.
"Recommendation X.224. Transport Protocol Specification
for Open Systems Interconnection (OSI) for CCITT
Applications."
(October, 1984)
[X.224]CCITT。 「推薦X.224。」 「CCITTアプリケーションのためにオープン・システム・インターコネクション(OSI)のためのプロトコル仕様を輸送してください。」 (1984年10月)
Cass & Rose [Page 25]
キャスとローズ[25ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
[X.225] CCITT.
"Recommendation X.225. Session Protocol Specification
for Open Systems Interconnection (OSI) for CCITT
Applications."
(October, 1984)
[X.225]CCITT。 「推薦X.225。」 「CCITTアプリケーションのためのオープン・システム・インターコネクション(OSI)のためのセッションプロトコル仕様。」 (1984年10月)
[X.410] CCITT.
"Recommendation X.410. Message Handling Systems: Remote
Operations and Reliable Transfer Server."
(October, 1984)
[X.410]CCITT。 「推薦X.410。」 メッセージハンドリングシステム: 「リモート操作と高信頼の転送サーバ。」(1984年10月)
Appendix A: Reserved TSAP IDs
付録A: 予約されたTSAP ID
Version 1 of this protocol uses a relatively simple encoding scheme for TSAP IDs. A TSAP ID is an attribute list containing two parameters, a 32-bit IP address, and a 16-bit port number. This is used to identify both the client TSAP and the server TSAP. When it appears in a TPKT with code CR or CC, the TSAP ID is encoded in the variable data part for the client TSAP as:
このプロトコルのバージョン1はTSAP IDに比較的簡単なコード化体系を使用します。 TSAP IDは2つのパラメタを含む属性リストと、32ビットのIPアドレスと、16ビットのポートナンバーです。 これは、クライアントTSAPとサーバTSAPの両方を特定するのに使用されます。 コードCRかCCと共にTPKTに現れるとき、TSAP IDはクライアントTSAPのために以下として可変データ部分でコード化されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 193 | 8 | 1 | 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| a | b | c | d |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 193 | 8 | 1 | 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a| b| c| d| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ポート| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
and for the server TSAP as:
そして、以下としてのサーバTSAPのために
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 194 | 8 | 1 | 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| a | b | c | d |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 194 | 8 | 1 | 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a| b| c| d| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ポート| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(Neither of these examples include an attribute for a TCP connection for expedited data. If one were present, the length of the TSAP ID attribute would be 16 instead of 8, and the 8 bytes following the Internet address would be "2" for the attribute code, "6" for the
これらの例のどちらも速められたデータのためのa TCP接続のための属性を含んでいません。(1つが存在しているなら、TSAP ID属性の長さが8の代わりに16であり、インターネット・アドレスに従う8バイトが16であるだろう、「属性コードのための2インチ、「6インチ、」
Cass & Rose [Page 26]
キャスとローズ[26ページ]
RFC 983 April 1986 ISO Transport Services on Top of the TCP
RFC983 1986年4月のISOはTCPの上でサービスを輸送します。
attribute length, and then 6 octets for the Internet address to use for expedited data, 4 octets for IP address, and 2 octets for TCP port.)
長さを結果と考えて、次に、インターネット・アドレスが速められたデータに使用する6つの八重奏、IPアドレスのための4つの八重奏、およびTCPポートへの2つの八重奏を結果と考えてください。)
Where [a.b.c.d] is the IP address of the host where the respective TSAP peer resides, and port is a 16-bit unsigned integer describing where in the TSAP port space the TS-user lives.
[a.b.c.d]がそれぞれのTSAP同輩が住んでいて、ポートがTS-ユーザがTSAPポートスペースでは、どこで生活するかを説明する16ビットの符号のない整数であるホストのIPアドレスであるところ。
Port value Designation
---------- -----------
0 illegal
1-4096 privileged
4097-65535 user
ポート値のDesignation---------- ----------- 0の不法な1-4096特権がある4097-65535ユーザ
The following table contains the list of the "official" TSAP ID port numbers as of the first release of this memo. It is expected that future editions of the "Assigned Numbers" document[RFC-960] will contain updates to this list.
以下のテーブルはこのメモの最初のリリース現在、「公式」のTSAP IDポートナンバーのリストを含みます。 「規定番号」というドキュメント[RFC-960]の将来の版がこのリストにアップデートを含むと予想されます。
Port name ISO service
---- ---- -----------
1 echo unofficial echo
2 sink unofficial data sink
3 FTAM File Transfer, Access, and Management
4 VTS ISO-8571 Virtual Terminal Service
5 MHS Message Handling System [X.411]
CCITT X.400
6 JTM Job Transfer and Manipulation
ISO 8831/8832
7 CASE Common Application Service Elements
Kernel ISO-8650/2
ポート名前ISOサービス---- ---- ----------- 1 エコー非公式のエコー2流し台非公式のデータ受信端末3FTAM File Transfer、Access、およびManagement4VTS ISO-8571 Virtual Terminal Service5MHS Message Handling System[X.411]CCITT X.400 6JTM Job TransferとManipulation ISO8831/8832 7CASE Common Application Service Elements Kernel ISO-8650/2
If anyone knows of a list of "official" ISO services, the authors would be very interested.
だれかが「公式」のISOサービスのリストを知っているなら、作者は非常に関心があるでしょう。
Cass & Rose [Page 27]
キャスとローズ[27ページ]
一覧
スポンサーリンク
