RFC55 日本語訳
0055 Prototypical implementation of the NCP. J. Newkirk, M. Kraley, J.Postel, S.D. Crocker. June 1970. (Format: TXT=48070 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Newkirk
Request for Comments: 55 M. Kraley
Harvard
J. Postel
S. Crocker
UCLA
19 June 1970
コメントを求めるワーキンググループJ.ニューカーク要求をネットワークでつないでください: 55 M.KraleyハーバードJ.ポステルS.医者UCLA1970年6月19日
A Prototypical Implementation of the NCP
NCPのPrototypical実現
While involved in attempting to specify the formal protocol, we also attempted to formulate a prototypical NCP in an Algol-like language. After some weeks of concentrated effort, the project was abandoned as we realized that the code was becoming unreadable. We still, however, felt the need to demonstrate our conception of how an NCP might be implemented; we felt that this would help suggest solutions for problems that might arise in trying to mold the formal specifications into an existing system. This document is that attempt to specify in a prose format what an NCP could look like.
また、正式なプロトコルを指定するのを試みるのにかかわっている間、私たちは、アルゴルのような言語のprototypical NCPを定式化するのを試みました。 数週間の集中努力の後に、私たちが、コードが読みにくくなっていたとわかったとき、プロジェクトは捨てられました。 しかしながら、私たちはまだNCPがどう実行されるかもしれないかに関する私たちの概念を示す必要性を感じていました。 私たちは、これが、既存のシステムに形式仕様を成形しようとする際に起こるかもしれない問題の解決を示すのを助けると感じました。 このドキュメントは散文形式でNCPが似ることができたことを指定するその試みです。
There are obvious limitations on a project of this nature. We do not, and cannot, know all of the quirks of the various systems that must write an NCP. We are forced to make some assumptions about the environment, system calls, and the like. We have tried to be as general as possible, but no doubt many sites will have completely different ways of conceptualizing the NCP. There is great difficulty involved in conveying our concepts and the mechanisms that deal with these concepts to people who have wholly different ways of looking at things. We have, however, benefited greatly by trying to actually code this program for our fictitious machine. Many unforeseen problems surfaced during the coding, and we hope that by issuing this document we can help to alleviate similar problems which may arise in individual cases.
明白な制限がこの種のプロジェクトにあります。 そして、私たちがそうしない、NCPを書かなければならない様々なシステムの気まぐれについてすべてを知ることができてください。 私たちはやむを得ず環境、システムコール、および同様のものに関するいくつかの仮定をします。 私たちはできるだけ一般的になろうとしましたが、間違いなく多くのサイトには、NCPを概念化する完全に異なった方法があるでしょう。 ものを見る完全に異なった方法を持っている人々にこれらの概念に対処する私たちの概念とメカニズムを伝えるのにかかわる大きな困難があります。 しかしながら、私たちは、実際に私たちの架空のマシンのためのこのプログラムをコード化しようとすることによって、大いに利益を得ました。 多くの予期せぬ問題がコード化の間、表面化しました、そして、このドキュメントを発行することによって、私たちが、個々の場合に起こるかもしれない同様の問題を軽減するのを助けることができることを願っています。
There is, of course, absolutely no requirement to implement anything which is contained in this document. The only rigid rules which an NCP _must_ conform to are stated in NWG/RFC#54. This description is intended only as an example, _not_ as a model.
もちろん、実行するという何か本書では含まれているもの要件が絶対に全くありません。 NCP_必須_が従う唯一の鉄則がNWG/RFC#54で述べられています。 この記述は単に_ではなく、例、モデルとしての_として意図します。
In the discussion which follows we first describe the environment to be assumed and postulate a set of system calls. We discuss the overall architecture of the NCP and the tables that will be used to hold relevant information. Narratives of network operations follow. A state diagram is then presented as a convenient method for conceptualizing the cause-effect sequencing of events. The detailed processing of each type of network event (system calls or incoming network messages) is then discussed.
続く議論では、私たちは、最初に、想定される環境について説明して、1セットのシステムコールを仮定します。 私たちは関連情報を保持するのに使用されるNCPとテーブルの総合的な構造について議論します。 ネットワーク操作の物語は従います。 そして、州のダイヤグラムは出来事の原因効果配列を概念化するための便利な方法として提示されます。 そして、それぞれのタイプのネットワークイベント(システムコールか入って来るネットワークメッセージ)の詳細な処理について議論します。
Newkirk, et al. [Page 1] RFC 55 Prototypical Implementation of NCP June 1970
ニューカーク、他 [1ページ] NCP1970年6月のRFC55Prototypical実現
II. Environment
II。 環境
We assume that the host will have a time-sharing operating system in which the CPU is shared by processes.
私たちは、ホストにはCPUが工程で共有される時分割オペレーティングシステムがあると思います。
We envision that each process is tagged with a user number. There may be more than one process with the same user number; if so, they should all be cooperating with respect to using the network.
私たちはそれを思い描きます。ユーザ番号で各過程はタグ付けをされます。 同じユーザ番号がある1つ以上の過程があるかもしれません。 そうだとすれば、彼らは皆、ネットワークを使用することに関して協力するべきです。
We envision that each process contains a set of ports which are unique to the process. These ports are used for input to or output from the process, from or to files, devices, or other processes.
私たちはそれを思い描きます。各過程は1セットの過程にユニークなポートを含んでいます。 これらのポートは過程からの入力か出力、または、過程かファイルか、装置か、他の過程に使用されます。
We also envision that a process is not put to sleep (i.e., blocked or dismissed) when it attempts to LISTEN or CONNECT. Instead it is informed when some action is complete. Of course, a process may dismiss itself so that it wakes up only on some external event.
また、私たちは試みる場合睡眠につけられなかった(すなわち、妨げられるか、または棄却されます)そのaの過程LISTENかCONNECTを思い描きます。 代わりに、それは何らかの動きがいつ完全であるかを知らされます。 もちろん、過程がそれ自体を棄却するかもしれないので、それはいくつかの外部の出来事だけで目覚めます。
To engage in network activity, a process attaches a local socket to one of its ports. Sockets are identified by user number, host and AEN; a socket is local to a process if the user numbers of the two match and they are in the same host. Thus, a process need only specify an AEN when it is referring to a local socket.
ネットワーク活動に従事するために、過程は地方のソケットをポートの1つに取り付けます。 ソケットはユーザ番号、ホスト、およびAENによって特定されます。 2つのもののユーザ番号が合って、それらが同じホストにあるなら、ソケットは過程に地方です。 地方のソケットについて言及しているとき、したがって、過程はAENを指定するだけでよいです。
Each port has a status which is modified by system calls and concurrent events outside the process (e.g., a 'close connection' command from a foreign host). The process may look at a port's status as any time (via the STATUS system call).
各ポートには、システムコールと同時発生の出来事によって過程(例えば、異種宿主からの'浅からぬ関係'コマンド)の外で変更される状態がいます。 過程は何時(STATUSシステムコールを通した)でもポートの状態を見るかもしれません。
We assume a one-to-one correspondence between ports and sockets.
私たちはポートとソケットとの1〜1つの通信を仮定します。
III. System Calls
III。 システムコール
These are typical system calls which a user process might execute.
これらはユーザ・プロセスが実行するかもしれない典型的なシステムコールです。
We use the notation
私たちは記法を使用します。
SYSCALL (ARG1, ARG2....)
SYSCALL(ARG1、ARG2)
where
SYSCALL is the name of the system call
and
ARGk, etc. are the parameters of the system call.
SYSCALLがシステムコールとARGkという名前であるところでは、などはシステムコールのパラメタです。
Newkirk, et al. [Page 2] RFC 55 Prototypical Implementation of NCP June 1970
ニューカーク、他 [2ページ] NCP1970年6月のRFC55Prototypical実現
CONNECT (P, AEN, FS, CR)
接続してください。(P、AEN、FS、CR)
P specifies a port of the process
AEN specifies a local socket; the user number and host are
implicit
FS specifies a socket with any user number in any hose,
and with any AEN
CR the condition code returned
Pは指定します。過程AENのポートは地方のソケットを指定します。 ユーザ番号とホストは内在しているFSがどんなホースのどんなユーザ番号、および条件コードが返したどんなAEN CRと共にもソケットを指定するということです。
CONNECT attempts to attach the local socket specified by AEN to
the port P and to initiate a connection with a specific foreign
socket, FS. Possible values of CR are:
CONNECTはAENによってポートPに指定された地方のソケットを取り付けて、特定の外国ソケット(FS)との接続を開始するのを試みます。 CRの可能な値は以下の通りです。
CR=OK The CONNECT was legal and the socket FS is being
contacted. When the connection is established
or refused the status will be updated.
CR=OK CONNECTは法的でした、そして、ソケットFSは連絡されています。 接続を確立するか、または拒否するとき、状態をアップデートするでしょう。
CR = BUSY The local socket is in use (illegal command
sequence).
ソケットがある地方のCR=BUSYは(不正コマンド系列)を使用します。
CR = BADSKT The socket specification was illegal.
CRはBADSKTと等しいです。ソケット仕様は不法でした。
CR = NOROOM Local host's resources are exhausted.
NOROOM Local CR=ホストのリソースは疲れ果てています。
CR = HOMOSEX Incorrect send/receive pair
CR=HOMOSEX Incorrectは組を送るか、または受けます。
CR = IMP DEAD Our imp has died
IMP DEAD Our CR=悪童は死にました。
CR = LINK DEAD The link to the foreign host is dead because:
1. the foreign Imp is dead,
2. the foreign host is dead, or
3. the foreign NCP does not respond.
CRがLINK DEADと等しい、異種宿主へのリンクが死んでいる、: 1. 外国Impが死んでいる、2 異種宿主が死んでいるか、または3 外国NCPは応じません。
LISTEN (P, AEN, CR)
聴いてください。(P、AEN、CR)
P specifies a port of the process
AEN specifies a local socket
CR the condition code returned
Pが指定する、過程AENのポートは条件コードが返した地方のソケットCRを指定します。
The local socket specified by AEN is attached to port P. If there
is a pending call, it is processed; otherwise, no action is taken.
When a call comes in, the user will be notified. After examining
the call, he may either accept or refuse it. Possible values of
CR are:
AENによって指定された地方のソケットは、P.を移植するために取り付けられます。そこのIfが未定の呼び出しである、それは処理されます。 さもなければ、行動を全く取りません。 呼び出しが入るとき、ユーザは通知されるでしょう。 呼び出しを調べた後に、彼は、それを受け入れるか、または拒否するかもしれません。 CRの可能な値は以下の通りです。
CR = OK Connection begun, listening
CRは聴いて、始められたOK Connectionと等しいです。
CR = BUSY
CR=忙しいです。
Newkirk, et al. [Page 3] RFC 55 Prototypical Implementation of NCP June 1970
ニューカーク、他 [3ページ] NCP1970年6月のRFC55Prototypical実現
CR = NOROOM
CRはNOROOMと等しいです。
CR = IMP DEAD
CRは悪童死者と等しいです。
CR = LINK DEAD
CRはリンク死者と等しいです。
ACCEPT (P, CR)
受け入れてください。(P、CR)
P specifies a port of the process
CR the condition code returned
Pは条件コードが返した過程CRのポートを指定します。
Accept implies that the user process has inspected the foreign
socket to determine who is calling and will accept the call.
(Note: an interesting alternative defines ACCEPT as the implicit
default condition. Thus any incoming RFC automatically satisfies
a LISTEN.) Possible values of CR are:
受け入れてください。ユーザ・プロセスがだれが電話をしているかを決定するために外国ソケットを点検したのを含意して、呼び出しを受け入れるでしょう。 (以下に注意してください。 おもしろい代替手段は暗黙のデフォルト条件とACCEPTを定義します。 したがって、どんな入って来るRFCも自動的にLISTENを満たします。) CRの可能な値は以下の通りです。
CR = BADSKT
CRはBADSKTと等しいです。
CR = NOROOM
CRはNOROOMと等しいです。
CR = IMP DEAD
CRは悪童死者と等しいです。
CR = LINK DEAD
CRはリンク死者と等しいです。
CR = BADCOMM Illegal command sequence. (E.g., Accept issued
before a LISTEN.
CRはBADCOMM Illegalコマンド・シーケンスと等しいです。 (例えばLISTENの前で発行されたAccept。
CR = PREMCLS Foreign user aborted connection after RFC was
locally received but before Accept was executed.
局所的にRFCを受け取った後にもかかわらず、Acceptを実行する前を除いて、PREMCLS Foreign CR=ユーザは接続を中止しました。
TRANSMIT (P, BUFF, BITSRQST, BITSACC, CR)
伝わってください。(P、ファン、BITSRQST、BITSACC、CR)
P specifies a port of the process
BUFF specifies the text buffer for transmission
BITSRQST specifies the length to be transmitted in bits
BITSACC returns the number of bits actually transmitted
CR the condition code returned
Pが指定する、過程BUFFのポートはビットBITSACCが実際に伝えられたビットの数を返す伝えられたコネが条件コードが返したCRであったならBITSRQSTが長さを指定するトランスミッションのためのテキストバッファを指定します。
Transmission takes place. Possible values for CR are:
トランスミッションは行われます。 CRに、可能な値は以下の通りです。
CR = OK
CRはOKと等しいです。
CR = IMP DEAD
CRは悪童死者と等しいです。
CR = LINK DEAD
CRはリンク死者と等しいです。
Newkirk, et al. [Page 4] RFC 55 Prototypical Implementation of NCP June 1970
ニューカーク、他 [4ページ] NCP1970年6月のRFC55Prototypical実現
CR = NOT OPEN Connection is not open (illegal command
sequence).
オープンCR=Connectionでないのは開いていません(不正コマンド系列)。
CR = BAD BOUND BITSRQST out of bounds (e.g., for a receive
socket BUFF was shorter than BITSRQST
indicated).
CRが区域外にBAD BOUND BITSRQSTと等しい、(例えば、aに関して、受信してください、ソケットBUFFがBITSRQSTが示したより短かった、)
INT (P, CR)
INT(P、CR)
P specifies the local socket of this process
CR the condition code returned
Pは条件コードが返したこの過程CRの地方のソケットを指定します。
The process on the other (foreign) side of this port is to be
interrupted. Possible values of CR are:
このポート反対の(外国)の側の過程は中断されることです。 CRの可能な値は以下の通りです。
CR = OK
CRはOKと等しいです。
CR = BADSKT
CRはBADSKTと等しいです。
CR = BADCOMM
CRはBADCOMMと等しいです。
CR = IMP DEAD
CRは悪童死者と等しいです。
CR = LINK DEAD
CRはリンク死者と等しいです。
STATUS (P, RTAB, CR)
状態(P、RTAB、CR)
P specifies a port of this process
RTAB the returned rendezvous table entry
CR the condition code returned
Pは条件コードが返したこの過程RTAB返されたランデブーテーブル項目CRのポートを指定します。
The relevant fields of the rendezvous table entry associated with
this port are returned in RTAB. This is the mechanism a user
process employs for monitoring the state of a connection.
Possible values of CR are:
RTABでこのポートに関連しているランデブーテーブルエントリーの関連野原を返します。 これはユーザ・プロセスが接続の状態をモニターするのに使うメカニズムです。 CRの可能な値は以下の通りです。
CR = OK
CRはOKと等しいです。
CR = BADSKT
CRはBADSKTと等しいです。
Newkirk, et al. [Page 5] RFC 55 Prototypical Implementation of NCP June 1970
ニューカーク、他 [5ページ] NCP1970年6月のRFC55Prototypical実現
CLOSE (P, CR)
閉鎖(P、CR)
P specifies a port of this process
CR the condition code returned
Pは条件コードが返したこの過程CRのポートを指定します。
Activity on the connection attached to this port stops, the
connection is broken and the port becomes free for other use.
Possible values of CR are:
このポートに付けられた接続の活動は止まります、そして、接続は失意です、そして、ポートは他の使用に自由になります。 CRの可能な値は以下の通りです。
CR = OK
CRはOKと等しいです。
CR = BADSKT
CRはBADSKTと等しいです。
CR = BADCOMM
CRはBADCOMMと等しいです。
CR = IMP DEAD
CRは悪童死者と等しいです。
CR = LINK DEAD
CRはリンク死者と等しいです。
IV. The NCP - Gross Structure
IV。 NCP--総計の構造
We view the NCP as having five component programs, several associative tables, and some queues and buffers.
私たちはいくつかの5つのコンポーネントプログラム、数個の結合しやすいテーブル、待ち行列、およびバッファを持っているとNCPをみなします。
The Component Programs (see Fig. 4.1)
コンポーネントプログラム(図4.1を参照します)
1. The Input Handler
1. 入力操作者
This is an interrupt-driven routine. It initiates Imp-to-Host
transmission into a resident buffer and wakes up the input
interpreter when transmission is complete.
これは中断駆動のルーチンです。 それは、Impからホストへのトランスミッションに居住しているバッファを伝授して、トランスミッションが完全であるときに、入力インタプリタを起こします。
2. The Output Handler
2. 出力操作者
This is an interrupt-driven output routine. It initiates Host-
to-Imp transmission out of a resident buffer and wakes up the
output scheduler when transmission is complete.
これは中断駆動の出力ルーチンです。 それは、居住しているバッファから悪童へのHostトランスミッションを開始して、トランスミッションが完全であるときに、出力スケジューラを起こします。
3. The Input Interpreter
3. 入力インタプリタ
This program decides whether the input is a regular message
intended for a user, a network control message, an Imp-to Host
message, or an error. For each class of message this program
invokes a subroutine to take the appropriate action.
このプログラムは、入力がユーザのために意図する通常のメッセージであるかどうか決めます、ネットワーク制御メッセージ、Imp、-、Hostメッセージ、または、誤り。 それぞれのクラスのメッセージに関しては、このプログラムは、適切な行動を取るためにサブルーチンを呼び出します。
Newkirk, et al. [Page 6] RFC 55 Prototypical Implementation of NCP June 1970
ニューカーク、他 [6ページ] NCP1970年6月のRFC55Prototypical実現
4. The Output Scheduler
4. 出力スケジューラ
Three classes of messages are sent to the Imp
3つのクラスに関するメッセージをImpに送ります。
(a) Host-to-Imp messages
(b) Control messages
(c) Regular messages
(a) ホストから悪童メッセージ(b)コントロールメッセージ(c)通常のメッセージ
We believe that a priority should be imposed among these
classes. The priority we suggest is the ordering above. The
output scheduler selects the highest priority message and
passes it to the output handler.
私たちは、優先がこれらのクラスで課されるべきであると信じています。 優先権は上での私たちが、示唆する注文です。 出力スケジューラは、最優先メッセージを選択して、出力操作者にそれを渡します。
Host-to-Imp messages are processed first come first served.
Control messages are processed individually by host, each host
being taken in turn. A control message queue for each foreign
host is provided. When any particular host is scheduled for
output, as many control commands for that host as will fit are
concatenated into a single message. Regular messages are
processed in groups by host and link, each unique combination
being taken in turn.
ホストから悪童へのメッセージは処理先着順です。 コントロールメッセージはホスト、順番にかかるそれぞれのホスト存在によって個別に処理されます。 各異種宿主のためのコントロールメッセージキューを提供します。 どんな特定のホストも出力のために予定されているとき、合うのとそのホストにとっての同じくらい多くの制御コマンドがただ一つのメッセージに連結されます。 それぞれのユニークな組み合わせが順番にかかって、通常のメッセージは、ホストによるグループで処理されて、リンクされます。
5. The System Call Interpreter
5. システムコールインタプリタ
This program interprets requests from the user. Each system
call has a corresponding routine which takes the appropriate
action.
このプログラムはユーザからの要求を解釈します。 各システムコールには、適切な行動を取る対応するルーチンがあります。
The two interesting components are the input interpreter and the
system call interpreter. These are similar in that the input
interpreter services foreign requests and the system call
interpreter services local requests.
2つのおもしろいコンポーネントが、入力インタプリタとシステムコールインタプリタです。 これらは入力インタプリタが外国要求を修理するという点において同様です、そして、システムコールインタプリタはローカルの要求を修理します。
The diagram in Figure 4.1 is our conception of the Network
Control Program. Squishy amoeba-like objects represent component
programs, cylinders represent queues, and the arrows represent
data paths. In this simplified diagram tables are not shown.
["Amoeba-like" objects in original hand drawing are now firm
rectangular boxes: Ed.]
図4.1のダイヤグラムは私たちのNetwork Control Programに関する概念です。 ぐにゃぐにゃのアメーバのような物はコンポーネントプログラムを表します、そして、シリンダは待ち行列を表します、そして、矢はデータ経路を表します。 この略図で、テーブルは見せられません。 [オリジナルの手の図面の「アメーバのような」物は現在堅い長方形の箱です: エド]
The abbreviated labels in the figure have the following meanings:
図の簡略化されたラベルには、以下の意味があります:
HIQ - Host-to-Imp Queue
OCCQ - Output Control Command Queue
DQ - Data Queue
IHBUF - Input Handler Buffer
OHBUF - Output Handler Buffer
HIQ--ホストから悪童への待ち行列OCCQ--アウトプット・コントロールコマンド待ち行列DQ--データ待ち行列IHBUF--入力操作者バッファOHBUF--出力操作者バッファ
Newkirk, et al. [Page 7] RFC 55 Prototypical Implementation of NCP June 1970
ニューカーク、他 [7ページ] NCP1970年6月のRFC55Prototypical実現
____________
| USER | STRUCTURE OF THE NETWORK CONTROL PROGRAM
|____________|
^ | Fig. 4.1
_____|______V____
| |
| System |
| Call |
| Interpreter |
|_________________| _____________
^ | | | |
| | | +---------------| Input |
| | | | +-----| Interpreter |
| | | | | | |
| V V V V -------------
|======| |=========| |=======| | ^
| D Q | | O C C Q | | H I Q | | |
|======| |=========| |=======| | |
| ^ | | | |
| | | | | |
| +--------)----------)---------+ |
| | | |
+-------+ | +------+ |
__V___V___V__ |
| | |
| Output | |
| Scheduler | |
|_____________| |
| |
V |
(===========) (===========)
( O H B U F ) ( I H B U F )
(===========) (===========)
| ^
______V______ ______|______
| | | |
| Output | | Input |
| Handler | | Handler |
| | | |
------------- -------------
| ^
| |
+----------+ +-----------+
| |
____V____|____
| |
| I M P |
|______________|
____________ | ユーザ| ネットワーク・コントロール・プログラムの構造|____________| ^ | 図4.1_____|______V____ | | | システム| | 呼び出し| | インタプリタ| |_________________| _____________ ^ | | | | | | | +---------------| 入力| | | | | +-----| インタプリタ| | | | | | | | | V V V V------------- |======| |=========| |=======| | ^ | D Q| | ○ C C Q| | H I Q| | | |======| |=========| |=======| | | | ^ | | | | | | | | | | | +--------)----------)---------+ | | | | | +-------+ | +------+ | __V___V___V__| | | | | 出力| | | スケジューラ| | |_____________| | | | V| (===========) (===========) (○ H B U F) (I H B U F) (===========) (===========) | ^ ______V______ ______|______ | | | | | 出力| | 入力| | 操作者| | 操作者| | | | | ------------- ------------- | ^ | | +----------+ +-----------+ | | ____V____|____ | | | I M P| |______________|
Newkirk, et al. [Page 8] RFC 55 Prototypical Implementation of NCP June 1970
ニューカーク、他 [8ページ] NCP1970年6月のRFC55Prototypical実現
V. Tables in the NCP
V。 NCPのテーブル
We envision that the bulk of the NCP's data base is in associative tables. By "associative" we mean that there is some lookup routine which is presented with a key and either returns successfully with a pointer to the corresponding entry, or fails if no entry corresponds to the key. The major tables are as follows:
私たちはそれを思い描きます。NCPのデータベースの大半が結合しやすいテーブルにあります。 「結合しやすいこと」で、私たちは、キーを与えて、首尾よく対応するエントリーにポインタとともに帰るか、またはエントリーが全くキーに対応していないなら失敗する何らかのルックアップルーチンがあると言っています。 主要なテーブルは以下の通りです:
1. The Rendezvous Table
1. ランデブーテーブル
This table holds the attributes of a connection. The table is
accessed by the local socket, but other tables may have
pointers to existing entries.
このテーブルは接続の属性を保持します。 テーブルは地方のソケットによってアクセスされますが、他のテーブルは既存のエントリーにポインタを持っているかもしれません。
The components of an entry are:
エントリーのコンポーネントは以下の通りです。
(a) Local Socket
(b) Foreign Socket
(c) Link
(d) Connection State
(e) Flow State
(f) Data Queue
(g) Call Queue
(h) Port Pointer
(i) Their Buffer Size (only needed on the send side)
(j) Error State
(a) 地方のSocketの(b)外国Socket(c)リンク(d)接続州(e)流動州(f)データQueue(g)が、Queue(h)ポートPointer(i)をそれらのBuffer Sizeと呼ぶ、(必要であるだけである、側) (j) 誤り州を送ってください。
An entry is created when either a CONNECT or a LISTEN system
call is executed or when a request for connection is received.
Various fields remain unused until after the connection is
established.
CONNECTかLISTENシステムコールのどちらかが実行されるか、または接続を求める要求が受信されているとき、エントリーは作成されます。 接続が確立された後まで多岐は未使用のままで残っています。
2. The Input Link Table
2. 入力リンクテーブル
The input interpreter uses the concatenation of the foreign
host and link as a key into the input table. The table is used
in processing a user-destined message on an incoming link by
providing a pointer into the rendezvous table.
入力インタプリタはキーとして異種宿主とリンクの連結を投入表に使用します。 テーブルはランデブーテーブルにポインタを供給することによってユーザによって運命づけられたメッセージを入って来るリンクに処理する際に使用されます。
3. The Output Link Table
3. 出力リンクテーブル
The input interpreter uses the output link table to access the
flow state as RFNM's return from transmitted messages. The
output link table is keyed by host and link and provides a
pointer into the rendezvous table.
入力インタプリタは、RFNMのリターンとして伝えられたメッセージから流れ状態にアクセスするのに出力リンクテーブルを使用します。 出力リンクテーブルは、ホストとリンクによって合わせられて、ランデブーテーブルにポインタを供給します。
Newkirk, et al. [Page 9] RFC 55 Prototypical Implementation of NCP June 1970
ニューカーク、他 [9ページ] NCP1970年6月のRFC55Prototypical実現
4. The Port Table
4. ポートテーブル
The system call interpreter uses the concatenation of the
process identification and the port identification as a key to
obtain a pointer into the rendezvous table.
システムコールインタプリタは、ランデブーテーブルにポインタを入手するのにキーとして過程識別とポート識別の連結を使用します。
5. The Output Control Command Table
5. アウトプット・コントロールコマンド表
The system call interpreter and the input interpreter use this
table to make entries in the appropriate output control command
queues. Commands are queued in separate table entries
corresponding to foreign hosts. Before output the contents of
the queue are concatenated into a large control message. The
components of an entry are:
システムコールインタプリタと入力インタプリタは、適切なアウトプット・コントロールにおけるエントリーをコマンド待ち行列にするのにこのテーブルを使用します。 コマンドは異種宿主にとって、対応する別々のテーブル項目に列に並ばせられます。 出力される前に、待ち行列の内容は大きいコントロールメッセージに連結されます。 エントリーのコンポーネントは以下の通りです。
(a) Host
(b) Output Control Command Queue
(a)ホスト(b)アウトプット・コントロールコマンド待ち行列
6. The Output Request Queue
6. 出力要求待ち行列
This queue contains an entry for each connection which has data
requiring transmission to the net. There is only one entry per
connection, which is deleted when the last packet of data is
transmitted and is entered whenever a user makes a system
request for data transmission.
この待ち行列はネットにトランスミッションを必要とするデータを持っている各接続のためのエントリーを含んでいます。 1接続あたり1つのエントリーしかありません。(接続は、データの最後のパケットが伝えられるとき、削除されて、ユーザがデータ伝送を求めるシステム要求をするときはいつも、入られます)。
The entry is re-inserted if transmission is not completed
(message too long) or is prevented by the flow control
mechanism. The only component of an entry is a local socket.
トランスミッションが終了されていないか(あまりに長い間、通信します)、またはフロー制御メカニズムによって防がれるなら、エントリーは再び差し込まれます。 エントリーの唯一のコンポーネントが地方のソケットです。
7. The Host Live Table
7. ホストの動いているテーブル
This is a simple table listing the hosts which are alive. This
table is checked before establishing a connection and before
sending any data to ensure that the destination host actually
exists. At present the protocol does not define the procedure
to be followed for the Host up/Host down conditions. See
NWG/RFC#57.
これはホストを記載する単純分類表です(生きています)。 取引関係を築く前とあて先ホストが実際に存在するのを保証するためにどんなデータも送る前に、このテーブルはチェックされます。 現在のところ、プロトコルは、Hostのために状態で/ホストで続かれるように手順を定義しません。 NWG/RFC#57を見てください。
8. The Link Assignment Table
8. リンク課題テーブル
Link numbers are assigned by the receiver. This table records
which links are free and can, therefore, be assigned.
受信機はリンク番号を割り当てます。このテーブルは、どのリンクが無料であるかを記録して、したがって、割り当てることができます。
Newkirk, et al. [Page 10] RFC 55 Prototypical Implementation of NCP June 1970
ニューカーク、他 [10ページ] NCP1970年6月のRFC55Prototypical実現
VI. Informal Description of Network Operations
VI。 ネットワークオペレーションの非公式の記述
We present here narratives describing the operation conducted during the three major phases of network usage: opening, flow control, and closing.
私たちはここにネットワーク用法の3つの主要な段階の間に行われた操作について説明する物語を提示します: 始まり、フロー制御、および閉鎖。
A. Opening
A.始まり
In order to establish a connection for data transmission, a pair
of RFC's must be exchanged. An RTS must go from the receive-side
to the send-side, and an STR must be issued by the send-side to
the receive-side. In addition, the receive-side, in its RTS, must
specify a link number. These RFC's (RFC is a generic term
encompassing RTS and STR) may be issued in any time sequence. A
provision must also be made for queuing pending calls (i.e., RFC's
which have not been dealt with by the user program). Thus, when a
user is finished with a connection, he may choose to examine the
next pending call from another process and decide to either accept
or refuse the request for connection. A problem develops because
the user may not choose to examine his pending calls; thus they
will merely serve to occupy queue space in the NCP. Several
alternative solutions to this problem will be mentioned later.
データ伝送のために取引関係を築くために、RFCの1組のものを交換しなければなりません。 RTS、側を発信させて、STRに側を受け取っている必須からの碁を発行しなければならない、側を発信させる、側を受け取ります。 さらに、RTSに側を受け取るのはリンク番号を指定しなければなりません。 RFCのこれらのもの(RFCはRTSとSTRを取り囲む総称である)はどんな時間系列でも発行されるかもしれません。 また、未定の要求(すなわち、ユーザ・プログラムで対処されていないRFCのもの)を列に並ばせるのに備えなければなりません。 ユーザが接続を終えているとき、したがって、彼は、別の過程から次の未定の呼び出しを調べて、接続を求める要求を受け入れるか、または拒否すると決めるのを選ぶかもしれません。 ユーザが、彼の未定の呼び出しを調べるのを選ばないかもしれないので、問題は発生します。 したがって、それらは、NCPの待ち行列スペースを占めるのに単に役立つでしょう。 この問題のいくつかの代替の解決が後で言及されるでしょう。
Utilizing the framework of the prototype system calls described
above, we envision at least four temporal sequences for obtaining
a successfully opened connection:
上で説明された原型システムコールの枠組みを利用して、私たちは首尾よく開かれた接続を得るために少なくとも4つの時の系列を思い描きます:
1. The user may issue a LISTEN, indicating he is willing to
consider connecting to anyone who sends him an RFC. When an
RFC comes in the user is notified. The user then decides
whether he wishes to connect to this socket and issues an
ACCEPT or a CLOSE on the basis of that decision. A CLOSE '
refuses' the connection, as discussed under "Closing." An
ACCEPT indicates he is willing to connect; an RFC is issued,
and the connection becomes fully opened.
1. 彼が、RFCを彼に送るだれにも接すると考えても構わないと思っているのを示して、ユーザはLISTENを発行するかもしれません。 RFCが入るとき、ユーザは通知されます。 そして、ユーザは、その決定に基づいてこのソケットと問題にACCEPTかCLOSEを接続したがっているかどうか決めます。 CLOSEは「閉鎖」の下で議論するように接続を'拒否します'。 ACCEPTは、彼が、接続しても構わないと思っているのを示します。 RFCは発行されます、そして、接続は完全に開かれるようになります。
2. Upon processing a user request for a LISTEN, the NCP
discovers that a pending call exists for that local socket.
The user is immediately notified, and he may ACCEPT or
CLOSE, as above.
2. LISTENを求めるユーザ要求を処理すると、NCPは、未定の呼び出しがその地方のソケットのために存在すると発見します。 ユーザにすぐに通知されます、そして、彼は同じくらい上のACCEPTかCLOSEに通知するかもしれません。
3. The user issues a CONNECT, specifying a particular foreign
socket that he would like to connect to. An RFC is issued.
If the foreign process accepts the request, it answers by
returning an RFC. When this acknowledging RFC is received,
the connection is opened.
3. 彼が接続したがっている特定の外国ソケットを指定して、ユーザはCONNECTを発行します。 RFCは発行されます。 外国過程が要請を受け入れるなら、RFCを返すことによって、それに答えます。 この承認RFCが受け取られているとき、接続は開かれます。
Newkirk, et al. [Page 11] RFC 55 Prototypical Implementation of NCP June 1970
ニューカーク、他 [11ページ] NCP1970年6月のRFC55Prototypical実現
4. When presented with a CONNECT, the NCP may discover that a
pending call exists from the specified foreign socket to the
local socket in question. An acknowledging RFC is issued
and the connection is opened.
4. CONNECTを与えるとき、NCPは、未定の呼び出しが指定された外国ソケットから地方の問題のソケットまで存在すると発見するかもしれません。 承認RFCは発行されます、そして、接続は開かれます。
In all of the above cases the user is notified when the connection
is opened, but data flow cannot begin until buffer space is
allocated and an ALL command is transmitted.
接続が開かれるとき、上の場合では、全部で、ユーザに通知しますが、データフローはバッファ領域を割り当てて、すべてのコマンドを伝えるまで始まることができません。
Any of these connection scenarios will be interrupted if a CLS
comes in, as discussed under "Closing."
CLSが入ると、これらの接続シナリオのいずれも「閉鎖」の下で議論するように中断されるでしょう。
1. Pending Call Queues
1. 未定の呼び出し待ち行列
It is essential that some form of queuing for pending RFC's
be implemented. A simple way to see this is to examine a
typical LISTEN-CONNECT sequence. One side issues a LISTEN,
the other a CONNECT. If the LISTEN is issued before the RFC
coming from the remote CONNECT arrives, all is fine.
However, due to the asynchronous nature of the net, we can
never guarantee that this sequence of events will occur. If
calls are not queued, and the RFC comes in before the LISTEN
is issued, it will be refused; if it arrives later, it will
be accepted. Thus we have an extremely ambiguous situation.
未定のRFCのもののための何らかのフォームの列を作りが実行されるのは、不可欠です。 これを見る簡単な方法は典型的なLISTEN-CONNECT系列を調べることです。 半面はLISTENを発行して、もう片方がCONNECTです。 リモートCONNECTから来るRFCが到着する前にLISTENが発行されるなら、すべてがすばらしいです。 しかしながら、ネットの非同期的性質のため、私たちは、出来事のこの系列が起こるのを決して保証できません。 呼び出しが列に並ばせられないで、LISTENが発行される前にRFCが入ると、それは拒否されるでしょう。 後で到着すると、それを受け入れるでしょう。 したがって、私たちには、非常にあいまいな状況があります。
Unless one has infinite queue space, it is desirable that
some mechanism for purging the queues of old RFC's which the
user never bothered to examine. An obvious but informal
method is to note the time when each RFC is entered into the
queue, and then periodically refuse all RFC's which have
exceeded some arbitrary time limit. Another thought, which
probably should be included within the context of any
scheme, is for the NCP to send a CLS on all outstanding
connections or pending calls when a user logs out or blows
up.
1つに無限の待ち行列スペースがない場合、それが望ましい、それ、待ち行列からユーザが決して苦しめなかった古いRFCのものを一掃するための何らかのメカニズムが調べます。 明白な、しかし、非公式の方法は、各RFCが待ち行列に入れられる時に注意して、次に、定期的に何らかの任意のタイムリミットを超えていたRFCのすべてのものを拒否することです。 別の考え(たぶんどんな計画の文脈の中にも含まれるべきである)はユーザがログアウトするか、または爆発するとNCPがすべての傑出している接続か未定の呼び出しにCLSを送ることです。
The scheme which is utilized in this description may seem at
first blush to be non-intuitive; but we feel it is more
realistic than other proposals. Basically, when a CONNECT
is issued, the NCP assumes that this socket wishes to talk
to the specified foreign socket and to that socket only. It
therefore purges from the pending call queue all non-
matching RFC's by sending back CLS's. Similarly, when the
connection is in the RFC-SEND state (a CONNECT has been
issued), all non-matching RFC's are refused. If a LISTEN-
ACCEPT or LISTEN- CLOSE sequence is executed, the remainder
この記述で利用される計画は非直感的であるように一見思えるかもしれません。 しかし、私たちは、それが他の提案より現実的であると感じます。 CONNECTが発行されるとき、基本的に、NCPは、このソケットが指定された外国ソケットと、そして、そのソケットだけと話したがっていると仮定します。 したがって、それは、非合っているRFCのすべてのものから未定の呼び出し待ち行列からCLSを返送することによって、追放します。 接続がRFC-SEND状態にあるとき(CONNECTは発行されました)、同様に、非合っているRFCのすべてのものが拒否されます。 LISTEN- ACCEPTかLISTEN- CLOSE系列が実行されるなら残り
Newkirk, et al. [Page 12] RFC 55 Prototypical Implementation of NCP June 1970
ニューカーク、他 [12ページ] NCP1970年6月のRFC55Prototypical実現
of the pending calls are not removed from the queue, in the
expectation that the user may wish to accept these requests
in the future.
未定では、呼び出しは待ち行列から取り除かれません、ユーザが将来これらの要求を受け入れたがっているかもしれない期待で。
Although the latter method may seem to be arbitrary and/or
unnecessarily restrictive, we have not yet concocted a
scenario which would be prohibited by this method, assuming
that we are dealing with a competent programmer (i.e., one
who is wary of race conditions and the asynchronous nature
of the net). Of course whatever scheme or schemes a
particular site chooses is highly implementation dependent;
we suggest that some provision for the queuing of RFC's be
provided for a period of time at least of the order of
magnitude that they are retained in the CONNECT-clear scheme
mentioned above.
後者の方法は任意である、そして/または、不必要に制限しているように思えるかもしれませんが、私たちはまだこの方法で禁止されているシナリオをでっち上げていません、私たちが有能なプログラマ(すなわち、競合条件とネットの非同期的性質に用心深い人)に対応していると仮定して。 特定のサイトがもちろんどういった計画か計画を選ぶかは、実現に非常に依存しています。 私たちは、RFCの列を作りへの何らかの支給が少なくともしばらくそれらが保有される桁では、はっきりとCONNECTが前記のように計画するかどうかということであると示唆します。
B. Flow Control
B.フロー制御
Meaningful data can only flow on a connection when it is fully
opened (i.e., two RFC's have been exchanged and closing has not
begun). We assume that the NCP's have a buffer for receiving
incoming data and that there is some meaningful quantity which
they can advertise (on a per connection basis) indicating the size
message they can handle. We further assume that the sending side
regulates its transmission according to the advertisements of that
size.
それが完全に開かれるときだけ(すなわち、2RFCのものを交換しました、そして、閉鎖は始まっていません)、重要なデータは接続に流れることができます。 私たちはNCPのものには受信データを受け取るためのバッファがあって、それらが扱うことができるサイズメッセージを示すそれらが広告を出すことができる(接続基礎あたりのaで)いくらかの重要な量があると思います。 私たちは、そのサイズの広告によると、送付側がトランスミッションを整えるとさらに思います。
When a connection is opened, a cell (called 'Their Size') is set
to zero. The receive-side will decide how much space it can
allocate and send an ALL message specifying that space. The
send-side will increment 'Their Size' by the allocated space and
will then be able to send messages of length less than or equal to
'Their Size' When messages are transmitted, the length of the
message is subtracted from 'Their Size'. When the receive-side
allocates more buffer space (e.g. when a message is taken by the
user, thus freeing some system buffer space), the number of bits
released is sent to the send-side via an ALL message.
接続が開かれるとき、セル('それらのSize'と呼ばれる)はゼロに設定されます。 側を受け取るのは、それがどのくらいのスペースを割り当てることができるかを決めて、すべてのメッセージにそのスペースを指定させるでしょう。 側を発信させるのは割り振りスペースのそばで'それらのSize'を増加するでしょう、そして、そして、より'それらのSize'Whenメッセージは送られて、メッセージの長さは'それらのSizeから引き算されること'を長さに関するメッセージに送ることができるでしょう。 側を受け取るのが、より多くのバッファ領域を割り当てるとき(例えば、伝言はいつユーザが受け取られますか、その結果、何らかのシステムバッファ領域を解放します)、放出されたビットの数に発信します。すべてのメッセージで側を発信させます。
Thus, 'Their Size' is never allowed to become negative and no
transmission can take place if 'Their Size' equals zero.
したがって、'それらのSize'は否定的に決してなることができません、そして、'それらのSize'がゼロと等しいなら、トランスミッションは全く行われることができません。
Notice that the lengths specified in ALL messages are increments
not the absolute size of the receiving buffer. This is
necessitated by the full duplex nature of the flow control
protocol. The length field of the ALL message can be 32 bits long
(note: this is an unsigned integer), thus providing the facility
for essentially an infinite "bit sink", if that may ever be
desired.
すべてのメッセージで指定された長さが受信バッファの実寸ではなく、増分であるのに注意してください。 これはフロー制御プロトコルの全二重本質によって必要とされます。 長さの分野、すべてのメッセージ、長さ32ビットであることができます(注意: これは符号のない整数です)、その結果、本質的には無限の「噛み付いている流し台」に施設を提供します、それが今までに望まれるかもしれないなら。
Newkirk, et al. [Page 13] RFC 55 Prototypical Implementation of NCP June 1970
ニューカーク、他 [13ページ] NCP1970年6月のRFC55Prototypical実現
C. Closing
C.閉鎖
Just as two RFC's are required to open a connection, two CLS's are
required to close a connection. Closing occurs under various
circumstances and serves several purposes. To simplify the
analysis of race conditions, we distinguish four cases: aborting,
refusing, termination by receiver, termination by sender.
ちょうど2として、RFCのものは接続を開かなければならなくて、2CLSのものは接続を終えなければなりません。 閉鎖は、様々な状況で起こって、いくつかの目的に役立ちます。 競合条件の分析を簡素化するために、私たちは4つのケースを区別します: 受信機、送付者による終了で拒否することでの終了を中止します。
A user "aborts" a connection when he issues a CONNECT and then a
CLOSE before the CONNECT is acknowledged. Typically a user will
abort following an extended wait for the acknowledgment; his
system may also abort for him if he blows up.
CONNECTが承認される前にCONNECTと次にCLOSEを発行するとき、ユーザは接続を「中止になります」。 通常、ユーザは、承認のための拡張待ちに続くのを中止するでしょう。 また、彼が爆発するなら、彼のシステムは彼のために中止になるかもしれません。
A user "refuses" a connection when he issues a LISTEN and, after
being notified of a prospective caller, issues a CLOSE. Any
requests for connection to a socket which is expecting a call from
a particular socket are also refused.
ユーザは、彼がLISTENを発行するとき、接続を「拒否し」て、将来の訪問者について通知された後に、CLOSEを発行します。 また、特定のソケットから呼び出しを予想しているソケットとの接続を求めるどんな要求も拒否されます。
After a connection is established, either side may terminate. The
required sequence of events suggests that attempts to CLOSE by the
receive-side should be viewed as "requests" which are always
honored as soon as possible by the send-side. Any data which has
not yet been passed to the user, or which continues over the
network, is discarded. Requests to CLOSE by the send-side are
honored as soon as all data transmission is complete.
接続が確立された後に、どちらの側も終わるかもしれません。 CLOSEに、側を受け取るのは、そうであるべきです。それが試みる、出来事の必要な系列が、示すできるだけ早くいつも光栄に思っている「要求」を側を発信させるとみなしました。 まだユーザに渡されていないか、またはネットワークの上で続くどんなデータも捨てられます。 すべてのデータ伝送が完全であるとすぐに、側を発信させるのが光栄に思っているようCLOSEに要求します。
1. Aborting
1. 中止になります。
We may distinguish three cases:
私たちは3つのケースを区別するかもしれません:
a) In the simplest case, we send an RFC followed later by a
CLS. The other side responds with a CLS and the attempt
to connect ends.
a) 最も簡単な場合では、私たちは後でCLSによって続かれたRFCを送ります。 反対側はCLSと共に応じます、そして、接続する試みは終わります。
b) The foreign process may accept the connection
concurrently with the local process aborting it. In this
case, the foreign process will believe the local process
is terminating an open connection.
b) 外国過程は同時にそれを中止するローカルの過程で接続を受け入れるかもしれません。 この場合、外国過程は、ローカルの過程がオープンな接続を終えることであると信じるでしょう。
c) The foreign process may refuse the connection
concurrently with the local process aborting it. In this
case, the foreign process will believe the local process
is acknowledging its refusal.
c) 外国過程は同時にそれを中止するローカルの過程で接続を拒否するかもしれません。 この場合、外国過程は、ローカルの過程が拒否を承諾することであると信じるでしょう。
Newkirk, et al. [Page 14] RFC 55 Prototypical Implementation of NCP June 1970
ニューカーク、他 [14ページ] NCP1970年6月のRFC55Prototypical実現
2. Refusing
2. 拒否します。
After an RFC is received, the local host may respond with an
RFC or a CLS, or it may fail to respond. (The local host
may have already sent its own RFC, etc.) If the local host
sends a CLS, the local host is said to be "refusing" the
request for connection.
RFCが受け取られていた後に、ローカル・ホストがRFCかCLSと共にこたえるかもしれませんか、またはそれは応じないかもしれません。 (ローカル・ホストは既にそれ自身のRFCなどを送ったかもしれません) ローカル・ホストがCLSを送るなら、ローカル・ホストは接続を求める要求を「拒否している」と言われます。
We require that CLS commands be exchanged to close a
connection, so it is necessary for the local host to
maintain the rendezvous table entry until an acknowledging
CLS is returned.
私たちが、CLSコマンドが接続を終えるために交換されるのを必要とするので、ローカル・ホストが承認CLSを返すまでのランデブーテーブルエントリーを維持するのが必要です。
3. Terminating by the Sender
3. 送付者で、終わります。
When the user on the send side issues a CLOSE system call,
his NCP must accept it immediately, but may not send out a
CLS command until all the data in the local buffers has been
passed to the foreign host. It is thus necessary to test
for both 'buffer-empty' and
'RFNM-received' before sending the CLS command. As usual,
the CLS must be acknowledged before the entry may be
deleted.
ユーザである、オンである、CLOSEシステムコールを副次的な問題に送ってください、彼のNCPは、すぐにそれを受け入れなければなりませんが、ローカルのバッファのすべてのデータが異種宿主に渡されるまで、CLSコマンドから発信しないかもしれません。 その結果、'バッファ空'の、そして、CLSを送る前ともに'RFNMが受け取られていている'コマンドがないかどうかテストするのが必要です。 いつものように、エントリーが削除されるかもしれない前にCLSを承認しなければなりません。
4. Terminating by the Receiver
4. 受信機で、終わります。
When the user on the receive side issues a CLOSE system
call, his NCP accepts and sends the CLS command immediately.
Data may still arrive, however, and this data should be
discarded. The send side, upon receiving the CLS, should
immediately terminate the data flow.
ユーザである、オンである、副次的な問題a CLOSEシステムコールを受けてください、彼のNCPは、すぐに、CLSコマンドを受け入れて、送ります。 しかしながら、データはまだ到着しているかもしれません、そして、このデータは捨てられるべきです。 CLSを受けるとき側を送ってください、そして、すぐに、データフローを終えるべきです。
VII. Connection Status
VII。 接続形態
An excellent mechanism for describing the sequence of events required to establish and terminate a connection involves a state diagram. We may assume that each socket can be associated with a state machine, and that this state machine may, at any time, be in one of ten possible states. In any state, certain network events cause the connection status to enter another state; other events are ignored; still others are error. A transition may also involve the local NCP performing some action. Figure 7.1 depicts the state machine. Circles [now boxes: Ed] represent states (described below); arrows show legal transitions between states. The labels on the arrows identify the event which caused them (note that CLOSE is a system call, CLS is a control command). Phrases after slashes denote the action which should be performed while traveling over that arrow. The arrow labeled '[E]RFC' (found between states 0 and 1) represents
接続を確立して、終えるのに必要である出来事の系列について説明するための素晴らしいメカニズムは州のダイヤグラムにかかわります。 私たちは各ソケットを州のマシンに関連づけることができて、この州のマシンがいつでも10の可能な州の1つにあるかもしれないと思うかもしれません。 どんな状態でも、あるネットワークイベントで、接続形態は別の状態に入ります。 他の出来事は無視されます。 それでも、他のものは誤りです。 また、変遷は何らかの動作を実行するローカルのNCPにかかわるかもしれません。 図7.1は州のマシンについて表現します。 円[現在の箱: エド]は州(以下で、説明される)を代表します。 矢は州の間の法的な変遷を示しています。 矢の上のラベルはそれらを引き起こした出来事を特定します(CLOSEがシステムコールであるというメモ、CLSは制御コマンドです)。 スラッシュの後の句はその矢の上を旅行している間に実行されるべきである動作を指示します。 矢が'[E] RFC'をラベルした、(州0と1の間で見つけられます)表す。
Newkirk, et al. [Page 15] RFC 55 Prototypical Implementation of NCP June 1970
ニューカーク、他 [15ページ] NCP1970年6月のRFC55Prototypical実現
the condition that whenever a connection enters the CLOSED state, the pending call queue for that connection is checked [Original was backwards "E": Ed.]
接続がCLOSED状態に入るときはいつも、その接続のための未定の呼び出し待ち行列がチェックされるという条件[オリジナルは遅れている「E」でした: エド]
If any pending calls exist in the queue, the connection moves to the PENDING state. If an RFC is received for a socket in the CLOSED state, it is also moved along this path to the PENDING state. Events and the actions they cause are described in sections VIII and IX below. Descriptions of the ten states follow:
何か未定の呼び出しが待ち行列で存在しているなら、接続はPENDING状態に移ります。 また、CLOSED状態のソケットのためにRFCを受け取るなら、この経路に沿ってそれをPENDING状態に動かします。 それらが引き起こす出来事と動作は以下でセクションVIIIとIXで説明されます。 10の州の記述は続きます:
(0) CLOSED
閉じられた(0)
The local socket is not attached to any port and no user has
requested a connection with it. (The table entry is non-
existent).
地方のソケットはどんなポートにも取り付けられません、そして、どんなユーザもそれとの接続を要求していません。 (テーブル項目は非目下です。)
(1) PENDING CALL
(1) 未定の呼び出し
The socket is not attached to any port but one or more
requests for connection have been received. A LISTEN system
call will be satisfied immediately by the first entry in the
pending call queue for a matching request; all other pending
calls are deleted.
どんなポートにもソケットを取り付けませんが、接続を求める1つ以上の要求を受け取りました。 LISTENシステムコールはすぐ合っている要求のための未定の呼び出し待ち行列における初記入で満たされるでしょう。 他のすべての未定の呼び出しが削除されます。
(2) LISTENING
(2) 聴取
The socket is attached to a port. We are waiting for a user
to request connection with this socket.
ソケットはポートに取り付けられます。 私たちは、ユーザがこのソケットとの接続を要求するのを待っています。
(3) RFC-RCVD
(3) RFC-RCVD
We are listening and an RFC was received. The local user has
been informed of the pending call. He must respond with
either a CLOSE or an ACCEPT.
私たちは聴いています、そして、RFCを受け取りました。 地元のユーザは未定の呼び出しにおいて知識があります。 彼はCLOSEかACCEPTのどちらかと共に応じなければなりません。
(4) ABORT
(4)アボート
We have notified the user that his LISTEN has been satisfied
but he has not yet responded; if during this time the foreign
user aborts the connection by sending a CLS, we send a CLS to
acknowledge the abort and mark the fact with this state. When
the user accepts or refuses the call, we can inform him the
connection has been prematurely terminated.
私たちは、彼のLISTENが満足したことをユーザに通知しましたが、彼はまだ応じていません。 この間に外国人のユーザがCLSを送ることによって接続を中止するなら、私たちは、アボートを承諾して、この状態を事実に付けるためにCLSを送ります。 ユーザが呼び出しを受け入れるか、または拒否するとき、私たちは彼に知らせることができます。終えられて、早まって、接続はそうです。
Newkirk, et al. [Page 16] RFC 55 Prototypical Implementation of NCP June 1970
ニューカーク、他 [16ページ] NCP1970年6月のRFC55Prototypical実現
(5) RFC-SENT
(5)はRFC発信しました。
This state is entered when:
この状態が入られる、いつ:
a) The local user has attached this socket to a port by
issuing a CONNECT.
b) An RFC has been sent, and
c) No reply has been received.
a) ユーザがCONNECT. bを発行しながらポートへのこのソケットを取り付けたローカル) RFCを送った、c) 回答を全く受け取っていません。
When the user issues a CONNECT the pending call queue is
searched.
ユーザがCONNECTを発行するとき、未定の呼び出し待ち行列は捜されます。
If a matching RFC is not found, the queue is deleted and this
state is entered. As new RFC's arrive they are compared with
our user's request. If they do not match, the RFC is
immediately refused. If the RFC matches, it completes the
initialization process and the connection enters the OPEN
state.
合っているRFCが見つけられないなら、待ち行列は削除されます、そして、この状態は入られます。 新しいRFCのものが到着するとき、それらは私たちのユーザの要求と比較されます。 彼らが合っていないなら、RFCはすぐに、拒否されます。 RFCが合っているなら、初期化の過程を完了します、そして、接続はオープン状態に入れます。
(6) OPEN
(6) 戸外
RFC's have been exchanged and the connection is securely
established. Transmission may begin following receipt of an
ALL command from the receive side, and will then proceed
subject to flow control.
RFCを交換しました、そして、しっかりと接続を確立します。 トランスミッションが、すべてのコマンドの領収書に従い始めるかもしれない、側を受け取ってください、そして、次に、フロー制御を条件として続くでしょう。
(7) CLS-WAIT
(7)CLS-待ち
After the local user has executed a CLOSE, and we have issued
a CLS, we must wait for an acknowledging CLS before the
connection can be completely closed. If the appropriate CLS
has not already been received, this state is entered.
地元のユーザがCLOSEを実行して、CLSを発行した後に、接続が完全に閉店できる前に私たちは承認CLSを待たなければなりません。 適切なCLSが既に受け取られていないなら、この状態は入られます。
(8) DATA-WAIT
(8)データ待ち
If we are on the send side and the local user executes a CLOSE
system call, a CLS cannot be issued if our data buffer is not
empty or if a RFNM for the last data message is outstanding.
The connection enters this state to wait for these conditions
to be fulfilled. Upon completion and acknowledgement of
output a CLS may be issued and the connection enters the CLS-
WAIT state, waiting for the acknowledging CLS. If a CLS
arrives while in the DATA-WAIT state we clear our buffer (the
CLS came from a receive socket, indicating it is no longer
interested in our data) and enter the RFNM-WAIT state to wait
for the network to clear.
私たちがオンである、側を送って、地元のユーザはCLOSEシステムコールを実行し、私たちのデータバッファが空でないか、または最後のデータメッセージのためのRFNMが傑出しているなら、CLSは発行できません。 接続は、これらの実現するべき状態を待つためにこの状態に入ります。 出力の完成と承認のときに、CLSは発行されるかもしれません、そして、接続はCLS- WAIT状態に入って、承認の待ちはCLSです。 CLSが中間、到着するなら、DATA-WAITは、私たちがバッファをきれいにする(CLSはaからソケットを受けに来ました、それがもう私たちのデータに興味を持っていないのを示して)と述べて、ネットワークがきれいにされるのを待つためにRFNM-WAIT状態に入ります。
Newkirk, et al. [Page 17] RFC 55 Prototypical Implementation of NCP June 1970
ニューカーク、他 [17ページ] NCP1970年6月のRFC55Prototypical実現
(9) RFNM-WAIT
(9)RFNM-待ち
If we are on the send side and a CLS command arrives, we
cannot issue an acknowledging CLS if we have not received the
RFNM for our last data message. We enter this state to await
the RFNM, and cease all further data transmission. When the
RFNM comes in, a CLS may then be issued, and the connection
will be closed.
オンである、側と到着するCLSが、命令するaを送ってください、と最後のデータメッセージのためにRFNMを受け取っていないなら、私たちは承認CLSを発行できません。 私たちは、RFNMを待って、すべての詳しいデータ送信をやめるためにこの状態に入ります。 RFNMが入ると、CLSは発行されるかもしれません、そして、接続は閉店するでしょう。
Newkirk, et al. [Page 18] RFC 55 Prototypical Implementation of NCP June 1970
ニューカーク、他 [18ページ] NCP1970年6月のRFC55Prototypical実現
______________
| | CLOSE
CONN/ | CLOSED |<---------------------------+
send RFC | (0) | LISTEN |
+----------------| |-----------------------+ |
| |______________| | |
| | ^ | |
| [E]RFC | | CLS/send CLS | |
| ___V____|____ ___V____|____
| non-matching | | | |
| CONN/send RFC | PENDING | LISTEN RFC | LISTENING |
| +-------------| (1) |----------+ +----| (2) |
| | |_____________| | | |_____________|
| | matching | | |
___V___V_____ CONN/send RFC| __V___V______
| | | ACCEPT/ | | CLS/
| RFC-SENT | RFC | send RFC | RFC-RECD | send CLS
| (5) |----------+ | +----------| (3) |---------+
|_____________| | | | |_____________| |
| | | | | | |
| | ___V___V___V___ SND&CLOSE | ____________ |
| | RCV&CLS/ | |-----------)->| | |
| | send CLS | OPEN | SND&CLS | | DATA-WAIT | |
| | +---------| (6) |--------+ | | (8) | |
| | | |_______________| | | |____________| |
| | | RCV&CLOSE/ | | | | |
| | | send CLS | | | | |
| | | | | | | CLS |
| | | ______V______ | | | |
| | | CLOSE/ | |CLOSE/ | | | |
| | | send CLS| CLS-WAIT |send CLS | | | |
| +---)--------->| (8) |<--------)--+ | |
| | |_____________| | | |
| | | ___V______V_ ______V___
| | | | | | |
| | | | RFNM-WAIT | | ABORT |
| | CLS | | (9) | | (4) |
| | | |____________| |__________|
| | | | |
| | ______V_______ RFNM/ | |
| | | | send CLS | |
| CLS/ +--------->| CLOSED |<----------+ |
| send CLS | (0) | ACCEPT|CLOSE |
+----------------->| |<----------------------------+
|______________|
______________ | | コン/を閉じてください。| 閉じられます。| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+はRFCを送ります。| (0) | 聴いてください。| +----------------| |-----------------------+ | | |______________| | | | | ^ | | | [E] RFC| | CLS/はCLSを送ります。| | | ___V____|____ ___V____|____ | 非マッチング| | | | | コン/はRFCを送ります。| 未定| RFCを聴いてください。| 聴きます。| | +-------------| (1) |----------+ +----| (2) | | | |_____________| | | |_____________| | | マッチング| | | ___V___V_____ コン/はRFCを送ります。| __V___V______ | | | /を受け入れてください。| | CLS/| RFCによって送られます。| RFC| RFCを送ってください。| RFC-RECD| CLSを送ってください。| (5) |----------+ | +----------| (3) |---------+ |_____________| | | | |_____________| | | | | | | | | | | ___V___V___V___ SNDと閉鎖| ____________ | | | RCV&CLS/| |-----------)->|、|、|、|、| CLSを送ってください。| 戸外| SND&CLS| | データ待ち| | | | +---------| (6) |--------+ | | (8) | | | | | |_______________| | | |____________| | | | | RCVと閉鎖/| | | | | | | | CLSを送ってください。| | | | | | | | | | | | CLS| | | | ______V______ | | | | | | | 閉鎖/| |閉鎖/| | | | | | | CLSを送ってください。| CLS-待ち|CLSを送ってください。| | | | | +---)--------->| (8) | <、-、-、-、-、-、-、--)--+ | | | | |_____________| | | | | | | ___V______V_______V___ | | | | | | | | | | | RFNM-待ち| | アボート| | | CLS| | (9) | | (4) | | | | |____________| |__________| | | | | | | | ______V_______ RFNM/| | | | | | CLSを送ってください。| | | CLS/+--------->| 閉じられます。| <、-、-、-、-、-、-、-、-、--+ | | CLSを送ってください。| (0) | 受け入れてください。|閉鎖| +----------------->| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ |______________|
Figure 7.1
Connection State Diagram
図7.1 接続州のダイヤグラム
Newkirk, et al. [Page 19] RFC 55 Prototypical Implementation of NCP June 1970
ニューカーク、他 [19ページ] NCP1970年6月のRFC55Prototypical実現
VIII. Algorithms for the Input Interpreter
VIII。 入力インタプリタのためのアルゴリズム
The following is a concise description of the NCP's responses to incoming network commands. CS always indicates Connection State. Note, CLOSE is a system call executed by the local user process, and CLS is a network command.
↓これは入って来るネットワークコマンドへのNCPの応答の簡潔な説明です。 CSはいつもConnection州を示します。 注意、CLOSEはローカルのユーザ・プロセスで実行されたシステムコールです、そして、CLSはネットワークコマンドです。
NOP
NOP
Discard.
捨ててください。
RFC (RTS or STR)
RFC(RTSかSTR)
If no entry exists, create one with status = PENDING CALL, and
queue the message.
エントリーが全く存在しないなら、状態=PENDING CALLと共に1つを作成してください、そして、メッセージを列に並ばせてください。
If CS = LISTENING, then queue the entry, enter the RFC-RCVD state,
and inform the user of the request.
CSがLISTENINGと等しいなら、エントリーを列に並ばせてください、そして、RFC-RCVD状態に入ってください、そして、要求についてユーザに知らせてください。
If CS = RFC-SENT but the new RFC does not match the request,
refuse the RFC.
CSがRFC-SENTと等しいのですが、新しいRFCが要求に合っていないなら、RFCを拒否してください。
In all other cases, check the RFC for a match. If none exists,
queue the RFC. If the RFC matches, then if:
他のすべての場合では、マッチがないかどうかRFCをチェックしてください。 なにも存在しないなら、RFCを列に並ばせてください。 次に、RFCが合っている、:
CS = RFC-SENT, we enter the OPEN state.
CSはRFC-SENTと等しく、私たちはオープン状態に入ります。
CS = CLOSE-WAIT, the RFC is ignored.
CSはCLOSE-WAITと等しく、RFCは無視されます。
otherwise, the request is illegal in all states which indicate
it has already been received (these states are 1,3,4,6,8,9).
さもなければ、要求はそれが既に受け取られたのを(これらの州は1、3、4、6、8、9です)示すすべての州で不法です。
In any case, if processing the RFC causes an overflow condition
(resources are exhausted), refuse the connection (send a CLS).
どのような場合でも、RFCを処理するとオーバーフロー条件が引き起こされるなら(リソースは疲れ果てています)、接続を拒否してください(CLSを送ってください)。
CLS
CLS
The pending call queue is searched. If the CLS doesn't match the
current request, but does match some other request, then delete
that request and issue a CLS. If there is no match, the CLS is
ignored.
未定の呼び出し待ち行列は捜されます。 CLSが現在の要求に合っていませんが、ある他の要求に合っているなら、その要求を削除してください、そして、CLSを発行してください。 マッチが全くなければ、CLSは無視されます。
If the CLS matches the current request, and CS =
CLSが現在の要求、およびCS=に合っているなら
PENDING, then delete the current request. If the request queue
is empty, delete the entry; otherwise, leave the entry
alone.
PENDING、そして、現在の要求を削除してください。 要求待ち行列が空であるなら、エントリーを削除してください。 さもなければ、エントリーを放っておいてください。
Newkirk, et al. [Page 20] RFC 55 Prototypical Implementation of NCP June 1970
ニューカーク、他 [20ページ] NCP1970年6月のRFC55Prototypical実現
RFC-RCVD, Issue a CLS and enter the ABORT state.
ABORT, ignore.
そして、RFC-RCVD、Issue a CLS、ABORT状態に入ってください。 ABORT、無視します。
RFC-SENT, issue a CLS. If the pending call queue is empty
delete the entry, else enter the PENDING state.
RFC-SENT、CLSを発行してください。 未定の呼び出し待ち行列が空であるなら、エントリーを削除してください、そして、ほかに、入ってください。PENDING状態。
OPEN, If we are on the receive side, response is identical to
the response for RFC-SENT. If we are on the send side,
clear the data queue, and if a RFNM is still pending enter
the RFNM-WAIT state. Otherwise response is identical to the
response for RFC-SENT.
オープン、If、私たちがオンである、側を受け取ってください、そして、RFC-SENTに、応答は応答と同じです。 私たちがオンである、側を送ってください、データが列を作るのが明確であり、RFNMがまだ未定であるなら、RFNM-WAIT状態に入ってください。 さもなければ、RFC-SENTに、応答は応答と同じです。
CLS-WAIT, Issue a CLS and if the pending call queue is empty,
delete the entry, otherwise CS = PENDING.
CLS-WAIT、Issue a CLSと未定の呼び出し待ち行列は空になってください、エントリーを削除してください、さもなければ、CSがPENDINGと等しいということであるかどうか。
DATA-WAIT, clear the data queue and enter the RFNM-WAIT state.
A matching CLS cannot occur in the CLOSED or LISTENING
states.
DATA-WAIT、データ待ち行列をクリアしてください、そして、RFNM-WAIT状態に入れてください。 合っているCLSはCLOSEDかLISTENING州に起こることができません。
ERR
間違えてください。
Errors are queued for later attention by system programmers, and
are considered to be a system error in the host that originated
the exchange. (Not associated with any state).
誤りは、後の注意のためにシステム・プログラマによって列に並ばせられて、交換を溯源したホストのシステム・エラーであると考えられます。 (どんな状態にはも、交際しません。)
ECO
エコ
The op code is changed to ERP and retransmitted (Not associated
with any state).
オペコードは、ERPに変えられて、再送されます(どんな状態にはも、交際しません)。
ERP
ERP
Upon receipt of an ERP, the system passes the text of the command
back to the process which issued the ECO.
ERPを受け取り次第、システムはECOを発行した過程にコマンドのテキストを戻します。
INR, INS
INR、インス
These commands are enabled only in the OPEN state. Upon receiving
an INTERRUPT, the system causes an event to be sent to the
associated process. An INTERRUPT is ignored in the CLS-WAIT,
DATA-WAIT, and RFNM-WAIT states. In any other state it is an
error.
これらのコマンドはオープン状態だけで可能にされます。 INTERRUPTを受けると、システムで、関連過程に出来事を送ります。 INTERRUPTはCLS-WAIT、DATA-WAIT、およびRFNM-WAIT州で無視されます。 いかなる他の状態ではも、それは誤りです。
Newkirk, et al. [Page 21] RFC 55 Prototypical Implementation of NCP June 1970
ニューカーク、他 [21ページ] NCP1970年6月のRFC55Prototypical実現
ALL
すべて
ALLOCATE is valid only in the OPEN state, and may be sent only to
a send socket. The NCP increments the 'Their Size' field in the
associated rendezvous table entry by the size specified in the
ALLOCATE command.
ALLOCATEはオープン状態だけで有効です、そして、aだけに送るかもしれません。ソケットを送ってください。 ALLOCATEコマンドで指定されたサイズに従って、NCPは関連ランデブーテーブルエントリーで'それらのSize'分野を増加します。
In the CLS-WAIT and DATA-WAIT states this command is ignored; in
any other state it is an error.
CLS-WAITとDATA-WAIT州では、このコマンドが無視されます。 いかなる他の状態ではも、それは誤りです。
Data-RFNM
データ-RFNM
If in the OPEN state, mark the Flow Control Status field in the
appropriate rendezvous table entry as RFNM-RECVD, and send more
data if required.
オープン状態でRFNM-RECVDとして適切なランデブーテーブルエントリーにFlow Control Status分野を示してください、そして、必要なら、より多くのデータを送ってください。
If in the DATA-WAIT state, maintenance the Flow Control Status.
If the data queue is empty issue a CLS and enter the CLS-WAIT
state; otherwise, transmit the next message.
DATA-WAIT状態、維持におけるFlow Control Statusであるなら。 データ待ち行列が空であるなら、CLSを発行してください、そして、CLS-WAIT状態に入れてください。 さもなければ、次のメッセージを送ってください。
If in the RFNM-WAIT state, maintenance the Flow Control Status and
issue a CLS. If the Pending Call queue is empty delete the
rendezvous table entry, otherwise CS = PENDING.
維持のRFNM-WAIT状態、Flow Control Status、および問題a CLSで。 Pending Call待ち行列が空であるなら、ランデブーテーブルエントリーを削除してください。さもなければ、CSはPENDINGと等しいです。
A Data-RFNM is an error in all other states.
Data-RFNMは他のすべての州の誤りです。
IX. Algorithms for the System Call Interpreter
IX。 システムコールインタプリタのためのアルゴリズム
Each System Call is discussed, giving the state changes it may effect:
それが作用するかもしれない州の変化を与えて、各System Callについて議論します:
CONNECT
接続してください。
If there is no entry, create one, issue an RFC, and enter the
RFC-SENT state.
エントリーが全くなければ、1つを作成してください、そして、RFCを発行してください、そして、RFC-SENT状態に入れてください。
If CS = PENDING, search the queue and reject all non-matching
requests. If no match is found issue an RFC and enter the
RFC-SENT state. If a match is found, issue an RFC and enter
the OPEN state. Transmission can commence as soon as buffer
space has been allocated.
CSがPENDINGと等しいなら、待ち行列を捜してください、そして、すべての非合っている要求を拒絶してください。 マッチが全く見つけられないなら、RFCを発行してください、そして、RFC-SENT状態に入れてください。 マッチが見つけられるなら、RFCを発行してください、そして、オープン状態に入れてください。 バッファ領域を割り当てるとすぐに、トランスミッションは始まることができます。
In any other state this command is illegal.
いかなる他の状態ではも、このコマンドは不法です。
LISTEN
聴いてください。
If an entry doesn't exist, create one, and enter the LISTENING
state.
エントリーが存在しないなら、1つを作成してください、そして、LISTENING状態に入れてください。
Newkirk, et al. [Page 22] RFC 55 Prototypical Implementation of NCP June 1970
ニューカーク、他 [22ページ] NCP1970年6月のRFC55Prototypical実現
If CS = PENDING, inform the user and enter the RFC-RCVD state.
CSがPENDINGと等しいなら、ユーザに知らせてください、そして、RFC-RCVD状態に入ってください。
In any other state this command is illegal.
いかなる他の状態ではも、このコマンドは不法です。
ACCEPT
受け入れてください。
If CS = RFC-RCVD, then issue an RFC and enter the OPEN state.
Data transmission can occur as soon as buffer space is
allocated.
CSがRFC-RCVDと等しいなら、RFCを発行してください、そして、オープン状態に入れてください。 バッファ領域を割り当てるとすぐに、データ伝送は起こることができます。
If CS = ABORT, inform the user of the premature termination of the
connection. If the pending call queue is empty, delete the
entry; otherwise, enter the PENDING state.
CSがABORTと等しいなら、接続の未完熟終了についてユーザに知らせてください。 未定の呼び出し待ち行列が空であるなら、エントリーを削除してください。 さもなければ、PENDING状態に入ってください。
This command cannot be legally executed in any other state.
いかなる他の状態でもこのコマンドを法的に実行できません。
CLOSE
閉鎖
If CS =
Cs=です。
LISTENING, then delete the entry.
LISTENING、そして、エントリーを削除してください。
RFC-RCVD, then issue a CLS and enter the CLS-WAIT state.
RFC-RCVD、次に、CLSを発行してください、そして、CLS-WAIT状態に入れてください。
ABORT, inform the user of the premature termination of the
connection. If the pending call queue is empty, delete the
entry; otherwise, enter the PENDING state.
ABORT、接続の未完熟終了についてユーザに知らせてください。 未定の呼び出し待ち行列が空であるなら、エントリーを削除してください。 さもなければ、PENDING状態に入ってください。
RFC-SENT, then issue a CLS and enter the CLS-WAIT state.
RFC-SENT、次に、CLSを発行してください、そして、CLS-WAIT状態に入れてください。
OPEN, if we are on the send side, and the data queue is not empty,
or if a Data-RFNM is still outstanding, enter the DATA-WAIT
state; otherwise, issue a CLS and enter the CLS-WAIT state.
私たちがオンのオープン、側を送ってください、そして、データ待ち行列が空でないか、またはa Data-RFNMがまだ傑出しているなら、DATA-WAIT状態に入れてください。 さもなければ、CLSを発行してください、そして、CLS-WAIT状態に入れてください。
CLS-WAIT, issuing a CLOSE in this state is a USER ERROR.
CLS-WAIT、この状態でCLOSEを発行するのは、USER ERRORです。
DATA-WAIT, issuing a CLOSE in this state is also an illegal
sequence.
DATA-WAIT、また、この状態でCLOSEを発行するのは、不法な系列です。
RFNM-WAIT, ignore the CLOSE.
RFNM-WAIT、CLOSEを無視してください。
A valid CLOSE cannot be issued if an entry does not exist, or if a
socket is in the PENDING state.
エントリーが存在していないか、またはソケットがPENDING州にあるなら、有効なCLOSEを発行できません。
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Anthony Anderberg 5/00 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][アンソニーAnderberg5/00によるオンラインRFCアーカイブへの]
Newkirk, et al. [Page 23]
ニューカーク、他 [23ページ]
一覧
スポンサーリンク
