RFC167 日本語訳

                         Network Working Group
                        Request for Comment #167
                               NIC #6784

コメント#167NIC#6784を求めるネットワークワーキンググループ要求

                    Socket Conventions Reconsidered

ソケットコンベンションは再考しました。

                          Athay Bhushan (MAC)
                         Bob Metcalfe (Harvard)
                            Joel Winett (LL)

Athay Bhushan(MAC)ボブメトカルフェ(ハーバード)ジョエルWinett(LL)

                              24 May 1971

1971年5月24日

                          Category: C1, C3, C8
                        Related RFCs: #147, #129
                    Related Functional Documents: #1

カテゴリ: C1、C3、C8はRFCsを関係づけました: #147 #129、は機能的なドキュメントについて話しました: #1

                                                                [Page 1]

RFC 167                                  Socket Conventions Reconsidered

[1ページ] RFC167ソケットコンベンションは再考しました。

The current NCP Protocol says nothing about how hosts should assign
socket numbers to process ports, except that the low-order bit is to
specify socket gender (i.e., send or receive). Two recent proposals call
for additional network-wide conventions on the 32-bit socket-number. The
first proposal asks that a portion of the socket number be reserved for
a network-unique user number for accounting and access control. The
second proposal asks that the high-order 16 bits of the socket number be
zero to assist smaller hosts in reducing the space required for socket
number tables.

ホストがポートを処理するためにどうソケット番号を割り当てるべきであるかに関して現在のNCPプロトコルは沈黙します、ソケット性を指定するのを除いて(すなわち、発信するか、または受信してください)下位のビットがことである。 2つの最近の提案が32ビットのソケット番号で追加ネットワーク全体のコンベンションを求めます。 最初の提案は、ソケット番号の部分が会計とアクセスコントロールのためのネットワークユニークユーザー数のために予約されるように頼みます。 2番目の提案は、ソケット数のテーブルに必要であるスペースを減少させるのにより小さいホストを助けるためにソケット番号の高位16ビットがゼロであると尋ねます。

It is recommended that both of these proposals be set aside.  Because a
large perturbation of the current NCP Protocol is required to provide
adequate handles for accounting and access control, and because the
socket number is already underpowered for its use, it is recommended
that both proposals be set aside until serious consideration can be
given to a major NCP Protocol overhaul.

これらの提案の両方がかたわらに置かれるのは、お勧めです。 現在のNCPプロトコルの大きい摂動が会計のための適切なハンドルとアクセスコントロールを提供するのに必要であり、使用において、ソケット番号が既にパワー不足であるので、両方の提案が主要なNCPプロトコルオーバーホールに真剣な考慮を与えることができるまでかたわらに置かれるのは、お勧めです。

DISCUSSION

議論

The socket number, as it is used in the current NCP Protocol is a small
number with a big function. It will probably be found that a
substantially more powerful identification mechanism (e.g., a
hierarchical naming scheme with arbitrarily long names) is required to
satisfactorily manipulate process ports. Two features of such a
mechanism will be (1) that it treats accounting and access control with
the respect they deserve, and (2) that it is part of a simpler NCP
Protocol more easily implemented under the existing size and complexity
restrictions of smaller hosts.

大きい機能に従って現在のNCPプロトコルに使用されているのが、少ない数であるということであるのでソケット番号。 実質的により強力な識別メカニズム(例えば、任意に長い名前がある階層的な命名体系)が満足にプロセスポートを操作するのに必要であることがたぶん見つけられるでしょう。 そのようなメカニズムの2つの特徴は(2) (1) それらが値する敬意をもって会計とアクセスコントロールを扱って、既存のサイズの下で、より容易に実装されたより簡単なNCPプロトコルの一部と、より小さいホストの複雑さ制限であるということでしょう。

Socket numbers are process port identifiers used in establishing
connections between processes. It is essential that they be UNIQUE to
avoid ambiguity during connection. It is important that their assignment
to specific processes be REPEATABLE for reconnection on a regular basis.

ソケット番号はプロセスの間に関係を樹立する際に使用されるプロセスポート識別子です。 接続の間、あいまいさを避けるのはそれらがUNIQUEであることが不可欠です。 特定のプロセスへの彼らの課題が定期的に再接続のためのREPEATABLEであることは重要です。

To assure that process port identifiers are unique and repeatable it is
necessary to subject their allocation to access controls.  The simplest
of access controls assuring uniqueness is that provided by NCPs which
check their tables of active connections for duplication when a process
requests the use of a specific socket number.

プロセスポート識別子がユニークであることを保証して、反復可能するように、アクセスする彼らの配分が制御されるのが対象に必要です。 プロセスであるときに、どれがそれらの複製のための活発な接続のテーブルをチェックするかがNCPから特定のソケット番号の使用を要求するなら、アクセス制御がユニークさを保証するのにおいて最も簡単であるのは、それです。

There is real difficulty in constructing schemes for allowing socket
number assignments to be repeatable. Some socket numbers are to be
universally known and associated with processes operating with specified
protocols (e.g., a logger socket, an RJB socket, a file transfer
socket). Other socket numbers might not be universally known, but given
to their users in a transmission over a universally known socket (e.g.,
the socket pair specified by the transmission over the logger socket
using the Initial Connection Protocol (ICP)).  Concurrently running

ソケット数の課題が反復可能であることを許容することの体系を構成することにおける本当の苦労があります。 いくつかのソケット番号は、指定されたプロトコル(例えば、きこりのソケット、RJBソケット、ファイル転送ソケット)で作動するプロセスに一般に知られていて関連していることです。 しかし、他のソケット番号は一般に一般に知られているソケットの上のトランスミッションで彼らのユーザに与えた状態で知られていないかもしれません(例えば、ソケット組はInitial Connectionプロトコルを使用しながら、きこりのソケットの上のトランスミッションで指定しました(ICP))。 同時に、稼働しています。

                                                                [Page 2]

RFC 167                                  Socket Conventions Reconsidered

[2ページ] RFC167ソケットコンベンションは再考しました。

instances of a program will require distinct process port identifiers.
Therefore, socket numbers will in general need to be dynamically
assigned via some system controlled allocation function.

プログラムのインスタンスは特異的な過程ポート識別子を必要とするでしょう。 したがって、一般に、ソケット番号は、何らかのシステムの制御配分機能でダイナミックに割り当てられる必要があるでしょう。

There are a number of ways of providing for potentially repeatable
socket number assignments. One bad way is to have the NCP keep a list of
all assigned socket numbers with some indication of who is permitted to
use them and for how long -- like keeping track of magnetic tape reels.
If there were few available socket numbers (e.g., 16 bits worth) this
bad method or one comparably distasteful and logistically foreboding
would have to be adopted.  With an abundance of socket numbers it is
possible, using sparse socket number assignment, to devise simple
algorithms for deciding whether a socket numbers being requested by a
process can be allocated freely. Such algorithms might take into account
(1) the dynamic status of the socket (i.e., its association with a
currently active connection), (2) its reserved status as a standard
service port address, and (3) its access control attributes in relation
to those of the requesting process.

潜在的に反復可能ソケット数の課題に備える多くの方法があります。 1つの悪い方法は、磁気テープリールの動向をおさえるようにNCPが、だれがそれらを使用することが許可されているかいくつかのしるしを伴うソケット番号をすべてのリストに割り当て続けるのを持って、どれくらい長い間ことであるか。 そして、有効なソケット番号がわずかしかなかった、(例えば、16ビット、価値) この悪いメソッドか1つのメソッド、比較できるほどに不快である、ロジスティックに、不吉な予感は採用されなければならないでしょう。 ソケット番号の豊富では、それは可能です、ソケットが要求されていた状態で存在に付番するか否かに関係なく、自由にプロセスを割り当てることができると決めるための簡単なアルゴリズムを工夫するのにまばらなソケット数の課題を使用して。 そのようなアルゴリズムは(1) ソケット(すなわち、現在活発な接続との仲間)のダイナミックな状態、(2) 標準のサービスポートアドレスとしての予約された状態、および(3) 要求プロセスのものと関連したそのアクセス制御属性を考慮に入れるかもしれません。

One good strategy for controlling socket numbers is to partition the
full socket space at a host among its network users. Under this scheme a
user could be assured of having the repeatable use of his partition.  It
might also be helpful to designate a utility partition for use in socket
number allocations where repeatability is not essential. Such socket
numbers could be selected from the utility partition by some clever
construction on the date and time.

ソケット番号を制御するための1つの優れた戦略はネットワーク利用者の中でホストで完全なソケットスペースを仕切ることです。 この体系の下では、ユーザは彼のパーティションの反復可能使用を持つのについて確信できました。 また、再現可能性が不可欠でないところでソケット数の配分における使用のためのユーティリティパーティションを指定するのも役立っているかもしれません。 そのようなソケット番号は、ユーティリティパーティションから日付の何らかの賢明な工事で選択されて、調節されることができました。

It will often be the case that a program will be written to use several
connections. Remembering that this program might find itself being
executed concurrently by several processes belonging to several users,
it might be convenient to code with socket tags which are to be extended
with runtime user and process identifier fields.

しばしばプログラムがいくつかの接続を使用するために書かれるのは、事実でしょう。 このプログラムが当たるかもしれないのを覚えているのが同時に数人のユーザのものであるいくつかのプロセスによって実行される場合、それは、ランタイムユーザとプロセス識別子分野で広げられることになっているソケットタグでコード化するのに便利であるかもしれません。

Socket numbers will tend to be viewed -- should be viewed -- as having
three fields: a user field to assist in providing repeatability, a
process field to assure uniqueness for concurrent instances of a
program, and a tag field to enable the convenient referencing of
multiple connections to a single process.

ソケット番号は、見られる傾向があるでしょう--3を持っていると以下がさばかれるとき、見られるべきです。 再現可能性(複数の接続の便利な参照箇所を単一のプロセスに可能にするために同時発生のインスタンスのためのユニークさにプログラム、およびタグ・フィールドを保証するプロセス分野)を提供する助けるユーザ分野。

Although fields will be helpful in dealing with socket number
allocation, it is not essential that such field designations be uniform
over the network. In all network transactions the 32-bit socket number
is handled with its 8-bit host number. Thus, if hosts are able to
maintain uniqueness and repeatability internally, socket numbers in the
network as a whole will also be unique and repeatable.  If a host fails
to do so, only connections with that offending host are affected.

分野はソケット数の配分に対処する際に役立つでしょうが、そのような分野名称がネットワークの上で一定であることは、不可欠ではありません。 すべてのネットワークトランザクションでは、32ビットのソケット番号は8ビットのホスト番号で扱われます。 したがって、ホストが内部的にユニークさと再現可能性を維持できるなら、全体の意志としてのネットワークにおけるソケット番号は、また、ユニークであり、反復可能されます。 ホストがそうしないなら、その怒っているホストとの接続だけが影響を受けます。

                                                                [Page 3]

RFC 167                                  Socket Conventions Reconsidered

[3ページ] RFC167ソケットコンベンションは再考しました。

Because the size, use, and character of systems on the network are so
varied, it would be difficult if not impossible to come up with an
agreed upon particular division of the 32-bit socket number.  Hosts have
different internal restrictions on the number of users, processes per
user, and connections per process they will permit.

ネットワークのシステムのサイズ、使用、およびキャラクタが非常に変えられるので、思いつくのが難しいか、または不可能であるだろう、32ビットのソケット番号の特定の区画に同意しました。 ホストはユーザの数、1ユーザあたりのプロセス、および1彼らが可能にするプロセスあたりの接続に異なった内部の制限を持っています。

It has been suggested that it may not be necessary to maintain socket
uniqueness. It is contended that there is really no significant use made
of the socket number after a connection has been established. The only
reason a host must now save a socket number for the life of a connection
is to include it in the CLOSE of that connection. If such is really the
case, then the NCP Protocol might be improved by inventing a new CLOSE
which uses the host-line pair associated with the connection. Hosts
which are short on space could then forget a socket number immediately
after successful connection.

ソケットのユニークさを維持するのは必要でないかもしれないと示唆されました。 接続が確立された後にソケット番号でされたどんな重要な使用も本当にないと主張されます。 ホストが現在接続の寿命のソケット番号を保存しなければならない唯一の理由はその接続のCLOSEにそれを含むことです。 そのようなものが本当にケースであるなら、NCPプロトコルは、接続に関連しているホスト一対の条線を使用する新しいCLOSEを発明することによって、改良されるかもしれません。 そして、スペースに不足したホストはうまくいっている接続直後ソケット番号を忘れることができました。

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

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

                                                                [Page 4]

[4ページ]