RFC107 日本語訳
0107 Output of the Host-Host Protocol Glitch Cleaning Committee. R.D.Bressler, S.D. Crocker, W.R. Crowther, G.R. Grossman, R.S. Tomlinson,J.E. White. March 1971. (Format: TXT=18109 bytes) (Updates RFC0102) (Updated by RFC0111, RFC0124, RFC0132, RFC0154, RFC0179) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Request for Comments # 107
コメント#107を求めるネットワークワーキンググループ要求
NIC # 5806
NIC#5806
Output of the Host-Host Protocol
Glitch Cleaning Committee
ホスト兼ホストプロトコル不調掃除委員会の出力
UCLA
23 March 1971
UCLA1971年3月23日
Robert Bressler
Steve Crocker
William Crowter
Gary Grossman
Ray Tomlinson
James Withe
ロバートBresslerスティーブ医者ウィリアムCrowterゲーリーグロースマンレイトムリンスンジェームス小枝
[Page 1]
Introduction
[1ページ] 序論
The Host-Host Protocol Glitch Cleaning Committee met for the second time at UCLA on 8, 9 March 1971, after canvassing the network com- munity. [The result of the (slightly larger) committee's first meeting are documented in RFC #102.] The committee agreed on several modifications to the protocol in Document #1; these modi- fications are listed below.
Host-ホストプロトコルGlitch Cleaning Committeeは2回目に8でUCLAで会いました、1971年3月9日、ネットワークcom- munityを求めた後に。 [(わずかに大きい)の委員会の最初のミーティングの結果はRFC#102に記録されます。] 委員会はDocument#1におけるプロトコルへのいくつかの変更に同意しました。 これらのmodi- ficationsは以下に記載されています。
At each of the meeting, the committee quickly treated all but one of the extant topics. At the first meeting, the bulk of time was spent considering the interrupt mechanism, and that discussion is summarized in RFC #102. At the second meeting, the committee spent almost all of its time discussing the notion of bytes; this dis- cussion is summarized after the list of modifications.
それぞれのミーティングでは、委員会はすぐに実在の話題の1つ以外のすべてを扱いました。 最初のミーティングでは、中断メカニズムを考える場合、時間の大半が費やされて、その議論はRFC#102でまとめられます。 2番目のミーティングでは、委員会はバイトの概念について議論するのに時間のほとんどすべてを費やしました。 この不-cussionは変更箇所一覧の後にまとめられます。
This RFC entirely supercedes RFC #102, and is an official modi- fication of Document #1. A revision of Document #1 will be written shortly which incorporates the changes listed here.
このRFC、完全にsupercedes RFC#102、Document#1が公式のmodi- ficationがあります。 ここに記載された変化を取り入れるDocument#1の改正はまもなく、書かれるでしょう。
NCP implementers are to incorporate these changes as soon as possible. NCP implementers also are to estimate on what date theis NCP's will be ready and to communicate this estimate to Steve Crocker or his secretary, Byrna Kristel.
NCP implementersはできるだけ早く、これらの変化を取り入れることになっています。 NCP implementersもtheis NCPのどんな日付のものが準備ができるかに関して見積もって、この見積りにスティーブ・クロッカーか彼の秘書に伝えることになっています、Byrnaクリステル。
[Page 2]
Modifications
[2ページ] 変更
I Bytes
Iバイト
Heretofore, a connection has been a bit stream. Henceforth, it is to be a byte stream, with the byte size, S, indicated in the STR command and in each message. The byte size meets the constraints: 1 <= S <= 255.
これまで、接続は少し流れることです。 今後は、それによるバイト・ストリームであることになっています、バイトサイズ、STRコマンドと各メッセージで示されたSと共に。 バイトサイズは規制を満たします: 1 <はS<=255と等しいです。
The choice of the byte size for a connection is a 3rd level protocol issue, but the size is constant for the life of a connection. Each message must contain an integral number of text bytes (see below).
接続のためのバイトサイズの選択は3番目の平らなプロトコル問題ですが、サイズは接続の人生で一定です。 各メッセージは整数のテキストバイトを含まなければなりません(以下を見てください)。
II Message Format
IIメッセージ・フォーマット
The message format is changed to the format shown in figure 1.
メッセージ・フォーマットは図1に示された書式に変わります。
The fields S and C are the byte size and byte count, respectively. The S field is 8 bits wide and must match the byte size specified in the STR which created the connection. The C field is 16 bit long and specifies the number of bytes in the text portion of the message. A zero value in the C field serves no purpose, but is explicitly permitted.
分野SとCはサイズとバイトがそれぞれ数えるバイトです。 S分野は、幅8ビットであり、サイズが接続を創造したSTRで指定したバイトに合わなければなりません。 C分野は、長さ16ビットであり、メッセージのテキスト部分でバイト数を指定します。 C分野で目的に全く役立ちませんが、明らかに受入れられますゼロが、評価する。
The M1 and M2 field are each 8 bits long and must contain zero. The M3 field is zero or more bits long and must be all zero. The M3 may be used to fill out a message to a word boundary. It is followed by padding.
M1とM2分野は、長さ各8ビットであり、ゼロを含まなければなりません。 M3分野は、すべてゼロであるに違いありませんゼロか、より多くの長さビットであり。 M3は、メッセージを語境界に書き込むのに使用されるかもしれません。 詰め物はそれのあとに続いています。
The text field consists of C bytes, where each byte is S bit long. The text field starts 72 bits after the start of the message.
テキストフィールドは各バイトが長い間噛み付かれたSであるところでCバイトから成ります。 テキストフィールドはメッセージの始まりの72ビット後に始まります。
The partition of a byte stream into messages is an artifact required by the subnet. No semantic contents be attacched to message boundaries. In particular,
メッセージへのバイト・ストリームのパーティションはサブネットによって必要とされた人工物です。 どんな意味内容、もメッセージ限界にattacchedされません。 特に
[Page 3]
32 bits
|<--------------------------------->|
[3ページ] 32ビット|<--------------------------------->|
+-----------------------------------+
| |
| leader |
| |
+--------+--------+-----------------+
| | | |
| M1 | S | C |
| | | |
+--------+--------+-----------------+
| | ^ |
| M2 | | |
| | | |
+--------+ | |
| | |
| | |
| |
| Text |
// //
| | |
| | |
| | |
| | |
| | +--------+
| | | |
| | | M3 |
| v | |
+-----------------+--------+--------+
| |
| 10 --------- 0 | <-- Padding
| |
+-----------------+
+-----------------------------------+ | | | リーダー| | | +--------+--------+-----------------+ | | | | | M1| S| C| | | | | +--------+--------+-----------------+ | | ^ | | M2| | | | | | | +--------+ | | | | | | | | | | | テキスト| // // | | | | | | | | | | | | | | +--------+ | | | | | | | M3| | v| | +-----------------+--------+--------+ | | | 10 --------- 0 | <-- 詰め物| | +-----------------+
Typical Message
典型的なメッセージ
Figure 1
図1
[Page 4]
1. A message with a zero value for C has no meaning, although
it is legal and it does use up resource allocation. (See
Flow Control below.)
[4ページ] 1。 それが法的であり、資源配分を使いきりますが、C値には意味でないのがあるというゼロがあるメッセージ。 (以下のFlow Controlを見てください。)
2. A receiver may not expect to see 3rd level control infor-
mation synchronized with message boundaries. Particuralrly,
if the notion of record is defined for a connection, the
receiver must expect multiple records and/or record frag-
ments within one message. (However, control message obey
special rules. See below.)
2. 受信機は、3番目のレベルコントロールinfor- mationがメッセージ限界に連動するのを見ると予想しないかもしれません。 Particuralrlyに、記録の概念が接続のために定義されるなら、受信機は、複数の記録、そして/または、記録が1つのメッセージの中でmentsを破片手榴弾で殺傷すると予想しなければなりません。 (しかしながら、コントロールメッセージは特別な規則に従います。 以下を見てください。)
III Message Data Types
IIIメッセージデータ型
No notion of data type is defined as part of the 2nd level pro- tocol. 3rd level protocols may include the notion. Data types cannot be synchronized on message boundaries.
データ型の概念は全く2番目の平らな親tocolの一部と定義されません。 3番目の平らなプロトコルは概念を含むかもしれません。 データ型はメッセージ限界で同期できません。
IV Reset and Reset Reply
IVリセットとリセットは返答します。
A new pair of one bit control commands RST (reset) and RRP (reset reply) are added. The RST is interpreted as a signal to purge the NCP tables of all existing entries which arose from the Host which sent to RST. The Host receiving the RST acknowledges by returning a RRP. The Host sending the RST may proceed to request connection after receiving either a RST or RRP in return. An RST is returned if the second Host comes up after the first Host.
1つのビット制御の新しいペアは、RST(リセット)とRRP(リセット回答)が加えられると命令します。 RSTは、NCPテーブルからRSTに発信したHostから起こったすべての既存のエントリーを一掃するために信号として解釈されます。RSTを受けるHostは戻るのによるRRPを承認します。 代わりにRSTかRRPのどちらかを受けた後に、RSTを送るHostは接続を要求するかもしれなくしかけます。 第2Hostが最初のHostの後に来るなら、RSTを返します。
V Flow Control
Vフロー制御
The flow control techniques are changed in two ways. First, the Cease mechanism is discontinued. The 10HI and 11HI message will no longer be recognized by the Imps, and the Imps will no loger generate the 10HI, 11HI or 12HI messages.
2つの方法でフロー制御のテクニックを変えます。 まず最初に、Ceaseメカニズムは中止されます。 10HIと11HIメッセージはもうImpsによって認識されないでしょう、そして、Impsは10HI、11HIまたは12HIメッセージをより多くのlogerに発生させないでしょう。
[Page 5]
Second, the allocation mechanism now deals with two quantities, bits
and messages. The receiver allocates each of these quantities
separately. The sender and receiver each must mantain a 16 bit
unsigned counter for message and a 32 bit unsigned counter for bits.
When sending a message, the sender subtract one from the message
counter, and the text length from the bit counter. The receiver
decrements his counter similarly when receiving the message. The
sender is prohibited from sending if either counter would be decre-
mented below zero. Similarly, the receiver is prohibited from raising
the current message allocation above 2**16 - 1, or the current bit
allocation above 2**32 - 1.
[5ページ] 2番目に、配分メカニズムは現在、2つの量、ビット、およびメッセージに対処します。 受信機は別々にそれぞれのこれらの量を割り当てます。 それぞれ送付者と受信機はメッセージと32ビットにおける、無記名の16ビットの無記名のカウンタが何ビットも打ち返すmantainがそうしなければなりません。 メッセージを送る送付者は、メッセージカウンタから1つを引いて、ビットからテキストの長さを引くときには、反対してください。 メッセージを受け取るとき、受信機は彼のカウンタを同様に減少させます。 送付者は零下でどちらかのカウンタがdecre- mentedであるなら発信するのから禁じられます。 同様に、受信機は、2**16--1の上で現在のメッセージ配分を上げるか、または2**32--1の上で現在の噛み付いている配分を上げるのが禁止されています。
The TEXT LENGTH of a message is the product of S, the byte size, and C, the number of bytes. These values always appear in the first part of the message, as described under Message Format.
メッセージのTEXT LENGTHはSの製品と、バイトサイズと、C、バイト数です。 これらの値はMessage Formatの下で説明されるようにメッセージの最初の部分でいつも見えます。
The ALL, GVB, and RET command are modified to treat two quantities. Their formats are given under Control Command, below. The GVB command is further modified to make it possible to ask for none of the allocation to be returned. The new GVB command has four eight bit fields. The first two fields are the op code and the link, as before. The next two fields contain number fM and fB which control how much of message and a bit allocation are to be returned. Each of these numbers is interpreted as "the number of 128ths of the current allocation" to be returned if it is in the range of 0 to 128, and is to be interpreted as "all of the current allocation", if it is in the range 128 to 255.
すべて、GVB、およびRETコマンドは、2つの量を扱うように変更されます。 以下のControl Commandの下でそれらの書式を与えます。 GVBコマンドは、配分のいずれも返されないように頼むのを可能にするようにさらに変更されます。 新しいGVBコマンドには、8ビットの4つの分野があります。 最初の2つの分野が、従来と同様オペコードとリンクです。 次の2つの分野がどのくらい制御するメッセージの数のfMとfBを含んでいます、そして、配分は少し、返すことです。 それぞれのこれらの数はそれが0〜128の範囲にあるなら返されて、「現在の配分のすべて」として解釈されることになっているために「現在の配分の128thsの数」として解釈されます、それが範囲に128〜255にあるなら。
VI Control Message
VIコントロールメッセージ
The control link is chsnged to link 0; link 1 is not to be used. The old and new protocols may thereforre coexist.
コントロールリンクは0をリンクするためにchsngedされます。 リンク1は使用されていることになっていません。 古くて新しいプロトコルはthereforreに共存するかもしれません。
[Page 6]
Message sent over the control link have the same format as other
regular messages, as described above under Message Format. The byte
size field must contain the value 8.
メッセージがコントロールリンクの上に送った[6ページ]は他の通常のメッセージと同じ形式を持っています、Message Formatの下で上で説明されるように。 バイトサイズ分野は値8を含まなければなりません。
Control messages may not contain more tha 120 byte of text; the value in the byte count field is thus limited to 120. This limi- tation is intended to help smaller hosts.
コントロールメッセージはテキストのtha120バイトをさらに含まないかもしれません。 バイト・カウント分野の値はこのようにして120に制限されます。 このlimi- tationが、より小さいホストを助けることを意図します。
Control messages must contain an integral number of control commands. Control commands, therefore, may not be split across control messages.
コントロールメッセージは整数の制御コマンドを含まなければなりません。 したがって、制御コマンドはコントロールメッセージの向こう側に分けられないかもしれません。
VII Link Assignment
VIIリンク課題
The link are now assigned as follows:
リンクは現在、以下の通り割り当てられます:
0 control link
1 old protocol's control link - to be phased out
2 - 31 links for connections
32 - 190 reserved -- not for current use
191 to be used only for measurement work under direction
of the network measurement center (UCLA)
192 - 255 available for any private experimental use.
0 コントロールは、どんな個人的な実験用にも利用可能な(UCLA)192--255のネットワーク測定センターの指示に基づく測定仕事にだけ使用されるために、現在の使用191でない段階的に廃止されるために、2--31に32--190が控えた接続のためにリンクされるという1つの古いプロトコルのコントロールリンクをリンクします。
VIII Fixed Length Control Commands
VIII固定長制御コマンド
The ECO, ERP and ERR commands are now fixed length. The ECO and ERP are now 16 bit long -- 8 bits of op code and 8 bits of data. The ERR command is now 96 bits long -- 8 bits of op code, 8 bits of error code, and 80 bits of text. 80 bits is long enough to hold the longest non-ERR control command.
現在、ECO、ERP、およびERRコマンドは固定長です。 ECOとERPは現在、長さ16ビットです--データのオペコードと8ビットの8ビット。 ERRコマンドは現在、長さ96ビットです--オペコードの8ビット、エラーコードの8ビット、およびテキストの80ビット。 80ビットは最も長い非ERR制御コマンドを保持できるくらい長いです。
[Page 7]
IX Control Command Formats
[7ページ] IX制御コマンド形式
As mentioned above, the formats of the STR, ALL, GVB, RET, ECO, ERP and ERR commands have changed; and the commands RST and RRP have been added. The formats of these commands are given here.
以上のように、STR、すべて、GVB、RET、ECO、ERP、およびERRコマンドの形式は変化しました。 そして、コマンドのRSTとRRPは加えられます。 これらのコマンドの書式をここに与えます。
| 8 | 32 | 32 | 8 |
+-----+-----------------------+-----------------------+-----+
| | | | |
1. | STR | send socket | receive socket | |
| | | | ^ |
+-----+-----------------------+-----------------------+--|--+
|
| 8 | 8 | 16 | 32 | +-- byte size
+-----+-----+-----------+-----------------------+
| | | | |
2. | ALL | link| msg space | bit space |
| | | | |
+-----+-----+-----------+-----------------------+
| 8 | 32 | 32 | 8 | +-----+-----------------------+-----------------------+-----+ | | | | | 1. | STR| ソケットを送ってください。| ソケットを受けてください。| | | | | | ^ | +-----+-----------------------+-----------------------+--|--+ | | 8 | 8 | 16 | 32 | +--バイトサイズ+-----+-----+-----------+-----------------------+ | | | | | 2. | すべて| リンク| msgスペース| 噛み付いているスペース| | | | | | +-----+-----+-----------+-----------------------+
| 8 | 8 | 16 | 32 |
+-----+-----+-----------+-----------------------+
| | | | |
3. | RET | link| msg space | bit space |
| | | | |
+-----+-----+-----------+-----------------------+
| 8 | 8 | 16 | 32 | +-----+-----+-----------+-----------------------+ | | | | | 3. | 浸水してください。| リンク| msgスペース| 噛み付いているスペース| | | | | | +-----+-----+-----------+-----------------------+
| 8 | 8 | 8 | 8 |
+-----+-----+-----+-----+
| | | | |
4. | GVB | link| fM | fB |
| | | ^ | ^ |
+-----+-----+--|--+--|--+
| |
| +-- bit fraction
+-------- message fraction
| 8 | 8 | 8 | 8 | +-----+-----+-----+-----+ | | | | | 4. | GVB| リンク| fM| fB| | | | ^ | ^ | +-----+-----+--|--+--|--+ | | | +--噛み付いている断片+-------- メッセージ断片
| 8 | 8 |
+-----+-----+
| | |
5. | ECO |data |
| | |
+-----+-----+
| 8 | 8 | +-----+-----+ | | | 5. | エコ|データ| | | | +-----+-----+
[Page 8]
| 8 | 8 |
+-----+-----+
| | |
6. | ERP |data |
| | |
+-----+-----+
[8ページ]| 8 | 8 | +-----+-----+ | | | 6. | ERP|データ| | | | +-----+-----+
| 8 | 8 | 80 |
+-----+-----+---------------------- // -----------------------+
| | | |
7. | ERR | | text |
| | ^ | |
+-----+--|--+---------------------- // -----------------------+
|
+-- error code
| 8 | 8 | 80 | +-----+-----+---------------------- // -----------------------+ | | | | 7. | 間違えてください。| | テキスト| | | ^ | | +-----+--|--+---------------------- // -----------------------+ | +--エラーコード
| 8 |
+-----+
| |
8. | RST |
| |
+-----+
| 8 | +-----+ | | 8. | RST| | | +-----+
| 8 |
+-----+
| |
9. | RRP |
| |
+-----+
| 8 | +-----+ | | 9. | 小売希望価格| | | +-----+
The values of the op codes are
オペコードの値はそうです。
NOP = 0
RTS = 1
STR = 2
CLS = 3
ALL = 4
GVB = 5
RET = 6
INR = 7
INS = 8
ECO = 9
ERP = 10
ERR = 11
RST = 12
RRP = 13
9 8 7 6 4すべて=GVB=5が浸水させる2 1 0NOP=RTS=STR=CLS=3=INR=インス=エコ=ERP=10が間違える、12=11RST=小売希望価格=13
[Page 9]
Discussion on Byte Streams
[9ページ] バイト・ストリームについての議論
The previous specification that connections would be conduits of bit streams provided maximum generality and minimum efficiency. Pressure for greater efficiency developed and the problen was examined.
接続がビットストリームの導管が提供された最大の一般性と最小の効率であるならそうする前の仕様。 より大きい効率に対する圧力は発生しました、そして、problenは調べられました。
Two separate kinds of inefficiency arose from bit streams.
別々の2種類の非能率はビットストリームから起こりました。
1. Receiving Hosts were equired to engage in expensive
shifting to concatenate the texts of successive
messages. Sending Hosts often also had to shift text
fields to align them on word boundaries.
1. Hostsを受けるのは、連続したメッセージのテキストを連結するのを高価な移行に従事するためにequiredされました。 しばしばHostsをまた送ると、テキストフィールドは、それらを語境界に並べるために移行しなければなりませんでした。
2. Sending NCP's were prohibited from hanging onto ANY
text for an indefinite time if it were possible to send
even one bit. This requirement was necessary to prevent
possible deadlocks. For example, suppose processes A
and B have a conversation in progress over a pair of
connections, one in each directions. Also suppose that
these processes produce exactly one bit of output for
each bit of input. Then if A's NCP fails to send a
waiting bit because it wants to pack it together with
later output from A, then B will not be able to output
and neither will A. It is clear then, that unless there
is some quantitee that the data in the sending NCP's
buffers are not crucially needed on the receive side, the
sending NCP must assume otherwise and transmit any
waiting data as soon as it is able.
2. 送付NCPは無期限にそれが1ビットさえ発信するのにおいて可能であるならどんなテキストにもすがりつくのが禁止されました。 この要件が、可能な行き詰まりを防ぐのに必要でした。 例えば、過程AとBが談話するなら、中では、指示は1組の接続、それぞれあるコネの上で進歩をします。 また、これらの過程がちょうど各ビットの入力のための出力の1ビットを作り出すと仮定してください。 次に、それが後の出力と共にAからそれを梱包したがっているのでAのNCPが待ちビットを送らないならBがA.Itが次に、必要であることで、そこでないならそれが送付NCPのバッファのデータが重要にそうでないいくらかのquantiteeであることが明確である出力とどちらの意志にできるようにならない、側を受け取ってください、と送付NCPは別の方法で仮定しなければならなくて、それができるとすぐに、あらゆる待ちデータを送ってください。
These considerations led to the notion of a "transmission unit," whose existence would be known to the NCP's. The questions then became what were typical and/or possible transmission unit sizes. For
これらの問題は存在がNCPのものに知られているだろう「トランスミッションユニット」の概念につながりました。 そして、何が典型的な、そして/または、可能なトランスミッションユニットサイズであるかという質問はなりました。 for
[Page 10]
character-oriented interaction, 8-bit transmission units seemed
reasonable. For line-oriented interaction, the transmission unit might
best be the line itself, and therefore variable length; alternatively,
it might be best consider the transmission unit to be a character. For
file transfer, it might be desirable for the transmission unit to be a
multiple of the word lengths of both machines; however, the last part of
the file may not form a whole transmission unit, if the transmission
unit is too large. The consensus became that the transmission unit
should not be divisible under any circumstances, and should, therefore,
be fairly small. The notion of transmission unit thus seems to be
synonymous with the notation of byte, and the term transmission unit was
dropped.
[10ページ] キャラクタ指向の相互作用、8ビットのトランスミッションユニットは妥当に思えました。 線指向の相互作用に関しては、トランスミッションユニットは最もよく線自体であるかもしれなく、したがって、変数は長さです。 あるいはまた、それはトランスミッションユニットがキャラクタであると特に考えることであるかもしれません。 ファイル転送に、トランスミッションユニットが両方のマシンの語長の倍数であることは望ましいかもしれません。 しかしながら、ファイルの最後の部分は全体のトランスミッション単位を形成しないかもしれません、トランスミッション単位が大き過ぎるなら。 トランスミッション単位がどうあっても分割可能であるべきでなくて、したがって、かなりわずかであるべきであるというコンセンサスは、なりました。 その結果、トランスミッションユニットの概念はバイトの記法と同義であるように思えました、そして、用語トランスミッションユニットは落とされました。
Subsequent discussion of the deadlocks and wakeup aspect revealed that there may be two byte sizes associated with a single connection:
行き詰まりとwakeup局面のその後の議論は、単独結合に関連している2バイトのサイズがあるかもしれないのを明らかにしました:
1. Transmission from the sending process to the sending NCP
is in bytes of size S. The sending NCP must send a
message whenever the link is unblocked, the message
counter is at least 1, the bit counter is at least S,
and the least S bits of text are ready. The message
must contain an integral number of bytes.
1. 送付の過程から送付NCPまでのトランスミッションがリンクが「非-妨げ」られるときはいつも、送付NCPがメッセージを送らなければならないサイズS.のバイトであります、そして、メッセージカウンタは少なくとも1です、そして、噛み付いているカウンタは少なくともSです、そして、テキストの最少のSビットは準備ができています。 メッセージは不可欠のバイト数を含まなければなりません。
2. At the receiving side, there may be a different byte
size R for transmission from the receiving NCP to the
receiving process. An example of where R <> S, is
suggested by UCSB which is providing a file system for
transparently storing binary files. It is reasonable that
a using HOST might send with 36 bit bytes, while the UCSB
file system might want to receive 32-bit increments.
2. 受信側に、受信NCPから受信の過程までのトランスミッションのためのサイズRが異なったバイトあるかもしれません。 例、どこR<>S、透明にバイナリーファイルを格納するファイルシステムを提供しているUCSBによって勧められるか。 使用HOSTが36ビットのバイトと共に発信するのは、妥当です、UCSBファイルシステムが32ビットの増分を受け取りたがっているかもしれませんが。
It is clear that from a network protocol point of view, only the byte S is relevant, and this is quantity which is communicated in the STR command in every message. The choice of the byte size R is up
ネットワーク・プロトコル観点から、バイトSだけが関連していて、これがあらゆるメッセージにおけるSTRコマンドで伝えられる量であることは明確です。 バイトサイズRの選択は上がっています。
[Page 11]
to the receiving user, and its meaning is how often the receiving NCP
should wakeup the receiving process. It may also happen that a
receiving process has an agreement with the receiving NCP which is more
complex than "please wake me every R bits;" for example, the NCP might
scan for new-line characters before waking up the receiving process.
受信ユーザ、およびその意味への[11ページ]は受信NCPはどれくらいの頻度で受信が処理するwakeupがそうするべきであるかということです。 また、より複雑な受信NCPとの協定が受信の過程にあるのが起こるかもしれない、「私のためにあらゆるRを起こしてください、ビット、」、。 例えば、NCPは受信の過程で目覚める前に、改行文字のために韻律に合うかもしれません。
In the new protocol, it is the option of the receiver to refuse a request for connection on the basis of the proffered byte size. Conceptually, we imagine that NCP's are capable of handling all byte sizes, and that such a choice would be up to the third level pro- grams (user programs, loggers, telnets, etc.) Some Hosts, small ones in particular, may know enough about their third level programs to restrict the variety of byte sizes which can be sent or received. While it is a matter of a local policy, the committee strongly suggests that NCP's be capable of handling all byte sizes. One of our committee, moreover, feels strongly that NCP's should be written to be able to receive all byte sizes S and provide for different byte sizes R for transmission to the user process.
新しいプロトコルでは、それは提供されたバイトサイズに基づいて接続を求める要求を拒否する受信機のオプションです。 概念的に、私たちは、NCPのものがすべてのバイトが大きさで分ける取り扱いができて、そのような選択が3番目の平らな親グラム(ユーザ・プログラム、きこり、telnetなど)まで達していると想像します。 いくつかのHosts(特に小さいもの)が、それらの3番目に関する十分が送るか、または受け取ることができるバイトサイズのバラエティーを制限するためにプログラムを平らにするのを知るかもしれません。 それはローカルの方針の問題ですが、委員会は、NCPのものがすべてのバイトが大きさで分ける取り扱いができると強く示唆します。 そのうえ、私たちの委員会のひとりは、NCPのものがユーザ・プロセスへの伝送のためすべてのバイトサイズSを受けて、異なったバイトサイズRに備えることができるように書かれているべきであると強く感じます。
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Enrico Bertone 4/97 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][エンリコBertone4/97によるオンラインRFCアーカイブへの]
[Page 12]
[12ページ]
一覧
スポンサーリンク
