RFC60 日本語訳
0060 Simplified NCP Protocol. R.B. Kalin. July 1970. (Format: TXT=18941 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Kalin Request for Comments: 60 MIT Category: Experimental 13 July 1970
Kalinがコメントのために要求するワーキンググループR.をネットワークでつないでください: 60MITカテゴリ: 実験的な1970年7月13日
A Simplified NCP Protocol
簡易型のNCPプロトコル
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Abstract
要約
This RFC defines a new NCP protocol that is simple enough to be implemented on a very small computer, yet can be extended for efficient operation on large timesharing machines. Because worst case storage requirements can be predicted, a conservative implementation can be freed of complicated resource allocation and storage control procedures. A general error recovery procedure is also defined.
このRFCを非常に小さいコンピュータで実行されていた状態で簡単な新しいNCPプロトコルを定義しますが、効率的な操作のために大きい時分割マシンで広げることができます。 最悪の場合格納要件を予測できるので、複雑な資源配分と格納コントロール手順について保守的な実現を解放できます。 また、一般的なエラーリカバリ手順は定義されます。
Overview and Rational
概観的で合理的です。
The central premise of this proposal is an insistence that all user- to-user connections be bi-directional. For those familiar with communication theory, this appears most reasonable. All communication requires a cyclical flow of information. To deny a simple association between a message and its reply makes protocol unnecessarily complicated and turns simple mechanisms of flow control into nightmares.
この提案の中央の前提はユーザとのすべてのユーザ接続が双方向であるという主張です。 情報理論に詳しいそれらに関しては、これは最も妥当に見えます。 すべてのコミュニケーションが情報の周期的な流れを必要とします。 メッセージとその回答との簡単な協会を否定するのは、プロトコルを不必要に複雑にさせて、フロー制御の簡単なメカニズムを悪夢に変えます。
It is proposed that a bi-directional connection, or duplex link, be identified by a pair of socket numbers, one for each end. This is half the number presently required. Associated with the connection are some number of "crates" or message containers. These crates travel back and forth over the link carrying network messages from one side to the other. Buffers are allocated at each end of the link to hold crates and the messages that they carry. Worst case buffer requirements are equal to the number of crates in circulation, or the "capacity" of the link.
双方向の接続、またはデュプレックスがリンクされるよう提案されて、1組のソケット番号(各端あたり1つ)によって特定されてください。 こちらは現在必要である半数です。 接続に関連づけられているのは、何らかの数の「かご」かメッセージ容器です。 これらのかごは、一方の側から他の側へネットワークメッセージを伝えながら、リンクの上に前後に移動します。 リンクの各端のときにかごと運ぶというメッセージを保持するためにバッファを割り当てます。 最悪の場合バッファ要件は流通における、かごの数、またはリンクの「容量」と等しいです。
Details
詳細
A message buffer has four states which follow one another cyclically. They are:
メッセージ・バッファには、周期的にお互いに続く4つの州があります。 それらは以下の通りです。
Kalin [Page 1] RFC 60 A Simplified NCP Protocol 13 July 1970
簡易型のNCPプロトコル1970年7月13日あたりKalin[1ページ]RFC60
1) empty,
1) 空になってください。
2) filled with a message-laden crate to be unloaded,
2)は、降ろされるためにメッセージ苦しいかごで満ちました。
3) filled with an empty crate, and
そして3)が空のかごで満ちた。
4) filled with a message-laden crate to be sent.
4)は送られるメッセージ苦しいかごで満ちました。
Normally state transitions correspond to message arrival, message removal, message insertion and message transmission.
通常、状態遷移はメッセージ到着、メッセージ取り外し、メッセージ挿入、およびメッセージ送信に対応しています。
For a process to be an NCP it must:
過程がNCPであるために、そうしなければなりません:
1) be able to make initial contact with foreign hosts via the control link and, if necessary, delete user-to-user links left over from the previous system incarnation.
1) コントロールを通した異種宿主との初期接触をリンクさせて、必要なら、ユーザからユーザへの前のシステム肉体化から残されたリンクは削除できてください。
2) be able to create user-to-user links.
2) ユーザからユーザへのリンクを作成できてください。
3) be able to interface users with these links.
3) これらのリンクにユーザを連結できてください。
4) be able to delete user-to-user links.
4) ユーザからユーザへのリンクを削除できてください。
The first of the four functions shall not be discussed here except to point out that it contains critical races that can not be resolved without making assumptions about maximum message propagation delays. Since within the ARPA network, bounds on message turnaround time do not exist, the approach chosen must necessarily be tender. The other three functions are discussed first from the viewpoint of one interested in implementing a minimal NCP. Then extensions and improvements are proposed that are suitable for larger machines.
最大のメッセージ伝播に関する仮定を遅れにしないで決議できない批判的なレースを含むと指摘する以外に、ここで4つの機能の1番目について議論しないものとします。 メッセージターンアラウンドタイムの領域がARPAネットワークの中に存在していないので、選ばれたアプローチは必ず穏やかでなければなりません。 最初に、最小量のNCPを実行したがっていた1の観点から他の3つの機能について議論します。 より大きいマシンに適当な次に、拡大と改良は提案されます。
Any NCP must be capable of creating a duplex link between a local user process and a remote one. The current protocol accomplishes this by queuing a potentially unbounded number of RFC's and waiting for the user to examine the queue to determine with whom he wishes to talk. There is no guarantee that the user will ever look at the queue and there is no way to limit the size of the queue. The overflow error message suggested fails in the respect because it admits that the RFC will only be sent again. The picture need not be this bleak. The following network conversation demonstrates how connections can be made without using queues or relying on user process attention.
どんなNCPもローカルのユーザ・プロセスとリモートものとの複式のリンクを作成できなければなりません。 RFCの潜在的に限りない数を列に並ばせて、ユーザが話したがっている決定する待ち行列を調べるのを待つことによって、現在のプロトコルはこれを達成します。 ユーザが待ち行列を見て、待ち行列のサイズを制限する方法が全くないという保証が全くありません。 RFCが再び送られるだけであることを認めるので、示されたオーバーフローエラーメッセージは敬意に失敗します。 これが荒涼であったなら、絵はそうする必要はありません。 以下のネットワークの会話はどう待ち行列を使用するか、またはユーザ・プロセス注意に依存しないで接続を作ることができるかを示します。
Suppose that a local user process and a remote user process wish to establish a new connection. The remote process asks its NCP to listen for a connection request and gives it the socket identifier for its end. Optionally it can give both socket identifiers. The user process at the local end asks its NCP to send a request for a duplex link
ローカルのユーザ・プロセスとリモート・ユーザーが新しい接続を確立するという願望を処理すると仮定してください。 リモート過程は、接続要求の聞こうとするようにNCPに頼んで、終わりにソケット識別子をそれに与えます。 任意に、それは両方のソケット識別子を与えることができます。 地方の終わりのユーザ・プロセスは、複式のリンクを求める要求を送るようにNCPに頼みます。
Kalin [Page 2] RFC 60 A Simplified NCP Protocol 13 July 1970
簡易型のNCPプロトコル1970年7月13日あたりKalin[2ページ]RFC60
(RFDL). It specifies both socket identifiers of the proposed link. The local NCP sends a RFDL over the control link with the following format:
(RFDL。) それは提案されたリンクに関する両方のソケット識別子を指定します。 ローカルのNCPは以下の形式とのコントロールリンクの上にRFDLを送ります:
RFDL <my socket> <your socket> <max number buffers> <spare>
RFDL<はあなたのソケット><最大数のバッファ><が>を割く私のソケット><です。
The third argument is normally supplied by the local NCP and indicates the maximum number of buffers the NCP will consider allocating to this duplex link. If buffers are in user storage the count may be given by the user in a call made to the NCP.
3番目の議論は、通常、ローカルのNCPによって供給されて、NCPが割り当てると考えるバッファの最大数がこのデュプレックスにリンクされるのを示します。 バッファがユーザ格納にあるなら、カウントはNCPにかけられる電話でユーザによって与えられるかもしれません。
The RFDL is received at the remote host and the remote NCP compares <my socket> and <your socket> against the socket identifiers supplied by unmatched listens issued to it. For listens in which just a single identifier was given only <your socket> must match. If both socket identifiers were given, they both must match. If a match is found an acknowledgement message with the following format is sent back by the NCP:
リモートホストにRFDLを受け取ります、そして、リモートNCPは<を比較します。ソケット識別子に対するあなたのソケット>が優れるのから供給した私のソケットの>と<はそれに発行されていた状態で聴かれます。 まさしくただ一つの識別子がどれであったかであなたのソケット>が合わなければならない<だけを与える場合、聴きます。 両方のソケット識別子を与えたなら、それらの両方が合わなければなりません。 確認メッセージが以下でマッチに見つけられるなら、形式はNCPによって返送されます:
ACDL <your socket> <my socket> <number buffers> <spare>
ACDL<は私のソケット><数のバッファ><が>を割くあなたのソケット><です。
The <number buffers> parameter is equal to the smaller of <max number buffers> as specified in the RFDL and the number of message buffers agreeable to the remote NCP. If no match is found the error message returned is an ACDL in which <number buffers> equals zero. Note that the RFDL mechanism is similar to a RFC mechanism in which the bound on queue size is one and connection acceptance is done entirely by the NCP.
<数のバッファ>パラメタはリモートNCPに快いメッセージ・バッファのRFDLと数における指定されるとしての<最大数のバッファ>について、より小さいのと等しいです。 エラーメッセージがどんなマッチにも見つけられないなら、返しているのは、<番号が同輩が合っているゼロ>をバッファリングするACDLです。 RFDLメカニズムが待ち行列サイズにおけるバウンドが1であり、接続承認が完全にNCPによって行われるRFCメカニズムと同様であることに注意してください。
The two varieties of a listen correspond to two modes of channel operation. The single parameter variety, as typified by a LOGIN process, is to be used by programs that will "talk with anyone who happens to dial their number". Screening of contacts for appropriateness is left to the user process. The double parameter listen is used by user programs who know with whom they will communicate and do not wish to be bothered by random RFDL's from other sources. Given the way in which socket name space is partitioned, it is impossible to get a matching RFDL from any process but the one intended.
aのバラエティーが聴く2はチャンネル操作の2つのモードに対応しています。 LOGIN工程で代表されるただ一つのパラメタのバラエティーは「たまたまそれらの番号にダイヤルするだれとも話す」プログラムで使用されることです。 適切さに関する接触の選別はユーザ・プロセスに残されます。 二重パラメタは聴かれます。彼らがだれを伝えるかと共に知っていて、無作為のRFDLのものによって他のソースから苦しめられることを願っていないユーザ・プログラムで、使用されます。 ソケット名スペースが仕切られる方法を考えて、どんな過程にもかかわらず、ものからの合っているRFDLも意図させるのは不可能です。
Message buffers for the connection are allocated in the remote host before it sends the ACDL and in the local host at the time the ACDL is received. The number of buffers at each end is equal to the <number buffers> parameter in the ACDL. The state of all remote buffers is "empty" and of all local buffers "filled with empty crate". After buffers are allocated the local user process is notified that it is able to start sending messages.
ACDLを送る前にリモートホストに接続へのメッセージ・バッファを割り当てます、そして、当時ローカル・ホストでは、ACDLは受け取られています。 各端のバッファの数はACDLの<数のバッファ>パラメタと等しいです。 すべてのリモートバッファの状態は、「空であり」、すべてのローカルのバッファに「空のかごで満ちました」。 バッファを割り当てた後に、メッセージを送り始めることができるようにローカルのユーザ・プロセスに通知します。
Kalin [Page 3] RFC 60 A Simplified NCP Protocol 13 July 1970
簡易型のNCPプロトコル1970年7月13日あたりKalin[3ページ]RFC60
The type of interface presented by the NCP between the user process and the newly created duplex link is a decision local to that host. A simple but complete interface would provide two calls to be made to the NCP. GETMESSAGE would return the next message from the link complete with marking, text and padding. PUTMESSAGE would take a message, marking and text only, and buffer it for transmission. The obvious logical errors would be reported.
ユーザ・プロセスと新たに作成された複式のリンクの間のNCPによって提示されたインタフェースのタイプはそのホストにとっての、ローカルの決定です。 簡単な、しかし、完全なインタフェースはNCPに作られているという2つの要求を提供するでしょう。 GETMESSAGEはマーク、テキスト、および詰め物で完全なリンクから次のメッセージを返すでしょう。 PUTMESSAGEは伝言、マーク、およびテキストだけを受け取て、トランスミッションのためにそれをバッファリングするでしょう。 明白な論理的な誤りは報告されるでしょう。
We suggest that message alignment be left to the user. On most machines it is a simple but time consuming operation. If done in the NCP there is no guarantee that the user will not have to readjust it himself. It is usually not possible to know a priori whether the text portion should be right adjusted to a word boundary, left adjusted to a word boundary, aligned to the end of the last message, or fragmented in some exotic way.
私たちは、メッセージ整列がユーザに任せることを提案します。 ほとんどのマシンにおける、それは簡単な、しかし、時間がかかった操作です。 NCPでするなら、ユーザが自分でそれを再調整する必要はないという保証が全くありません。 通常、テキスト部分が正しいはずであるかどうかが最後のメッセージの終わりまで並べられた語境界に調整されるように残されるか、または何らかのエキゾチックな方法で断片化された語境界に適応したのを先験的に知るのは可能ではありません。
Within this protocol message boundaries are used to provide storage allocation information. If not required by the user this information can be forgotten and the user interface can be made to appear as a bit stream. Though welcomed by purists, such a strategy may produce complications when attempting to synchronize both ends of a link.
このプロトコルの中では、メッセージ限界は、記憶領域の割当て情報を提供するのに使用されます。 ユーザは必要でないなら、この情報を忘れることができます、そして、少し流れるとき、ユーザーインタフェースを現れさせることができます。 純粋主義者によって歓迎されますが、リンクの両端を同期させるのを試みるとき、そのような戦略は複雑さを起こすかもしれません。
Links are deleted by removing empty crates from them and reclaiming the buffers allocated to the crates removed. Only buffers with crates in can be reclaimed; empty buffers must remain available to receive messages that may arrive. When no crates are left, no buffers remain, and the socket identifiers can be forgotten. When empty crates are removed, a decrement size message is sent to the foreign NCP to allow it to reduce its buffer allocation:
リンクはそれらから空のかごを取り外すことによって、削除されました、そして、かごに割り当てられたバッファを取り戻すのは取り外されました。 中にかごがあるバッファしか取り戻すことができません。 空のバッファは到着するかもしれないメッセージを受け取るために利用可能なままで残らなければなりません。 いつ、かごが全くないかはいなくなりました、そして、バッファは全く残っていません、そして、ソケット識別子は忘れることができます。 空のかごを取り外すとき、バッファ配分を抑えるのを許容するために減少サイズメッセージを外国NCPに送ります:
DEC <my socket> <your socket> <number of buffers dropped>
12月の<あなたのソケット><が付番するバッファの低下している>の私のソケット><。
A reply is solicited from the foreign NCP to affirm the deletions or to complain of an error. Possible errors include "no such link" and "impossible number of buffers dropped".
回答は、削除を確言するか、または誤りについて不平を言うために外国NCPから請求されます。 可能な誤りは「そのようなリンクでない」を含んでいます、そして、「不可能な数のバッファが低下しました」。
The option to close a link can be given to a user process by providing either of two system calls. NOMOREOUTPUT declares that no more messages will be sent by the local user process. All local buffers for the link that contain empty crates are reclaimed by the NCP. DEC messages are sent to the foreign NCP. As crates are emptied, via GETMESSAGE calls, their buffers are reclaimed too. As an alternative, the call KILLMESSAGE can be implemented. This call can be used in place of a PUTMESSAGE. Instead of filling an empty crate with a message to be sent, KILLMESSAGE will cause the crate to be reclaimed and a DEC control message sent.
リンクを閉じるオプションは、提供することによって、2つのシステムコールをユーザ・プロセスに与えることができます。 NOMOREOUTPUTは、それ以上のメッセージが全くローカルのユーザ・プロセスで送られないと宣言します。 リンクのための空のかごを入れてあるすべてのローカルのバッファがNCPによって取り戻されます。 12月のメッセージを外国NCPに送ります。 かごがGETMESSAGE呼び出しで空にされているとき、また、それらのバッファは取り戻されます。 代替手段として、呼び出しKILLMESSAGEを実行できます。 PUTMESSAGEに代わってこの呼び出しを使用できます。 空のかごを満たすことの代わりに、KILLMESSAGEは開墾されるべきかごと送られた12月のコントロールメッセージを引き起こすでしょう。
In situations where the user process has died, or for some other
または、ユーザ・プロセスが消え失せた状況である他の
Kalin [Page 4] RFC 60 A Simplified NCP Protocol 13 July 1970
簡易型のNCPプロトコル1970年7月13日あたりKalin[4ページ]RFC60
reason can not close the link, more drastic measures must be taken. For these situations, the ABEND control message is defined:
理由はリンクを閉じることができないで、より抜本的な対策は実施されなければなりません。 これらの状況において、ABENDコントロールメッセージは定義されます:
ABEND <my socket> <your socket>
ABEND<、私のソケット><、あなたのソケット>。
After sending an ABEND the issuing NCP starts to close the link. All buffers containing input are destroyed. A DEC is issued for these and the previously empty buffers. If messages arrive on the link, they are destroyed and a DEC is issued. Any ABEND received for the link is ignored.
ABENDを送った後に、発行NCPはリンクを閉じ始めます。 入力を含むすべてのバッファが破壊されます。 12月はこれらと以前に空のバッファのために発行されます。 メッセージがリンクの上に到着するなら、それらは破壊されます、そして、12月は発行されます。 リンクに受け取られたどんなABENDも無視されます。
When the remote NCP receives the ABEND, it stops sending messages over the link and refuses new messages from the user process at its end. Empty buffers are reclaimed. Pending output messages are destroyed and their buffers reclaimed. Input messages are fed to the user process as long as it will accept them. Buffers are reclaimed as input is accepted. DEC's are issued to cover all buffers reclaimed. When the user process will take no more input, input messages are destroyed and their buffers reclaimed. Eventually all buffers will be reclaimed at both ends of the link. At such time the connection can be considered closed and the socket numbers used can be reassigned without ambiguity.
リモートNCPがABENDを受けるとき、それは、リンクの上にメッセージを送るのを止めて、終わりのユーザ・プロセスから新しいメッセージを拒否します。 空のバッファは取り戻されます。 未定の出力メッセージは、破壊されていて取り戻されたそれらのバッファです。 それらを受け入れる限り、入力メッセージをユーザ・プロセスに入れます。 入力を受け入れるとき、バッファを取り戻します。 12月は、取り戻されたすべてのバッファをカバーするために発行されます。 ユーザ・プロセスがそれ以上の入力を全く取らないとき、入力メッセージは、破壊されていて取り戻されたそれらのバッファです。 結局、すべてのバッファがリンクの両端で取り戻されるでしょう。 そのような時に、閉じられると接続を考えることができます、そして、あいまいさなしで数が使用したソケットを再選任できます。
Under this proposed protocol the above four functions constitute all that must be part of a network NCP. If buffers are allocated only when free ones exist there can be no "overflow" errors nor is there any need to place further constraints on message flow. For any user message that arrives buffer room is guaranteed. All control messages can be processed without requiring additional storage to be allocated. Attempts by a user process to issue too many listens can be thwarted by local control procedures.
上の4つの機能が構成するこの提案されたプロトコルの下では、そのすべてがネットワークNCPの一部であるに違いありません。 自由なものが存在するときだけ、バッファを割り当てるなら、「オーバーフロー」誤りが全くあるはずがありません、そして、メッセージ流動に更なる規制を置く少しの必要もありません。 到着するどんなユーザメッセージに関してはも、バッファ部屋は保証されます。 追加格納が割り当てられる必要でない、すべてのコントロールメッセージを処理できます。 現場制御手順によって多く過ぎるのが聴く問題へのユーザ・プロセスによる試みを阻まれることができます。
Inefficiencies in storage will result when the number of outstanding connections gets large. One price of coding simplicity is a fifty percent utilization of buffer space. On large hosts it may prove advantageous to implement some of the following NCP extensions. With more complicated flow control procedures, it becomes possible for an NCP to allocate more buffer space than actually exists and still not to get into trouble. Other extensions provide message compression, improved throughput and user transparent error recovery.
傑出している接続の数が大きくなるとき、格納における非能率は結果として生じるでしょう。 コード化の簡単さの単一価格はバッファ領域の50パーセントの利用です。 大きいホストの上では、以下のNCP拡大のいくつかを実行するのが有利であると判明するかもしれません。 より複雑なフロー制御手順によると、NCPが実際に存在しているより多くのバッファ領域を割り当てて、まだ問題に入っていないのは可能になります。 他の拡大はメッセージ圧縮、改良されたスループット、およびユーザの透明なエラー回復を提供します。
Because some extensions require the cooperation of foreign hosts and assume that they have implemented more than the minimal NCP it is proposed that an inquiry control message be used to find out what extensions the foreign host has implemented. The response to an INQ will be a control message defining a host profile. If an "undefined error" message is returned, the foreign host is assumed to have only a minimal NCP.
いくつかの拡張子が、異種宿主の協力を必要として、彼らが最小量のNCP以上を実行したと仮定するので、問い合せコントロールメッセージが異種宿主がどんな拡大を実行したかを見つけるのに使用されるよう提案されます。 INQへの応答はホストプロフィールを定義するコントロールメッセージになるでしょう。 「未定義の誤り」メッセージを返すなら、最小量のNCPしか持っていないと異種宿主を思います。
Kalin [Page 5] RFC 60 A Simplified NCP Protocol 13 July 1970
簡易型のNCPプロトコル1970年7月13日あたりKalin[5ページ]RFC60
A simple extension is to define a control message that will replace user RFNM's. A user RFNM is a null text message sent, for example, as a reply when a file is transferred via a duplex link. They are inefficient since they tie up an entry in the IMP's link assignment table and degrade network throughput. A more efficient solution is to send a special message over the control link. In this way one short message can replace several user messages.
単純拡大はユーザRFNMのものを取り替えるコントロールメッセージを定義することです。 ユーザRFNMは複式のリンクを通してファイルを移すとき例えば回答として送ったヌルテキストメッセージです。 彼らがIMPのリンク課題テーブルでエントリーをタイアップして、ネットワークスループットを下げるので、それらは効率が悪いです。 より効率的な解決策はコントロールリンクの上に特別教書を送ることです。 このように、1つの短いメッセージがいくつかのユーザメッセージを置き換えることができます。
URFNM <my socket> <your socket> <number of user RFNM's>
URFNM<はあなたのソケット><が付番するユーザRFNMの>に関する私のソケット><です。
Because the control link is concurrent with the return side of the user link, URFNM's can not be substituted for user RFNM's when there are other messages to be sent on the return link. Otherwise ordering will be lost and with it user transparency.
コントロールリンクがユーザリンクのリターン側面で同時発生であるので、リターンリンクに送られるべき他のメッセージがあるとき、ユーザRFNMのものにURFNMのものを代入できません。 さもなければ、注文は、失われていて、それでそうするでしょう。ユーザ透明。
Throughput can also be increased with a mechanism to add additional crates on a duplex link. This might be at user instigation or be a decision of the NCP.
また、スループットはメカニズムで増加して、デュプレックスの追加かごがリンクされると言い足すことができます。 これは、ユーザ扇動にはあるか、NCPの決定であるかもしれません。
INC <my socket> <your socket> <number buffers desired>
INC<、あなたのソケット><番号がバッファリングする私のソケット><は>を望んでいました。
The foreign host replies to an increase request by returning an INCR.
増加に関する回答がINCRを返すことによって要求する異種宿主。
INCR <my socket> <your socket> <number buffers to be added>
INCR<はあなたのソケット><番号が加えられた>になるようにバッファリングする私のソケット><です。
If the foreign NCP is unable to meet the additional buffer demand, <number buffers to be added> will be less than <number buffers desired> and possibly zero. The initial state of all local buffers added is "filled with empty crate" and of all foreign buffers "empty".
外国NCPが追加バッファ需要にこたえることができないなら、数が<以下が数のバッファであるつもりであったなら加えられた>になるようにバッファリングする<は>とことによるとゼロを望んでいました。 ローカルのバッファが加えたすべての初期状態は「空のかごで満たされます」、そして、すべてでは、外国バッファは「空になります」。
The spare argument in the RFDL and ACDL could be used to declare the maximum sized message that will actually be sent in that direction. A perceptive NCP could observe this information and allocate smaller buffers. A lesser NCP could ignore it and always assume maximum length messages. For example, if the field were zero then only user RFNM's would be sent. A smart NCP would allocate no storage at all.
実際にその方向に送られる最大の大きさで分けられたメッセージを宣言するのにRFDLとACDLの予備議論を使用できました。 知覚しているNCPは、この情報を観測して、より小さいバッファを割り当てるかもしれません。 より少ないNCPは、それを無視して、いつも最大の長さがメッセージであると仮定するかもしれません。 例えば、分野がゼロであるなら、ユーザRFNMのものだけを送るでしょうに。 賢いNCPは格納を全く割り当てないでしょう。
If the NCP retains a copy of each user message sent over the network until a reply is returned, an automatic error recovery procedure can be implemented. Because the capacity of the link is always known, an NCP can determine whether there are messages in transit. This is done by first sending a STOP message to the foreign NCP:
NCPが回答を返すまでネットワークの上に送られたそれぞれのユーザメッセージのコピーを保有するなら、自動エラー回復手順を実行できます。 リンクの容量がいつも知られているので、NCPは、トランジットにはメッセージがあるかを決定できます。 最初にはSTOPメッセージを外国NCPに送りながら、これをします:
STOP <my socket> <your socket>
STOP<、私のソケット><、あなたのソケット>。
The STOP message tells the foreign NCP to temporarily stop transmitting messages over the selected link. Unlike CEASE-ON-LINK
STOPメッセージは、選択されたリンクの上にメッセージを送るのを一時止めるように外国NCPに言います。 リンクの上にやみます。
Kalin [Page 6] RFC 60 A Simplified NCP Protocol 13 July 1970
簡易型のNCPプロトコル1970年7月13日あたりKalin[6ページ]RFC60
there is no guarantee as to how many messages will be sent before the STOP takes effect. The local NCP then sends a link inquiry message:
STOPが効く前にいくつのメッセージを送るかに関して保証が全くありません。 次に、ローカルのNCPはリンク問い合せメッセージを送ります:
LINQ <my socket> <your socket>
LINQ<、私のソケット><、あなたのソケット>。
The reply gives the number of crates at the foreign end of the link. The LINQ message is repeated until this number plus the number of local crates equals the capacity of the link. At this time no messages are in transit and the two ends of the link have been synchronized. Messages can now be identified relative to the synchronization point. Thus the local NCP can send a control message asking, for example, that the third to last message be retransmitted. The foreign NCP is able to identify which message this is and to retransmit it. Once all errors have been recovered a START control message, similar in format to the STOP, is sent to the foreign NCP and normal operation continues. The entire recovery procedure can be transparent to both user processes.
回答はリンクの外国端でかごの数を与えます。 地方のかごのこの数と数がリンクの容量と等しくなるまで、LINQメッセージは繰り返されます。 このとき、メッセージは全くトランジット中ではありません、そして、リンクの2つの端が連動しました。 現在、同期ポイントに比例してメッセージを特定できます。 したがって、ローカルのNCPで、例えば、コントロールメッセージは、メッセージを持続する3番目が再送されるように頼むことができます。 外国NCPは、これがどのメッセージであるかを特定して、それを再送できます。 いったんすべての誤りを回復すると、形式においてSTOPと同様のSTARTコントロールメッセージを外国NCPに送ります、そして、通常の操作は続きます。 全体のリカバリ手順は両方のユーザ・プロセスに見え透いている場合があります。
It is expected that the larger hosts will not adhere strictly to the worst case storage allocation requirements. Rather they will allocate more buffers than they have and reply on statistics to keep them out of trouble most of the time. Such conduct is perfectly permissible as long as it is transparent to foreign hosts. The protocol allows an NCP to lie about storage allocation as long as he is not caught. In situations where detection appears imminent some of the following control mechanisms will need to be applied. They are listed in increasing order of power.
より大きいホストが厳密に最悪の場合記憶領域の割当て要件を固く守らないと予想されます。 むしろ彼らは持って、たいてい問題にそれらを入れないようにするために統計で返答するより多くのバッファを割り当てるでしょう。 異種宿主にとって、それが透明である限り、そのような行為は完全に許されています。 プロトコルで、彼が引っかかっていない限り、記憶領域の割当てに関してNCPがあります。 検出が差し迫っているように見える状況で、以下のいくつかの制御機構が、適用される必要があるでしょう。 それらはパワーの増加する注文に記載されています。
a) Do not send out any user RFNM's or other short messages. There is a good chance that they will be replaced by longer messages that will strain buffer capacity even more.
a) どんなユーザRFNMのものや他の短いメッセージも出さないでください。 それらを緩衝能をさらにも張るより長いメッセージに取り替えるという十分な見込みがあります。
b) Try not to accept any new messages from the IMP. Block local processes attempting to issue messages.
b) IMPからどんな新しいメッセージも受け入れようとしないでください。 メッセージを発行するのを試みるローカルの過程を妨げてください。
c) Issue DEC's to free up buffer space. Do not allocate more than one buffer to RFDL's and refuse INC's.
c) 12月を発行して、バッファ領域を開けてください。 1つ以上のバッファをRFDLのものに割り当てないでください、そして、INCのものを拒否してください。
d) Fake errors in messages waiting for local user action. Do this only if the host that sent it has implemented error recovery. This will free buffer space and allow you to recover later. This final measure is admittedly a last resort, but it should be powerful enough to control any emergency.
d) 地方のユーザ動きを待って、メッセージで誤りを見せかけてください。 それを送ったホストがエラー回復を実行した場合にだけ、これをしてください。 これは、バッファ領域を解放して、あなたが後で回復するのを許容するでしょう。 この最終的な測定は明白に切り札ですが、それはどんな非常時にも制御するほど強力であるはずです。
It is the hope of the author that the above protocol presents an attractive alternative to that proposed by RFC 54 and its additions. Although it appears at a late date, it should not be more than a minor jolt to implementation efforts. It is simple enough to be
それは上のプロトコルがRFC54によって提案されたそれへの魅力的な代替手段とその追加を提示するという作者の望みです。 後半期日に現れますが、それは実現の努力への小さい方の急激な動揺より多いはずがありません。 それは単に簡単です。
Kalin [Page 7] RFC 60 A Simplified NCP Protocol 13 July 1970
簡易型のNCPプロトコル1970年7月13日あたりKalin[7ページ]RFC60
implemented quickly. If adopted, a majority of the present sites could be talking intelligently with one another by the end of the summer.
すぐに実行されます。 採用されるなら、現在の場所の大部分が夏の終わりまでに知的にお互いと話しているかもしれません。
References
参照
[1] Crocker, S.D., Postel, J., Newkirk, J. and Kraley, M., "Official protocol proffering", RFC 54, June 1970.
[1] クロッカーとサウスダコタ州とポステルとJ.とニューカークとJ.とKraley、M.、「公式のプロトコル提供」、RFC54、1970年6月。
Author's Address
作者のアドレス
Richard Kalin MIT Lincoln Laboratory
リチャードKalin MITリンカーン研究所
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Ian Redfern 3/97 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][イアンRedfern3/97によるオンラインRFCアーカイブへの]
Kalin [Page 8]
Kalin[8ページ]
一覧
スポンサーリンク