RFC163 日本語訳

Network Working Group                            V. Cerf
Request for Comments #163                        19 May 71
NIC #6775                                        UCLA - NMC
Categories:  D.7                                 Computer Science
Updates:  None
Obsoletes:  None

コメント#163 1971年5月19日のNIC#6775UCLAを求めるネットワークワーキンググループV.サーフの要求--NMCカテゴリ: D.7コンピュータサイエンスアップデート: なにも以下を時代遅れにしません。 なし

                        DATA TRANSFER PROTOCOLS

データ転送プロトコル

This is an informal statement of material discussed at the SJCC.  There
are two peoblems.

これはSJCCで議論した材料の非公式の声明です。 2peoblemsがあります。

   1.  Movement of data from one site to another.
   2.  Interpretation of the data at receiving site.

1. データの1つのサイトから別のサイトまでの動き。 2. サイトを受け取るところのデータの解釈。

The first task (1) requires a simple protocol which accomplishes the
following

最初のタスク(1)は以下を達成する簡単なプロトコルを必要とします。

   1)  Standard connection procedure for connecting
       transmitting and receiving processes

1) プロセスを送信して、受けながら接続するための標準の接続手順

   2)  Standard packaging which allows network to
       collect the transmitted data stream in the
       right order and know when the end of the
       file has been reached.

2) ネットワークを正しい注文における伝えられたデータ・ストリームを集めて、ファイルの端にいつ達したかを知る標準のパッケージ。

Standard Connection Procedure

標準の接続手順

Suppose every HOST has a process charged with the responsibility of
sending and receiving files between -HOSTS-(processes?)[The Data
Manager].  If the Data Manager offers to listen on a given socket for
file xmt requests, then ICP is sufficient to establish a connection
between a serving Data Manager and a using process.

あらゆるHOSTが送受信ファイルの責任を-HOSTS(プロセス?)[Dataマネージャ]の間にプロセスを課させると仮定してください。 Dataマネージャが、ファイルxmt要求のための与えられたソケットの上に聴くと申し出るなら、ICPは、給仕のDataマネージャと使用プロセスの間に取引関係を築くために十分です。

We have completely avoided the discussion of data interpretation, and
also the problem of control.  For instance, we have not said how a
process can ask the Data Manager to send a file of a par- ticular name,
nor how to end the transmission of a file.  This is deferred for later.

私たちは、完全にデータ解釈の議論を避けて、また、コントロールの問題を避けました。 例えば、私たちはプロセスが、平価ticular名のファイルを送るようにどうしたらDataマネージャに頼むことができるか、そして、ファイルの伝達をどのように終わらせるかを言っていません。 これは後で延期されます。

Another desirable ability is to have processes transmit files to each
other independent of the HOST Data Manager.  ICP should suffice, for the
creation of a full duplex connection.  File naming, and format
interpretation are left to the individual process to solve.

別の望ましい能力はプロセスにHOST Dataマネージャの如何にかかわらずファイルを互いに送らせることです。 ICPは全二重接続の作成に十分であるはずです。 解決する命名、および形式解釈が個々のプロセスに残されるファイル。

It is of interest to note that files need not have names.  If two
processes are connected, then the file name is in a sense implicit in
the sending and receiving socket pair.  One imagines, however, that

ファイルには名前がある必要はないことに注意するのが興味があります。 2つのプロセスが接続されているなら、ファイル名はある意味で送受信ソケット組で暗黙です。 しかしながら、人はそれを想像します。

                                                                [Page 1]

connections with Data Managers for the purpose of file transmission are
too transient to serve as permanent file names, so information about
file name will be needed by the Data Manager.  This information could be
supplied either embedded in the file transmission data stream, or
supplied over a separate control connection established at ICP time.

[1ページ] ファイルトランスミッションの目的のためのDataマネージャとの接続が保存用ファイル名として機能できないくらい一時的であるので、ファイル名の情報はDataマネージャによって必要とされるでしょう。 この情報をファイルトランスミッションデータ・ストリームに埋め込まれていた状態で提供したか、またはICP時に確立された別々のコントロール接続の上に提供できました。

It seems reasonable that a Data Manager have a network-wide, fixed
socket number on which it is listening to service data transmission
requests.* In this sense, it acts much like the Network Logger.  For
inter-process file transmission, less rigidity seems called for, and we
can leave such decisions to the individual peocesses communicating with
each other.  Public processes at serving HOSTS could have known (nia
NIC?) sockets over which file transmission is acceptable.

Dataマネージャにはそれがサービスデータ送受信要求を聞いているネットワーク全体の、そして、固定されたソケット番号があるのは妥当に思えます。*この意味で、それはNetwork Loggerのように行動します。 相互プロセスファイルトランスミッションに関しては、より少ない剛性が求められるように思えます、そして、私たちは互いにコミュニケートする個々のpeocessesにそのような決定を任せることができます。 公衆はHOSTSが(nia NIC?)ソケットを知ったかもしれないそれのファイルトランスミッションが許容できる給仕で処理します。

Standard Packaging

標準のパッケージ

We naively imagine that very little in the way of formatting is needed
to move data across the connection.  A few bits (8?) at the beginning of
transmission could specify the formatting protocol (e.g. arbitrary bit
string until connection closed, count field + data, break chars, etc.)
Depending on the selected format mode, the appropriate control bits will
or will not appear interspersed betweeen the data bits.  Message
boundaries are totally transparent.

私たちは、接続の向こう側にデータを動かすのに形式の方法でほとんど必要でないと純真に想像します。 トランスミッションの始めにおける数ビット(8?)が形式プロトコル(例えば、任意の閉店した接続、カウント分野+データ、中断雑用などまでのビット列)を指定するかもしれません。 選択された形式モードによって、適切なコントロールビットがよるだろうか、または点在しているbetweeenに見えないでしょう。データ・ビット。 メッセージ限界は完全に透明です。

A way of ending the file, possibly without closing the connection, is
useful, although closing the connection after the RFNM from final
"record" sent is received by the sending process might be adequate
(sufficient, but not palatable?)

ことによると接続を終えないでファイルを終わらせる方法は役に立ちます、送付プロセスで送られた最終的な「記録」からのRFNMを受け取った後に接続を終えるのは適切であるかもしれませんが(十分な、しかし、おいしくない)?

----
*ICP causes sockets to be dynamically assigned for the ensuing
conversation (which might be all 1-way).

---- *ICPは続くことの会話(すべて1ウェイであるかもしれない)のためにソケットをダイナミックに割り当てさせます。

                                                                [Page 2]

Control

[2ページ] コントロール

A great many problems come up if the Data Manager serves as a part of
the HOST filling system.  For example, the Data Manager must know
whether the process it is serving wants to send a file or receive one.
In either case, some sort of file name + qualifiers (user ID, security
codes, access requested, etc.) will be needed to resolve the usual
access legality, and potential file name ambiguities.  This information
can be supplied either within a single full duplex data stream (1 per
ICP request) established by a modified ICP for data transmission.  The
former seems simplier, sufficient, and immediately implementable.

DataマネージャがHOSTの腹を満たすシステムの一部として勤めるなら、多くの問題が来ます。 例えば、Dataマネージャは、それが役立っているプロセスがファイルを送りたいか、または1を受け取りたがっているかどうかを知らなければなりません。 どちらの場合ではも、ある種のファイル名+資格を与える人(ユーザID、セキュリティコード、要求されたアクセスなど)が、普通のアクセス合法、および潜在的ファイル名のあいまいさを取り除くのに必要でしょう。 データ伝送のために変更されたICPによって確立されたただ一つの全二重データ・ストリーム(ICP要求あたり1)の中でこの情報を提供できます。 前者は十分で、すぐに実装可能なsimplierに見えます。

Data transmission between arbitrary processes probably does not need as
much formal control protocol as process-to/from-DM (data Manager)
connection.  Ad hoc procedures can be established by trading information
on previously established connections; regularity is nice, so perhaps a
standard set of control protocols can be devised which work, regardless
of the identity of the processes transmitting data.  Control data must
be formatted and probably identifiable by prefix codes so that
unnecessary control information can be left out if desired.  (I am
thinking specifically of file names.)

任意のプロセスの間のデータ伝送がたぶん同じくらい多くの正式な制御プロトコルを必要としない、プロセス、-、/、DMからの(データマネージャ)接続。 以前に確立した接続の取り引き情報は臨時の手順を確立できます。 規則性が良いので、恐らく働いている標準の制御プロトコルについて工夫できます、データを送るプロセスのアイデンティティにかかわらず。 制御データは、望まれているなら不要な制御情報を省くことができるくらいフォーマットされていてたぶん接頭語コードで身元保証可能でなければなりません。 (私は特にファイル名を考えています。)

It remains to establish a set of format protocols which permit packaging
of data and identification of control information.  This should be the
task of the renamed Data Transmission Committee.

データのパッケージと制御情報の識別を可能にする1セットの形式プロトコルを確立するのは残っています。 これは改名されたData Transmission Committeeに関するタスクであるべきです。

       [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by Simone Demmel 5/97 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][シモンDemmel5/97によるオンラインRFCアーカイブへの]

                                                                [Page 3]

[3ページ]