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ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

SSHで初めて接続するホストで、接続するかどうかyes/noを聞かれないようにする

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る