RFC171 日本語訳
0171 The Data Transfer Protocol. A. Bhushan, B. Braden, W. Crowther,E. Harslem, J. Heafner, A. McKenize, J. Melvin, B. Sundberg, D.Watson, J. White. June 1971. (Format: TXT=20616 bytes) (Obsoleted by RFC0264) (Updates RFC0114) (Updated by RFC0238) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Abhay Bhushan Request for Comments: 171 MIT NIC 6793 Bob Braden Categories: D.4, D.5, and D.7 UCLA Updates: 114 Will Crowther Obsolete: None Alex McKenzie BBN Eric Harslem John Heafner Rand John Melvin Dick Watson SRI Bob Sundberg HARVARD Jim White UCSB 23 June 1971
ネットワークワーキンググループAbhay Bhushanはコメントのために以下を要求します。 171 MIT NIC6793ボブブレーデンCategories: D.4、D.5、およびD.7 UCLAアップデート: 114 クラウザーは以下を時代遅れにするでしょうか? なにもに、アレックス・マッケンジー・BBNエリック・Harslemジョン・Heafner Randジョン・メルビン・ディック・ワトソン・様のボブ・SundbergハーバードのジムはUCSB1971年6月23日を空白にします。
THE DATA TRANSFER PROTOCOL
データ転送プロトコル
I. INTRODUCTION
I. 序論
A common protocol is desirable for data transfer in such diverse applications as remote job entry, file transfer, network mail system, graphics, remote program execution, and communication with block data terminals (such as printers, card, paper tape, and magnetic tape equipment, especially in context of terminal IMPs). Although it would be possible to include some or even all of the above applications in an all-inclusive file transfer protocol, a separation between data transfer and application functions would provide flexibility in implementation, and reduce complexity. Separating the data transfer function would also reduce proliferation of programs and protocols.
リモートジョブエントリ、ファイル転送、ネットワーク・メール・システム、グラフィックス、リモートプログラム実行、およびブロックのデータ端末とのコミュニケーション(特に端末のIMPsの文脈でのプリンタや、カードや、紙テープや、磁気テープ設備などの)のようなさまざまのアプリケーションにおけるデータ転送に、一般的なプロトコルは望ましいです。 すべてを含むファイル転送プロトコルに上のアプリケーションのいくつかかすべてさえ含んでいるのが可能でしょうが、データ転送とアプリケーションの機能の間の分離は、柔軟性を実装に提供して、複雑さを減少させるでしょう。 また、データ転送機能を切り離すと、プログラムとプロトコルの増殖は抑えられるでしょう。
We have therefore defined a low-level data transfer protocol (DTP) to be used for transfer of data in file transfer, remote job entry, and other applications protocols. This paper concerns itself solely with the data transfer protocol. A companion paper (RFC 172) describes file transfer protocol.
したがって、私たちは、ファイル転送、リモートジョブエントリ、および他のアプリケーションプロトコルにおけるデータ転送に使用されるために、低レベルであるデータ転送プロトコル(DTP)を定義しました。 この紙は唯一データ転送プロトコルでタッチしています。 仲間論文(RFC172)はファイル転送プロトコルについて説明します。
II. DISCUSSION
II。 議論
The data transfer protocol (DTP) serves three basic functions. It provides for convenient separation of NCP messages into "logical" blocks (transactions, units, records, groups, and files), it allows for the separation of data and control information, and it includes some error control mechanisms.
データ転送プロトコル(DTP)は3つの基本機能に役立ちます。 「論理的な」ブロック(トランザクション、ユニット、レコード、グループ、およびファイル)にNCPメッセージの便利な分離に備えます、とデータと制御情報の分離のために許容します、そして、いくつかの誤り制御メカニズムを含んでいます。
Bhushan, et al. [Page 1] RFC 171 THE DATA TRANSFER PROTOCOL June 1971
Bhushan、他 [1ページ] RFC171データ転送プロトコル1971年6月
Three modes of separating messages into transactions [1] are allowed by DTP. The first is an indefinite bit stream which terminates only when the connection is closed (i.e., the bit stream represents a single transaction for duration of connection). This mode would be useful in data transfer between hosts and terminal IMPs (TIPs).
トランザクション[1]への分離メッセージの3つのモードがDTPによって許容されています。 1番目は接続が閉じられるときだけ(すなわち、ビットストリームは接続の持続時間のための単一取引を表します)終わる無期ビットストリームです。 このモードはホストと端末のIMPs(TIPs)の間のデータ転送で役に立つでしょう。
The second mode utilizes a "transparent" block convention, similar to the ASCII DLE (Data Link Escape). In "transparent" mode, transactions (which may be arbitrarily long) end whenever the character sequence DLE ETX is encountered (DLE and ETX are 8-bit character codes). To prevent the possibility of a DLE ETX sequence occurring within data stream, any occurrence of DLE is replaced by DLE DLE on transmission. The extra DLE is stripped on reception. A departure from the ASCII convention is that "transparent" block does not begin with DLE STX, but with a transaction type byte. This mode will be useful in data transfer between terminal IMPs.
2番目のモードはASCII DLE(データLink Escape)と同様の「透明な」ブロックコンベンションを利用します。 「透明な」モードに、キャラクタシーケンスDLE ETXが遭遇する(DLEとETXは8ビットのキャラクタコードです)ときはいつも、トランザクション(任意に長いかもしれない)は終わります。 データ・ストリームの中に起こるDLE ETX系列の可能性を防ぐために、トランスミッションのときにDLEのどんな発生もDLE DLEに取り替えます。 レセプションで付加的なDLEを剥取ります。 ASCIIコンベンションからの出発は「透明な」ブロックがDLE STXにもかかわらず、トランザクションタイプバイトで始まらないということです。 このモードは端末のIMPsの間のデータ転送で役に立ちます。
The third mode utilizes a count mechanism. Each transaction begins with a fixed-length descriptor field containing separate binary counts of information bits and filler bits. If a transaction has no filler bits, its filler count is zero. This mode will be useful in most host-to-host data transfer applications.
3番目のモードはカウントメカニズムを利用します。 固定長記述子分野が情報ビットとフィラービットの別々の2進のカウントを含んでいて、各トランザクションは始まります。 トランザクションにフィラービットが全くないなら、フィラーカウントはゼロです。 このモードはホストからホストへのデータ転送ほとんどのアプリケーションで役に立ちます。
DTP allows for the above modes to be intermixed over the same connection (i.e., mode is not associated with connection, but only with transaction). The above transfer modes can represent transfer of either data or control information. The protocol allows for separating data or control information at a lower level, by providing different "type" codes (see SPECIFICATIONS) for data and control transactions. This provision may simplify some implementations.
DTPは、上のモードが同じ接続の上に混ぜられるのを許容します(すなわち、モードは接続にもかかわらず、トランザクションだけに関連づけられません)。 上の転送モードはデータか制御情報のどちらかの転送を表すことができます。 プロトコルは、下のレベルでデータか制御情報を切り離すと考慮します、異なった「タイプ」コード(SPECIFICATIONSを見る)をデータとコントロールトランザクションに提供することによって。 この支給はいくつかの実装を簡素化するかもしれません。
The implementation of a workable [2] subset of the above modes is specifically permitted by DTP. To provide compatibility between hosts using different subsets of transfer modes, an initial "handshake" procedure is required by DTP. The handshake involves exchanging information on modes available for transmit and receive. This will enable host programs to agree on transfer modes acceptable for a connection.
上のモードの実行可能な[2]部分集合の実装はDTPによって明確に可能にされます。 転送モードの異なった部分集合を使用することでホストの間の互換性を提供するために、初期の「握手」手順はDTPによって必要とされます。 握手は、モードで情報交換することを利用可能な状態で伴います。送受信してください。 これは、ホストプログラムが接続において、許容できる転送モードに同意するのを可能にするでしょう。
The manner in which DTP is used would depend largely on the applications protocol. It is the applications protocol which defines the workable subset of transfer modes. For example, the file transfer protocol will not work just with the indefinite bit stream modes. At least, for control information one of the other two modes is required. Again, the use of information separator and abort functions provided in DTP (see SPECIFICATIONS) is defined by the applications protocol. For example, in a remote job entry protocol, aborts may be used to stop the execution of a job while they may not
DTPが使用されている方法は主にアプリケーションプロトコルによるでしょう。 それは転送モードの実行可能な部分集合を定義するアプリケーションプロトコルです。 例えば、ファイル転送プロトコルは無期ビットストリームモードだけで働かないでしょう。 制御情報に関して、他の2つのモードの1つが少なくとも、必要です。 一方、DTP(SPECIFICATIONSを見る)に提供された情報分離と放棄機能の使用はアプリケーションプロトコルによって定義されます。 例えば、使用されていない間、リモートジョブエントリプロトコルに、アボートは、仕事の実行を止めるのに使用されるかもしれません。
Bhushan, et al. [Page 2] RFC 171 THE DATA TRANSFER PROTOCOL June 1971
Bhushan、他 [2ページ] RFC171データ転送プロトコル1971年6月
cause any action in another applications protocol.
別のアプリケーションプロトコルにおけるあらゆる動作を引き起こしてください。
It should also be noted that DTP does not define a data transfer service. There is no standard server socket, or initial connection protocol defined for DTP. What DTP defines is a mechanism for data transfer which can be used to provide services for block data transfers, file transfers, remote job entry, network mail and numerous other applications.
また、DTPがデータ転送サービスを定義しないことに注意されるべきです。 DTPのために定義されたどんな標準のサーバソケットの、または、初期の接続プロトコルもありません。 DTPが定義することは転送、ファイル転送、リモートジョブエントリ、ネットワークメール、および他の頻繁な利用をブロック・データのためのサービスに供給するのに使用できるデータ転送のためのメカニズムです。
There are to be no restrictions on the manner in which DTP is implemented at various sites. For example, DTP may be imbedded in an applications program such as for file transfer, or it may be a separate service program or subroutine used by several applications programs. Another implementation may employ macros or UUO's (user unimplemented operations on PDP-10's), to achieve the functions specified in DTP. It is also possible that in implementation, the separation between the DTP and applications protocols be only at a conceptual level.
制限が全くDTPが様々なサイトで実装される方法にないでしょう。 それは、数個のアプリケーションプログラムで使用される例えば、DTPがファイル転送などのアプリケーションプログラムで埋め込まれるかもしれませんか、別々のサービス・プログラムかサブルーチンであるかもしれません。別の実装は、DTPで指定された機能を獲得するのに、マクロかUUOのもの(PDP-10のところにおけるユーザの非実装している操作)を使うかもしれません。 また、DTPとアプリケーションプロトコルの間の分離が単に概念的なレベルにおいて実装では、そうも可能です。
III. SPECIFICATIONS
III。 仕様
1. Byte Size for Network Connection
1. ネットワーク接続のためのバイトサイズ
The standard byte size for network connections using DTP is 8- bit. However, other byte sizes specified by higher-level applications protocols or applications programs are also allowed by DTP. For the purpose of this document bytes are assumed to be 8-bits, unless otherwise stated.
DTPを使用しているネットワーク接続のための標準のバイトサイズは8ビットです。 しかしながら、また、サイズが、よりハイレベルのアプリケーションプロトコルで指定した他のバイトかアプリケーションプログラムがDTPによって許容されています。 別の方法で述べられない場合バイトが8ビットであると思われるこのドキュメントの目的のために。
2. Transactions
2. トランザクション
At DTP level, all information transmitted over connection is a sequence of transactions. DTP defines the rules for delimiting transactions. [3]
DTPレベルでは、接続の上に伝えられたすべての情報がトランザクションの系列です。 DTPは、トランザクションを区切るために規則を決めます。 [3]
2A. Types
2A。 タイプ
The first byte of each transaction shall define a transaction type, as shown below. (Note that code assignments do not conflict with assignments in TELNET protocol.) The transaction types may be referred by the hexadecimal code assigned to them. The transactions types are discussed in more detail in section 2B.
それぞれのトランザクションの最初のバイトは以下に示されるようにトランザクションタイプを定義するものとします。 (コード課題がTELNETプロトコルにおける課題と衝突しないことに注意してください。) トランザクションタイプは彼らに割り当てられた16進コードによって参照されるかもしれません。 さらに詳細にセクション2Bでトランザクションタイプについて議論します。
Bhushan, et al. [Page 3] RFC 171 THE DATA TRANSFER PROTOCOL June 1971
Bhushan、他 [3ページ] RFC171データ転送プロトコル1971年6月
Code Transaction Type Hex Octal
トランザクションタイプ十六進法8進をコード化してください。
B0 260 Indefinite bit stream -- data. B1 261 Transparent (DLE) block--data. B2 262 Descriptor and counts--data. B3 263 Modes available (handshake). B4 264 Information separators (endcode). B5 265 Error codes. B6 266 Abort. B7 267 No operation (NoOp). B8 270 Indefinite bit stream--control. B9 271 Transparent (DLE) block--control. BA 272 Descriptor and counts--control. BB 273 (unassigned but reserved for data transfer) BC 274 " " " BD 275 " " " BE 276 " " " BF 277 " " "
B0 260の無期ビットストリーム--データ。 B1 261見え透いた(DLE)ブロック--データ。 B2 262記述子とカウント--データ。 利用可能なB3 263モード(握手)。 B4 264情報分離(endcode)。 B5 265エラーコード。 B6 266は中止になります。 B7 267いいえ操作(NoOp)。 B8 270の無期ビットストリーム--制御してください。 透明な(DLE)が妨げるB9 271--制御してください。 BA272Descriptorとカウント--制御してください。 掲示板273(割り当てられませんが、データ転送のために、予約されます)紀元前274年、「「「BD275」、「「276になってください」、「「BF277、」 「」」
2B. Syntax and Semantics
2B。 構文と意味論
2B.1 Type B0 and B8 (indefinite bitstream modes) transactions terminate only when the NCP connection is "closed". There is no other escape convention defined in DTP at this level. It should be noted, that closing connection in bitstream mode represents an implicit file separator (see section 2B.5).
2B.1はB0をタイプします、そして、NCP接続が「閉じられる」ときだけ、B8(無期bitstreamモード)トランザクションは終わります。 このレベルでDTPで定義された他のエスケープコンベンションは全くありません。 それが閉じる場合、bitstreamモードにおける接続が暗黙のファイル分離文字を表すことに(セクション2B.5を見てください)注意されるべきです。
2B.2 Type B1 and B0 (transparent block modes) transactions terminate when the byte sequence DLE ETX is encountered. The sender shall replace any occurrence of DLE in data stream by the sequence DLE DLE. The receiver shall strip the extra DLE. The transaction is assumed to by byte-oriented. The code for DLE is Hex '90' or Octal '220' (this is different from the ASCII DLE which is Hex '10' or Octal '020). ETX is Hex '03' or Octal '03' (the same as ASCII ETX) [4].
2B.2はB1をタイプします、そして、バイト列DLE ETXが遭遇するとき、B0(見え透いたブロックモード)トランザクションは終わります。 送付者は系列DLE DLEによるデータ・ストリームにおける、DLEのどんな発生にも取って代わるものとします。 受信機は付加的なDLEを剥取るものとします。 トランザクションは想定されます。バイト指向で。 'DLEのためのコードはHex90年です'かOctalが'220'である、(これが'Hex10年OctalであるASCII DLEと異なっている、020年) ETXはHex'03'かOctal'03'(ASCII ETXと同じ)[4]です。
2B.3 Type B2 and BA (descriptor and counts modes) transactions have three fields, a 9-byte (72-bits) descriptor field [5] and variable length (including zero) info and filler fields, as shown below. The total length of a transaction is (72+info+filler) bits.
2B.3はB2をタイプします、そして、BA(記述子とカウントモード)トランザクションには、3つの分野、9バイト(72ビット)の記述子分野[5]、可変長(ゼロを含んでいる)インフォメーション、およびフィラー分野があります、以下に示すように。 トランザクションの全長は(72+インフォメーション+フィラー)ビットです。
Bhushan, et al. [Page 4] RFC 171 THE DATA TRANSFER PROTOCOL June 1971
Bhushan、他 [4ページ] RFC171データ転送プロトコル1971年6月
|<B2 or BA><Info count><NUL><Seq #><NUL><filler count>|<info><filler> |
| <B2かBA><Infoが><NUL><Seq#><NUL><フィラーカウントを数えます。>|<インフォメーション><フィラー>。|
| 3-bits 24-bits 8-bits 16-bits 8-bits 8-bits |Variable length|
| 3ビットの24ビットの8ビットの16ビットの8ビットの8ビット|可変長|
|<----- 72-bit descriptor field --------------------->|info and filler|
| <、-、-、-、-- 72ビットの記述子分野--------------------->|インフォメーションとフィラー|
Info count is a binary count of number of bits in info field, not including descriptor or filler bits. Number of info bits is limited to (2**24 - 1), as there are 24 bits in info count field.
インフォメーションカウントは記述子かフィラービットを含んでいるのではなく、インフォメーション分野のビットの数の2進のカウントです。 24ビットがインフォメーションカウント分野にあって、インフォメーションビットの数は(2**24--1)に制限されます。
Sequence # is a sequential count in round-robin manner of B2 and BA type transaction. The inclusion of sequence numbers would help in debugging and error control, as sequence numbers may be used to check for missing transactions, and aid in locating errors. Hosts not wishing to implement this mechanism should have all 1's in the field. The count shall start from zero and continue sequentially to all 1's, after which it is reset to all zeros. The permitted sequence numbers are one greater than the previous, and all 1's.
系列#はB2の連続方法で連続したカウントです、そして、BAはトランザクションをタイプします。 一連番号の包含はデバッグと誤り制御で助けるでしょう、一連番号がなくなったトランザクション、および援助がないかどうか誤りの場所を見つける際にチェックするのに使用されるとき。 このメカニズムを実装したがっていないホストはその分野にすべての1を持つべきです。 カウントは、すべての1に連続して裸一貫から始めて、続くものとします。(その時、それはすべてのゼロにリセットされました後)。 受入れられた一連番号は前、およびすべての1よりすばらしい1つです。
Filler count is a binary count of bits used as fillers (i.e., not information) after the end of meaningful data. Number of filler bits is limited to 255, as there are 8 bits in filler count field.
フィラーカウントは重要なデータの終わり以降フィラー(すなわち、情報でない)として使用されたビットの2進のカウントです。 8ビットがフィラーカウント分野にあって、フィラービットの数は255に制限されます。
The NUL bytes contain all 0's.
NULバイトはすべての0を含んでいます。
2B.4 Type B3 (modes available) transactions have a fixed length of 3 bytes, as shown below. First byte defines transaction type as B3, second byte defines modes available for send, and third byte defines modes available for receive.
2B.4タイプB3(利用可能なモード)トランザクションには、3バイトの固定長が以下に示されるようにあります。 最初のバイトはトランザクションタイプをB3と定義して、発信してください。そうすれば、3番目のバイトが利用可能な状態でモードを定義するので、2番目のバイトは利用可能なモードを定義します。受信してください。
+------------------+---------------------+---------------------+ | Type | I send | I receive | | | | | | | | | | | | | | | | | | | | B3 |0|0|BA|B2|B9|B1|B8|B0|0|0|BA|B2|B9|B1|B8|B0| +------------------+---------------------+---------------------+
+------------------+---------------------+---------------------+ | タイプ| 私は発信します。| 私は受信します。| | | | | | | | | | | | | | | | | | | | B3|0|0|Ba|B2|B9|B1|B8|B0|0|0|Ba|B2|B9|B1|B8|B0| +------------------+---------------------+---------------------+
The modes are indicated by bit-coding, as shown above. The particular bit or bits, if set to logical "1", indicate that mode to be available. The 2 most significant bits should be set to logical "0". The use of type B3 transactions is discussed in section 3B.
モードは上に示されるようにコード化することで噛み付いている示されます。 または、特定のビット、ビット論理的な「何1インチも、そのモードが利用可能であることを示してください」に設定されるなら。 2つの最上位ビットが論理的な「0インチ」に設定されるべきです。 セクション3BでタイプB3トランザクションの使用について議論します。
2B.5 Type B4 (information separator) transactions have fixed length of 2 bytes, as shown below. First byte defines transaction type as B4, and second byte defines the separator.
2B.5タイプB4(情報分離)トランザクションは以下に示されるように2バイトの長さを固定しました。 最初のバイトはトランザクションタイプをB4と定義します、そして、2番目のバイトは分離符を定義します。
Bhushan, et al. [Page 5] RFC 171 THE DATA TRANSFER PROTOCOL June 1971
Bhushan、他 [5ページ] RFC171データ転送プロトコル1971年6月
+------------------+------------------+ | Type | End Code | | | | |R| | | | |G|E| | | B4 | F|R|C|U| | | I|O|O|N| | | L|U|R|I| | | E|P|D|T| +------------------+------------------+
+------------------+------------------+ | タイプ| エンド・コード| | | | |R| | | | |G|E| | | B4| F|R|C|U| | | I|O|O|N| | | L|U|R|I| | | E|P|D|T| +------------------+------------------+
The following separator codes are assigned:
以下の分離符コードは割り当てられます:
Code Meaning Hex Octal
意味十六進法8進をコード化してください。
01 001 Unit separator 03 003 Record separator 07 007 Group separator 0F 017 File separator
01 001ユニット分離文字03 003Record分離符07 007Group分離符0F017File分離符
Files, groups, records, and units may be data blocks that a user defines to be so. The only restriction is that of the hierarchical relationship File>Groups>Records>Units (where '>' means 'contains'). Thus a file separator marks not only the end of file, but also the end of group, record, and unit. These separators may provide a convenient "logical" separation of data at the data transfer level. Their use is governed by the applications protocol.
ファイル、グループ、レコード、およびユニットはユーザがしたがって、であるなるように定義するデータ・ブロックであるかもしれません。 唯一の制限が上下関係File>Groups>Records>Units('>'が'含有'を意味するところ)のものです。 したがって、ファイル分離文字はファイルの終りだけではなく、グループ、記録、およびユニットの端を示します。 これらの分離符はデータ転送レベルでデータの便利な「論理的な」分離を提供するかもしれません。 彼らの使用はアプリケーションプロトコルによって管理されます。
2B.6 Type B5 (error codes) transactions have a fixed length of 3 bytes, as shown below. First byte defines transaction type as B5, second byte indicates an error code, and third byte may indicate the sequence number on which error occurred.
2B.6タイプB5(エラーコード)トランザクションには、3バイトの固定長が以下に示されるようにあります。 最初のバイトはトランザクションタイプをB5と定義します、そして、2番目のバイトはエラーコードを示します、そして、3番目のバイトは誤りが発生した一連番号を示すかもしれません。
+------------------+-------------------+-----------------+ | Type | Error Code | Sequence # | | | | | | B5 | | | +------------------+-------------------+-----------------+
+------------------+-------------------+-----------------+ | タイプ| エラーコード| 系列#| | | | | | B5| | | +------------------+-------------------+-----------------+
Bhushan, et al. [Page 6] RFC 171 THE DATA TRANSFER PROTOCOL June 1971
Bhushan、他 [6ページ] RFC171データ転送プロトコル1971年6月
The following error codes are assigned:
以下のエラーコードは割り当てられます:
Error Code Meaning Hex Octal
エラーコード意味十六進法8進
00 000 Undefined error 01 001 Out of sync. (type code other than B0 through BF). 02 002 Broken sequence (the sequence # field contains the first expected but not received sequence number). 03 003 Illegal DLE sequence (other than DLE DLE or DLE ETX). B0 260 through through The transaction type (indicated by BF 277 by error code) is not implemented.
00 000 同時性の未定義の誤り01 001Out。 (B0からBF以外のコードをタイプします。) 02 002 壊れている系列(系列#分野は最初の予想されましたが、容認されなかった一連番号を含んでいます)。 03 003 不法なDLE系列(DLE DLEかDLE ETXを除いた)。 トランザクションタイプ(エラーコードによってBF277によって示される)で終えたB0 260は実装されません。
The error code transaction is defined only for the purpose of error control. DTP does not require the receiver of an error code to take any recovery action. The receiver may discard the error code transaction. In addition, DTP does not require that sequence numbers be remembered or transmitted.
エラーコードトランザクションは誤り制御の目的のためだけに定義されます。 DTPは、どんな回復行動も取るためにエラーコードの受信機を必要としません。 受信機はエラーコードトランザクションを捨てるかもしれません。 さらに、DTPは、一連番号が覚えていられるか、または伝えられるのを必要としません。
2B.7 Type B6 (abort) transactions have a fixed length of 2 bytes, as shown below. First byte defines transaction type as B6, and second byte defines the abort function.
2B.7タイプB6(中止になる)トランザクションには、2バイトの固定長が以下に示されるようにあります。 最初のバイトはトランザクションタイプをB6と定義します、そして、2番目のバイトは放棄機能を定義します。
+-------------------+--------------------+ | Type | Function | | | | | |R| | | | | |G|E| | | | |F|R|C|U| | | |I|O|O|N| | | |L|U|R|I| | | |E|P|D|T| +-------------------+--------------------+
+-------------------+--------------------+ | タイプ| 機能| | | | | |R| | | | | |G|E| | | | |F|R|C|U| | | |I|O|O|N| | | |L|U|R|I| | | |E|P|D|T| +-------------------+--------------------+
Bhushan, et al. [Page 7] RFC 171 THE DATA TRANSFER PROTOCOL June 1971
Bhushan、他 [7ページ] RFC171データ転送プロトコル1971年6月
The following abort codes are assigned:
以下のアボートコードは割り当てられます:
Abort Code Meaning Hex Octal
コード意味十六進法8進を中止してください。
00 000 Abort preceding transaction 01 001 Abort preceding unit 02 002 Abort preceding record 07 007 Abort preceding group 0F 017 Abort preceding file
00 000は、ファイルに先行する記録的な07 007Abort前のグループ0F017Abortに先行するユニット02 002Abortに先行するトランザクション01 001Abortに先行するのを中止します。
DTP does not require the receiver of an abort to take specific action, therefore sender should not necessarily make any assumptions. The manner in which abort is handled is to be specified by higher-level applications protocols.
DTPは特定の行動を取るためにアボートの受信機を必要としません、したがって、送付者が必ず少しの仮定もするべきであるというわけではありません。 アボートが扱われる方法は、よりハイレベルのアプリケーションプロトコルによって指定されることです。
2B.8 Type B7 (NoOp) transactions are one byte long, and indicate no operation. These may be useful as fillers when byte size used for network connections is other than 8-bits.
2B.8タイプB7(NoOp)トランザクションは、長さ1バイトであり、操作を全く必要としません。 8ビットを除いて、サイズがネットワーク接続に使用したバイトがあるとき、これらはフィラーとして役に立つかもしれません。
3. Initial Connection, Handshake and Error Recovery
3. 初期の接続、握手、およびエラー回復
3A. DTP does not specify the mechanism used in establishing connections. It is up to the applications protocol (e.g., file transfer protocol) to choose the mechanism which suits its requirements. [6]
3A。 DTPは関係を樹立する際に使用されるメカニズムを指定しません。 要件に合うメカニズムを選ぶのはアプリケーションプロトコル(例えば、ファイル転送プロトコル)まで達しています。 [6]
3B. The first transaction after connection is made will be type B3 (modes available). In a full-duplex connection, both server and user will communicate type B3 transactions, indicating modes available for send and receive. In a simplex connection only sender will communicate a type B3 transaction. It is the sender's responsibility to choose a mode acceptable to the receiver. If an acceptable mode is not available or if mode chosen is not acceptable, the connection may be closed. [7]
3B。 接続の後の最初の取引がタイプB3が(利用可能なモード)であるつもりであったなら行われます。 全二重接続では、サーバとユーザが利用可能なモードを示すタイプB3トランザクションを伝える両方が、発信して、受信されます。 シンプレクス接続では、送付者だけがタイプB3トランザクションを伝えるでしょう。 受信機に許容できるモードを選ぶのは、送付者の責任です。許容できるモードが利用可能でないか、または選ばれたモードが許容できないなら、接続は閉店するかもしれません。 [7]
3C. No error recovery mechanisms are specified by DTP. The applications protocol may implement error recovery and further error control mechanisms.
3C。 エラー回復メカニズムは全くDTPによって指定されません。 アプリケーションプロトコルは、エラー回復とさらなる誤り制御がメカニズムであると実装するかもしれません。
END NOTES
終わりの注意
[1] The term transaction is used here to mean a block of data defined by the transfer mode.
[1] 用語トランザクションは、転送モードで定義された1ブロックのデータを意味するのにここで使用されます。
[2] What constitutes a workable subset is entirely governed by the high-level application protocol.
[2] 実行可能な部分集合を構成することがハイレベルのアプリケーション・プロトコルによって完全に管理されます。
Bhushan, et al. [Page 8] RFC 171 THE DATA TRANSFER PROTOCOL June 1971
Bhushan、他 [8ページ] RFC171データ転送プロトコル1971年6月
[3] Transactions suppress the notion of host-IMP messages, and may have a logical interpretation similar to that of flags (and data) defined by Mealy in RFC 91.
[3] トランザクションは、ホスト-IMPメッセージの概念を抑圧して、RFC91でMealyによって定義された旗(そして、データ)のものと同様の論理的な解釈を持っているかもしれません。
[4] This assignment is made to be consistent with the TELNET philosophy of maintaining the integrity of the 128 Network ASCII characters.
[4] 128人のNetwork ASCII文字の保全を維持するTELNET哲学と一致しているのをこの課題をします。
[5] A 72-b9t descriptor field provides a convenient separation of information bits, as 72 is the least common multiple of 8 and 36, the commonly encountered byte sizes on ARPA network host computers.
[5] 72-b9t記述子分野は情報ビットの便利な分離を提供します、72が8と36の最小公倍数であるので一般的に遭遇したバイトはARPAネットワークでホストコンピュータを大きさで分けます。
[6] It is, however, recommended that the standard initial connection protocol be adopted where feasible.
[6] しかしながら、標準の初期の接続プロトコルが可能であるところに採用されることが勧められます。
[7] It is recommended that when more than one mode is available, the sender should choose 'descriptor and count' mode (Type B2 or BA). The 'bitstream' mode (type B0 or B8) should be chosen only when the other two modes cannot be used.
[7] 1つ以上のモードが利用可能であるときに、送付者が'記述子とカウント'モードを選ぶのは(B2かBAをタイプしてください)、お勧めです。 他の2つのモードであるときにだけモード(B0かB8をタイプする)が選ばれるべきである'bitstream'を使用できません。
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Samuel Etler 08/99 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][サミュエル・エトラー08/99によるオンラインRFCアーカイブへの]
Bhushan, et al. [Page 9]
Bhushan、他 [9ページ]
一覧
スポンサーリンク