RFC264 日本語訳
0264 The Data Transfer Protocol. A. Bhushan, B. Braden, W. Crowther,E. Harslem, J. Heafner, A. McKenize, B. Sundberg, D. Watson, J.White. January 1972. (Format: TXT=20907 bytes) (Obsoletes RFC0171) (Obsoleted by RFC0354) (Updated by RFC0310) (Also RFC0265) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Bhushan
Request for Comments: 264 MIT
NIC: 7812 B. Braden
UCLA
W. Crowther
BBN
E. Harslem
J. Heafner
Rand
A. McKenzie
BBN
J. Melvin
SRI
B. Sundberg
Harvard
D. Watson
SRI
J. White
UCSB
15 November 1971
Bhushanがコメントのために要求するワーキンググループA.をネットワークでつないでください: 264 MIT NIC: 7812 B.ブレーデンUCLA W.クラウザーBBN E.Harslem J.Heafner底ならし革A.マッケンジーBBN J.メルビン様のB.SundbergハーバードD.ワトソン様のJ.ホワイトUCSB1971年11月15日
THE DATA TRANSFER PROTOCOL
データ転送プロトコル
This paper is a revision of RFC 171, NIC 6793. The changes to RFC 171 are given below. The protocol is then restated for your convenience.
この紙はRFC171、NIC6793年の改正です。 RFC171への変化を以下に与えます。 そして、プロトコルは便宜のため言い直されます。
CHANGES TO RFC 171
RFC171への変化
1) The sequence number field is changed to 16 bits in the error (Type
B5) transactions, thus resolving the ambiguity in the previous
specification. In addition, the information separators (Type B4)
transactions shall also contain a 16-bit sequence number field.
1) 一連番号分野は誤り(B5をタイプする)トランザクションで16ビットに変わります、その結果、前の仕様であいまいさを取り除きます。 また、さらに、情報分離(B4をタイプする)トランザクションは16ビットの一連番号分野を含むものとします。
2) The modes available (Type B3) transactions shall define only the
modes available for receive, instead of both receive and send. In
simplex connections modes available transactions should not be
sent as they are meaningless. In full-duplex connections, the
modes available transactions are still required.
2) 利用可能な(B3をタイプする)トランザクションが利用可能なモードだけを定義するものとするモードは、受信して、両方の代わりに受信して、発信します。 シンプレクス接続モードで、それらが無意味であるので、利用可能なトランザクションを送るべきではありません。 全二重接続、利用可能なモード、トランザクションがまだ必要です。
3) The code assignments for "End Code" in information separators and
for "function" in abort transactions have been changed to reflect
a numerical order rather than "bit-coding".
3) 「ビットコード化」よりむしろ番号を反映するために情報分離の「エンド・コード」とアボートトランザクションにおける「機能」のためのコード課題を変えました。
4) Minor editorial changes.
4) 小さい方の社説は変化します。
Bhushan, et. al. [Page 1] RFC 264 The Data Transfer Protocol 15 November 1971
et Bhushan、アル。 [1ページ] RFC264データ転送プロトコル1971年11月15日
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 may
provide flexibility in implementation, and reduce complexity.
Separating the data transfer function from the specific
applications functions may also reduce proliferation of programs
and protocols.
リモートジョブエントリ、ファイル転送、ネットワーク・メール・システム、グラフィックス、リモートプログラム実行、およびブロックのデータ端末とのコミュニケーション(特に端末のIMPsの文脈でのプリンタや、カードや、紙テープや、磁気テープ設備などの)のようなさまざまのアプリケーションにおけるデータ転送に、一般的なプロトコルは望ましいです。 すべてを含むファイル転送プロトコルに上のアプリケーションのいくつかかすべてさえ含んでいるのが可能でしょうが、データ転送とアプリケーションの機能の間の分離は、柔軟性を実装に提供して、複雑さを減少させるかもしれません。 また、特定のアプリケーション機能とデータ転送機能を切り離すと、プログラムとプロトコルの増殖は抑えられるかもしれません。
We have therefore defined a data transfer protocol (DTP) which
should be used for transfer of data in file transfer, remote job
entry, and other applications protocols. This paper concerns
itself only with the data transfer protocol. A companion paper
(RFC 265) describes the file transfer protocol.
したがって、私たちはファイル転送、リモートジョブエントリ、および他のアプリケーションプロトコルでデータ転送に使用されるべきであるデータ転送プロトコル(DTP)を定義しました。 この紙は単にデータ転送プロトコルでタッチしています。 仲間論文(RFC265)はファイル転送プロトコルについて説明します。
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メッセージの便利な分離に備えます、とデータと制御情報の分離のために許容します、そして、いくつかの誤り制御メカニズムを含んでいます。
Transfer Modes
転送モード
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) convention. 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
2番目のモードは「透明な」ブロックコンベンション、ASCII DLEと同様(データLink Escape)のコンベンションを利用します。 「透明な」モードに、キャラクタシーケンスDLE ETXが遭遇する(DLEとETXはキャラクタがコード化する8ビットです)ときはいつも、トランザクション(任意に長いかもしれない)は終わります。 データ・ストリームの中に起こるDLE ETX系列の可能性を防ぐために、トランスミッションのときにDLEのどんな発生もDLE DLEに取り替えます。 レセプションで付加的なDLEを剥取ります。 ASCIIコンベンションからの出発はそれです。
Bhushan, et. al. [Page 2] RFC 264 The Data Transfer Protocol 15 November 1971
et Bhushan、アル。 [2ページ] RFC264データ転送プロトコル1971年11月15日
"transparent" block does not begin with DLE STX, but with a
transaction type byte. This mode would be useful in data transfer
between terminal IMPs.
「透明な」ブロックは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 (i.e., not
information) bits. If a transaction has no filler bits, its
filler count is zero. This mode would be useful in most host-to-
host data transfer applications.
3番目のモードはカウントメカニズムを利用します。 固定長記述子分野が情報ビットとフィラー(すなわち、情報でない)ビットの別々の2進のカウントを含んでいて、各トランザクションは始まります。 トランザクションにフィラービットが全くないなら、フィラーカウントはゼロです。 このモードはホストからホストへのデータ転送ほとんどのアプリケーションで役に立つでしょう。
DTP allows for transfer modes to be intermixed over the same
connection (i.e., the transfer mode is not associated with
connection, but only with transaction). The transfer modes can
represent transfer of either data or control information. The
protocol allows for separating data and 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 subset of transfer modes is specifically
permitted by DTP. To provide compatibility between hosts using
different subsets of transfer modes, an initial "handshake"
procedure may be used. The handshake involves exchanging
information on modes available for receive. This will enable host
programs to agree on transfer modes acceptable for a connection.
転送モードの部分集合の実装はDTPによって明確に可能にされます。 転送モードの異なった部分集合を使用することでホストの間の互換性を提供するために、初期の「握手」手順は用いられるかもしれません。 握手は、モードで情報交換することを利用可能な状態で伴います。受信してください。 これは、ホストプログラムが接続において、許容できる転送モードに同意するのを可能にするでしょう。
Using DTP
DTPを使用します。
The manner in which DTP is used would depend largely on the
applications protocol. It is the applications protocol which
defines the use of transfer modes and the use of information
separator and abort functions provided in DTP (see
SPECIFICATIONS). For example, in a remote job entry protocol,
aborts may be used to stop the execution of a job, while they may
not cause any action in another applications protocol.
DTPが使用されている方法は主にアプリケーションプロトコルによるでしょう。 それはDTPに提供された転送モードの使用と情報分離と放棄機能の使用を定義するアプリケーションプロトコル(SPECIFICATIONSを見る)です。 例えば、リモートジョブエントリプロトコルに、アボートは仕事の実行を止めるのに使用されるかもしれません、別のアプリケーションプロトコルにおける少しの動作も引き起こさないかもしれませんが。
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 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
制限が全くDTPが様々なサイトで実装される方法にないでしょう。 それは、数個によって使用される例えば、DTPがファイル転送などのアプリケーションプログラムで埋め込まれるかもしれませんか、別々のサービス・プログラムかサブルーチンであるかもしれません。
Bhushan, et. al. [Page 3] RFC 264 The Data Transfer Protocol 15 November 1971
et Bhushan、アル。 [3ページ] RFC264データ転送プロトコル1971年11月15日
applications programs. Another implementation may employ macros
or UUO's (unimplemented user 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で指定された機能を獲得するのに、マクロか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
bits. However, other byte sizes specified by applications
protocols 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 a connection is
a sequence of transactions. DTP defines the rules for
delimiting transactions.
DTPレベルでは、接続の上に伝えられたすべての情報がトランザクションの系列です。 DTPは、トランザクションを区切るために規則を決めます。
2A. Types
2A。 タイプ
The first 8-bit 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 will be referred to by the hexadecimal code
assigned to them. (The transaction types are discussed in more
detail in Section 2B.)
それぞれのトランザクションの最初の8ビットのバイトは以下に示されるようにトランザクションタイプを定義するものとします。 (コード課題がTELNETプロトコルにおける課題と衝突しないことに注意してください。) トランザクションタイプは彼らに割り当てられた16進コードによって言及されるでしょう。 (さらに詳細にセクション2B.でトランザクションタイプについて議論します)
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.
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
through through Unassigned but reserved for DTP.
BF 277
B0 260の無期ビットストリーム--データ。 B1 261見え透いた(DLE)ブロック--データ。 B2 262記述子とカウント--データ。 利用可能なB3 263モード(握手)。 B4 264情報分離。 B5 265エラーコード。 B6 266は中止になります。 B7 267いいえ操作(NoOp)。 B8 270の無期ビットストリーム--制御してください。 透明な(DLE)が妨げるB9 271--制御してください。 BA272Descriptorとカウント--制御してください。 DTPのためのUnassignedにもかかわらず、予約にされるを通して終えた掲示板273。 BF277
Bhushan, et. al. [Page 4] RFC 264 The Data Transfer Protocol 15 November 1971
et Bhushan、アル。 [4ページ] RFC264データ転送プロトコル1971年11月15日
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 the closing of a connection in bitstream
mode is an implicit file separator (see Section 2B.5).
2B.1はB0をタイプします、そして、NCP接続が「閉じられる」ときだけ、B8(無期bitstreamモード)トランザクションは終わります。 このレベルでDTPで定義された他のエスケープコンベンションは全くありません。 bitstreamモードにおける、接続の閉鎖が暗黙のファイル分離文字(セクション2B.5を見る)であることに注意されるべきです。
2B.2 Type B1 and B9 (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 be 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). [2] ETX is Hex '03' or
Octal '03' (the same as ASCII ETX).
2B.2はB1をタイプします、そして、バイト列DLE ETXが遭遇するとき、B9(見え透いたブロックモード)トランザクションは終わります。 送付者は系列DLE DLEによるデータ・ストリームにおける、DLEのどんな発生にも取って代わるものとします。 受信機は付加的なDLEを剥取るものとします。 トランザクションがバイト指向であると思われます。 'DLEのためのコードはHex90年です'かOctalが'220'である、(これが'Hex10年OctalであるASCII DLEと異なっている、020年) [2] ETXはHex'03'かOctal'03'です(ASCII ETXと同じ)。
2B.3 Type B2 and BA (descriptor and counts modes) transactions have
three fields, a 9-byte (72-bit) descriptor field (as shown
below) and variable length (including zero) info and filler
fields. The total length of a transaction is (72+info+filler)
bits.
2B.3はB2をタイプします、そして、BA(記述子とカウントモード)トランザクションには、3つの分野、9バイト(72ビット)の記述子分野(以下に示すように)と可変長(ゼロを含んでいる)インフォメーション、およびフィラー分野があります。 トランザクションの全長は(72+インフォメーション+フィラー)ビットです。
|<B2 or BA>|<Info count>| <NUL> <Sequence #>| <NUL> |<filler count>| |<-8-bit-> |<--24-bit-->|<8-bit><--16-bit-->|<8-bit>|<---8-bit---->| |<--------------------72-bit descriptor field--------------------->|
| <B2かBa>|<インフォメーションカウント>| <NUL><系列#>| <NUL>。|<フィラーカウント>| | <、-8ビットの>。| <--24ビット-->|<の8ビットの><--16ビット-->|<8ビット>| <、-、--8ビットです。---->| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--72ビットの記述子分野--------------------->|
_Info count_ is a binary count of the number of bits in the
info field, not including descriptor or filler bits. The
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,
BA, and B4 type transactions. The inclusion of sequence
numbers will 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, all 1's, and zero for the
first transaction only.
_Sequence #_ is a sequential count in round-robin manner of B2, BA, and B4 type transactions. 一連番号の包含はデバッグと誤り制御で助けるでしょう、一連番号がなくなったトランザクションと援助がないかどうか誤りの場所を見つける際にチェックするのに使用されるとき。 このメカニズムを実装したがっていないホストはその分野にすべての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に制限されます。
Bhushan, et. al. [Page 5] RFC 264 The Data Transfer Protocol 15 November 1971
et Bhushan、アル。 [5ページ] RFC264データ転送プロトコル1971年11月15日
The NUL bytes must contain all 0's.
NULバイトはすべての0を含まなければなりません。
2B.4 Type B3 (modes available) transactions have a fixed length of
two bytes, as shown below. First byte defines the transaction
type B3, and second byte defines the transfer modes available
for receive.
2B.4タイプB3(利用可能なモード)トランザクションには、2バイトの固定長が以下に示されるようにあります。 最初のバイトはトランザクションタイプB3を定義します、そして、バイトが利用可能な転送モードを定義する2番目は受信されます。
+-----------------+---------------------+
|Type | I receive |
| B3 | |
| |0|0|BA|B2|B9|B1|B8|B0|
+-----------------+---------------------+
+-----------------+---------------------+ |タイプ| 私は受信します。| | B3| | | |0|0|Ba|B2|B9|B1|B8|B0| +-----------------+---------------------+
The modes are indicated by bit-coding, as shown above. The
particular bits, if set to logical "1", indicate that the
corresponding modes are handled by the sender's receive side.
The two most significant bits should be set to logical "0".
Mode available transactions have no significance in a simplex
connection. The use of type B3 transactions is discussed in
section 3B.
モードは上に示されるようにコード化することで噛み付いている示されます。 特定のビット論理的な「何1インチも、対応するモードが扱われて、送付者のものが側を受け取るということであることを示してください」に設定されるなら。 2つの最上位ビットが論理的な「0インチ」に設定されるべきです。 モードの利用可能なトランザクションには、シンプレクス接続における意味が全くありません。 セクション3BでタイプB3トランザクションの使用について議論します。
2B.5 Type B4 (information separator) transactions have a fixed
length of four bytes, as shown below. First byte defines the
transaction type B4, second byte defines the separator, and
third and fourth bytes contain a 16-bit sequence number.
2B.5タイプB4(情報分離)トランザクションには、4バイトの固定長が以下に示されるようにあります。 最初のバイトはトランザクションタイプB4を定義します、そして、2番目のバイトは分離符を定義します、そして、3番目と4番目のバイトは16ビットの一連番号を含んでいます。
+------------+------------+-------------------------+
|Type | End Code | Sequence Number |
| B4 | | | |
| | | | |
+------------+------------+------------+------------+
+------------+------------+-------------------------+ |タイプ| エンド・コード| 一連番号| | B4| | | | | | | | | +------------+------------+------------+------------+
The following separator codes are assigned:
以下の分離符コードは割り当てられます:
Code Meaning
Hex Octal
意味十六進法8進をコード化してください。
01 001 Unit separator
02 002 Record separator
03 003 Group separator
04 004 File separator
01 001ユニット分離文字02 002Record分離符03 003Group分離符04 004File分離符
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.
ファイル、グループ、レコード、およびユニットはユーザがしたがって、であるなるように定義するデータ・ブロックであるかもしれません。 唯一の制限が上下関係File>Groups>Records>Units('>'が'含有'を意味するところ)のものです。 したがって、ファイル分離文字はファイルの終りだけではなく、グループ、記録、およびユニットの端を示します。
Bhushan, et. al. [Page 6] RFC 264 The Data Transfer Protocol 15 November 1971
et Bhushan、アル。 [6ページ] RFC264データ転送プロトコル1971年11月15日
These separators may provide a convenient "logical" separation
of data at the data transfer level. Their use is governed by
the applications protocol.
これらの分離符はデータ転送レベルでデータの便利な「論理的な」分離を提供するかもしれません。 彼らの使用はアプリケーションプロトコルによって管理されます。
2B.6 Type B5 (error codes) transactions have a fixed length of four
bytes, as shown below. First byte defines the transaction type
B5, second byte indicates an error code, and third and fourth
bytes may indicate the sequence number of a transaction in
which an error occurred.
2B.6タイプB5(エラーコード)トランザクションには、4バイトの固定長が以下に示されるようにあります。 最初のバイトはトランザクションタイプB5を定義します、そして、2番目のバイトはエラーコードを示します、そして、3番目と4番目のバイトは誤りが発生したトランザクションの一連番号を示すかもしれません。
+------------+------------+-------------------------+
|Type | End Code | Sequence Number |
| B5 | | | |
| | | | |
+------------+------------+------------+------------+
+------------+------------+-------------------------+ |タイプ| エンド・コード| 一連番号| | B5| | | | | | | | | +------------+------------+------------+------------+
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 DLF sequence (other than DLE
DLE or DLE FTX).
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 不法なDLF系列(DLE DLEかDLE FTXを除いた)。 トランザクションタイプ(エラーコードによって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 two bytes,
as shown below. First byte defines the transaction type B6,
and second byte defines the abort function.
2B.7タイプB6(中止になる)トランザクションには、2バイトの固定長が以下に示されるようにあります。 最初のバイトはトランザクションタイプB6を定義します、そして、2番目のバイトは放棄機能を定義します。
+------------+------------+
|Type | Function |
| B6 | |
| | |
+------------+------------+
+------------+------------+ |タイプ| 機能| | B6| | | | | +------------+------------+
Bhushan, et. al. [Page 7] RFC 264 The Data Transfer Protocol 15 November 1971
et Bhushan、アル。 [7ページ] RFC264データ転送プロトコル1971年11月15日
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
03 003 Abort preceding group
04 004 Abort preceding file
00 000は、記録的な03 003Abort前のグループ04 004のAbortの前のファイルに先行するユニット02 002Abortに先行するトランザクション01 001Abortに先行するのを中止します。
DTP does not require the receiver of an abort to take specific
action, therefore a sender should not make any assumptions
thereof. 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 (8-bit) long, and
indicate no operation. These may be useful as fillers when the
byte size used for network connections is other than 8-bits.
2B.8タイプB7(NoOp)トランザクションは、長さ1バイトであり(8ビット)、操作を全く必要としません。 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. [3]
3A。 DTPは関係を樹立する際に使用されるメカニズムを指定しません。 要件に合うメカニズムを選ぶのはアプリケーションプロトコル(例えば、ファイル転送プロトコル)まで達しています。 [3]
3B. The first transaction after a full-duplex connection is made
will be type B3 (modes available) indicating the transfer modes
available for receive. The modes available (Type B3)
transaction is not applicable in simplex connections. It is
the sender's responsibility to choose a mode acceptable to the
receiver. [4] If an acceptable mode is not available or if
mode chosen is not acceptable, the connection may be closed.
3B。 全二重接続がことになった人工であることが、利用可能な状態で転送モードを示すB3(利用可能なモード)をタイプすることであるという後に最初のトランザクションは受信されます。 モード、利用可能な(B3をタイプする)トランザクションはシンプレクス接続で適切ではありません。 受信機に許容できるモードを選ぶのは、送付者の責任です。[4] 許容できるモードが利用可能でないか、または選ばれたモードが許容できないなら、接続は閉店するかもしれません。
3C. No error recovery mechanisms are specified by DTP. The
applications protocol may implement error recovery and further
error control mechanisms.
3C。 エラー回復メカニズムは全くDTPによって指定されません。 アプリケーションプロトコルは、エラー回復とさらなる誤り制御がメカニズムであると実装するかもしれません。
Bhushan, et. al. [Page 8] RFC 264 The Data Transfer Protocol 15 November 1971
et Bhushan、アル。 [8ページ] RFC264データ転送プロトコル1971年11月15日
Endnotes
エンドノート
[1] The term transaction is used here to mean a block of data defined by the transfer mode.
[1] 用語トランザクションは、転送モードで定義された1ブロックのデータを意味するのにここで使用されます。
[2] This assignment was made to be consistent with the TELNET philosophy of maintaining the integrity of the 128 Network ASCII characters.
[2] 128人のNetwork ASCII文字の保全を維持するTELNET哲学と一致しているのをこの課題をしました。
[3] It is, however, recommended that the standard Initial Connection Protocol as specified in RFC 165 or any subsequent standard document be adopted where feasible.
[3] しかしながら、RFC165の指定されるとしての標準のInitial Connectionプロトコルかどんなその後の標準のドキュメントも可能であるところに採用されることが勧められます。
[4] It is suggested that when available, the sender should choose 'descriptor and count' mode (Type B2 or BA). The 'indefinite bitstream' mode (Type B0 or B8) should be chosen only when the other two modes are not available.
[4] 利用可能であるときに、送付者が'記述子とカウント'モードを選ぶべきである(B2かBAをタイプする)と示唆されます。 他の2つのモードが利用可能でないときにだけモード(B0かB8をタイプする)が選ばれるべきである'無期bitstream'。
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Ryan Kato 6/01 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ライアン・加藤6/01によるオンラインRFCアーカイブへの]
Bhushan, et. al. [Page 9]
et Bhushan、アル。 [9ページ]
一覧
スポンサーリンク
