RFC129 日本語訳

Network Working Group                         22 April 1971
Request for Comments:  129               E. E. Harslem-Rand
NIC 5845                                 J. F. Heafner-Rand
                                         E.    Meyer-MIT

コメントを求めるワーキンググループ1971年4月22日の要求をネットワークでつないでください: 129 E.E.Harslem-底ならし革NIC5845J.F.Heafner-底ならし革E.マイヤー-MIT

                       A REQUEST FOR COMMENTS ON
                         SOCKET NAME STRUCTURE

ソケット名構造のコメントを求める要求

INTRODUCTION

序論

     This RFC is in answer to a request (made at the
February NWG Meeting at the University of Illinois) that
we comment on several suggested socket name structures.
We apologize for the delay in getting out these comments
and we hope that you will respond more quickly with your
reactions.
     Please direct your replies via the standard RFC
mechanism.
     Two structures are presented in this RFC as shown
below.

このRFCは私たちがいくつかの提案されたソケット名構造を批評するという要求(2月のNWG Meetingでは、イリノイ大学で作られている)に答えています。 私たちはこれらのコメントを出す遅れを謝ります、そして、あなたが、よりすばやくあなたの反応をもって応じることを願っています。 標準のRFCメカニズムで回答を指示してください。 2つの構造がこのRFCに以下に示すように提示されます。

                        31                 1
          +-------------------------------+-+
     1.   |         Arbitrary             | | <-- gender
          +-------------------------------+-+

31 1 +-------------------------------+-+ 1. | 任意| | <-- 性+-------------------------------+-+

                        24             7   1
          +------------------------+------+-+
     2.   |        User ID         | tag  | | <-- gender
          +------------------------+------+-+

24 7 1 +------------------------+------+-+ 2. | ユーザID| タグ| | <-- 性+------------------------+------+-+

     Three variations are given for the way in which
socket names are assigned, as examples of use of the
first structure.
     1.   Users pick the arbitrary number arbitrarily
          and associate it with a process.
     2.   A logger chooses the arbitrary number dynamically
          and associates it with a process via a directory.
     3.   The arbitrary number is assigned outside of a
          logger but may be issued by a logger to the
          remote party.

ソケット名が割り当てられる方法のために3回の変化を与えます、最初の構造で役に立つ例として。 1. ユーザは、任意に特殊活字の数字を選んで、それをプロセスに関連づけます。 2. きこりは、ダイナミックに特殊活字の数字を選んで、ディレクトリでそれをプロセスに関連づけます。 3. 特殊活字の数字は、きこりの外に割り当てられますが、きこりによってリモートパーティーに発行されるかもしれません。

                                                                [Page 1]

The second format shown above associates sockets specifi-
cally with users as opposed to processes.
     The following discussion covers three different schemes
of socket identifier assignment using a simple example.
User A at Host A has agreed (by letter, telephone, etc.)
with User B at Host B for their respective processes to
establish a connection through the Network at a particular
time.  User B is to be waiting for the connection attempt
initiated by User A.  The issues to be faced are those of
addressing (how is User A to know to which socket to connect?),
and of security (how are both users to be confident that
they are talking each other, and not some interloper?).
     A fourth scheme follows which addresses another concept
of Network use--that connections are made between processes
and that processes not users should be identified via
Socket names.

[1ページ] 目立つ2番目の書式はプロセスと対照的にソケットspecifi警察署をユーザに関連づけます。 以下の議論は、簡単な例を使用することでソケット識別子課題の3つの異なった体系をカバーしています。 Host AのユーザAは、それらのそれぞれのプロセスが特定の時にNetworkを通して取引関係を築くとHost BのUser Bに同意しました(手紙、電話などで)。 ユーザBはUser A.によって開始された接続試みを待つことになっています。面するべき問題はアドレシング(User Aは、接続するのをどのようにどのソケットに知ることになっていますか?)、およびセキュリティ(両方のユーザは、彼らが侵入者ではなく、互いについて話しているとどのように確信していることになっていますか?)のものです。 4番目の体系は続きます(接続がプロセスの間で作られていて、ユーザではなく、プロセスがSocket名で特定されるべきであるというNetwork使用の別の概念を扱います)。

FREELY SELECTED RANDOM SOCKET IDENTIFIERS (Scheme 1)

自由に選択された無作為のソケット識別子(体系1)

     Under this scheme a user is able to use any 32-bit
socket identifier he chooses.  Two restrictions apply:  the
least significant bit denotes the socket's gender (0-read,
1-write), and no more than one socket bearing a given iden-
tifier can be active at a host at a time.
     The two users select suitably random identifiers ("a"
and "b").  User A will attempt to activate his socket with
identifier "a" an connect it to socket "b" at Host B.  There
is the possibility that somebody other than User B has
activated socket "b" at Host B so that User A will address
the wrong  party.  However, the possibility that some other
user has accidentally picked this particular identifier is
reasonably small, since there are about a billion different
identifiers.  When the connection request from A gets to
User B, he examines the identifier of the calling socket.
If for some reasom it is not "a" or not from Host A, he
rejects the request, because it is likely to be from some

この体系の下では、ユーザは選ぶどんな32ビットのソケット識別子も使用できます。 2つの制限が適用されます: 最下位ビットがソケットの性を指示する、(0によって読まれる、1、-書いてください、)、与えられたiden- tifierを持っている1個のソケットが一度にホストでアクティブである場合があるほど多くではありません。 2人のユーザが適当に無作為の識別子(“a"と「b」)を選択します。 Host B.でソケット「b」にそれを接続してください。ユーザAが、識別子“a"で彼のソケットを動かすのを試みる、ThereはUser Aが間違ったパーティーに演説するようにUser B以外のだれかがHost Bでソケット「b」を動かした可能性です。 しかしながら、ある他のユーザが偶然この特定の識別子を選んだ可能性は合理的に小さいです、およそ10億の異なった識別子があるので。 Aからの接続要求がUser Bを始めると、彼は呼ぶソケットに関する識別子を調べます。 それがいくらかのreasomに関する“a"でないなら、Host Aから、それがいくつかからありそうであるので、彼は要求を拒絶します。

                                                                [Page 2]

outside party.  If the calling socket is named, "a" and
from Host A, User B can be reasonably sure that it is from
User A.  It is very unlikely that some other party will
accidentally address socket "b" from a socket named "a".
     The advantages of this scheme are:  simplicity and
reasonable security in a non-malicious environment.  The
disadvantages are that there are possibilities from annoy-
ingly unavoidable conflicts with other users and that each
pair of users must conduct a prior confidential private
communication (as opposed to a broadcast announcement in
more secure schemes).

[2ページ] 外では、パーティーへ行ってください。 呼ぶソケットが“a"とHost Aから命名されるなら、User Bはある他のパーティーが“a"というソケットからソケット「b」を偶然扱うのによるUserから、A.Itが非常にありそうもないということであることを合理的に確信している場合があります。 この体系の利点は以下の通りです。 非悪意がある環境における簡単さと手頃なセキュリティ。 いらいらさせてください。損失が可能性があるということである、避けられないinglyは他のユーザと衝突して、ユーザの各組は先の秘密の私信(より安全な体系における放送発表と対照的に)を行わなければなりません。

HOST-SELECTED IDENTIFIERS PLUS DIRECTORY (Scheme 2)

ホストによって選択された識別子とディレクトリ(体系2)

     This system uses the same socket identifier structure
as presented above, except that the Host picks the identi-
fier at the time the socket is assigned, and the user has no
no prior knowledge or control of the assignment.  By itself,
this system would be totally unusable, because there would
be no way for User A to address User B.  However, it allows
certain service functions (such as the Network logger) to
have specifically assigned sockets.
     One of these is a Network Directory service.  This
serves to relate a socket identifier at a particular host
to the name of the user operating it.  This might either
be a single distributed service, or there might be a separ-
ate service at each host.
     Under this scheme, each user, A and B, first activates
his socket (or somehow gets his host to assign and tell
him of a socket identifier).  Then he gets the Directory
module at his host to associate his name with the identi-
fier of the socket just activated.  Following this, User A
in some manner gets the Directory Service at Host B to tell
him the socket identifier assigned to User B.  Then User A
dispatches a connection request for this socket.

このシステムは上で提示されるのと同じソケット識別子構造を使用します、ソケットが割り当てられるときHostがidenti- fierを選んで、ユーザにはいいえが全く優先的にないのを除いて。課題の知識かコントロール。 それ自体で、このシステムは完全に使用不可能でしょう、User AがUser B.Howeverを扱う方法が全くないでしょう、したがってそれで、あるサービス機能(Networkきこりなどの)は明確にソケットを割り当てることができました。 これらの1つはNetworkディレクトリサービスです。 これは、特定のホストでそれを操作しているユーザの名前にソケット識別子について話すのに役立ちます。 separが食べたaが各ホストでのサービスであるかもしれないなら、これはそこでのただ一つの分配されたサービスでしょうに。 この体系の下では、各ユーザ(AとB)は、最初に、彼のソケット(または、どうにか、彼のホストがソケット識別子について彼に割り当てて、言うのを得る)を動かします。 そして、彼は彼のホストのディレクトリモジュールにただ動くソケットのidenti- fierの名前を関連づけさせます。 これに続いて、何らかの方法によるUser AはHost BのディレクトリサービスにUser B.Then User Aに割り当てられたソケット識別子がこのソケットを求める接続要求を派遣すると彼に言わせます。

                                                                [Page 3]

When User B gets the request, he similarly calls on the
Directory service at Host A to find out the name of the user
who is operating the socket User B was called by.  If the
name is that of User A, User B can safely accept the request.
Otherwise, he rejects.
     This scheme is rather cumbersome, but some directory
services must exist for Host-selected socket identifiers to
work.  On advantage of the Directory Service is thst it
allows symbolic addressing.  A sizeable disadvantage in view
of its complexity is that it does not provide absolute
security.  (For exemple, after User A gets the identifier
of the socket he is to address, User B could deactivate it,
and somebody else could come along and get the same-named
socket.)

[3ページ] User Bが要求を得るとき、彼は、Host Aでのディレクトリサービスが、ソケットUser Bを操作しているユーザの名前によって電話をされたのを見つけるよう同様に呼びかけます。 名前がUser Aでは、User Bが安全に要請を受け入れることができるということであるなら。 さもなければ、彼は拒絶します。 この体系はかなり厄介ですが、いくつかのディレクトリサービスが、Hostによって選択されたソケット識別子が働くように存在しなければなりません。 ディレクトリサービスの有利な立場に、それがシンボリックなアドレシングを許容するthstがあります。 複雑さから見たかなり大きい不都合は絶対的な安全性を提供しないということです。 (User Aが彼が扱うことになっているソケットに関する識別子を得た後にUser Bがそれを非活性化できて、exempleに関して、他の誰かが、やって来て、同じように命名されたソケットを手に入れるかもしれません。)

ADMINISTRATIVELY ASSIGNED USER IDENTIFIERS (Scheme 3)

行政上割り当てられたユーザ識別子(体系3)

     This is the system that is put forth on page 5 of
Protocol Document 1(8/3/70).  Under it a user is permanently
assigned a user identifier by his home host.  There is a
user identifier subfield within the socket identifier, and a
user is permitted by an NCP to operate only those sockets
bearing his uder identifier.  This gives the user a selec-
tion of 256 sockets operable by him.
     In arranging for the connection the two Users A and B
tell each other their user identifiers (alternatively a user
ID could be read from a directory), and User B specifies
which of his sockets ("b") that he will "listen" on.  At
connection time, User A selects one of his sockets and
requests connection for it to socket "b" specified by User B.
By protocol only User B can operate socket "b", so User A
can be certain of reaching the right party.
     When User B receives the connection request, he examines
the user identifier subfield of the calling socket identifier.
If it is the user identifier of User A, User B accepts the
connection request, confident that it is actually User A at
the other end.  Otherwise B rejects the request.

これは5プロトコルDocumentページ(8/3/70)1で差し出されるシステムです。 それの下では、ユーザ識別子は永久に、彼のホームホストによってユーザに割り当てられます。 ソケット識別子の中にユーザ識別子部分体があります、そして、NCPで、ユーザが彼のuder識別子を持っているそれらのソケットだけを操作することが許可されます。 これは彼が操作できる256個のソケットのselec- tionをユーザに与えます。 接続を準備する際に、2Users AとBが彼らのユーザ識別子を互いに言います、そして、(ディレクトリからあるいはまたユーザIDを読むことができました)User Bは彼が「聴く」ソケット(「b」)のどれを指定するか。 接続時間に、User Aは、彼のソケットの1つを選択して、それのためのUser B.ByプロトコルUser Bだけによって指定されたソケット「b」との接続がソケット「b」を操作できるのでUser Aが正しいパーティーに届くのが確かである場合があるよう要求します。 User Bが接続要求を受け取るとき、彼は呼んでいるソケット識別子のユーザ識別子部分体を調べます。 それがUser Aに関するユーザ識別子であるなら、User Bは接続要求を受け入れます、それが実際にもう一方の端のUser Aであると確信しています。 さもなければ、Bは要求を拒絶します。

                                                                [Page 4]

The advantages of this scheme are that if both hosts
involved in a connection enforce the user ID assignment,
the misconnection aspect of security is solved and there
can be no socket naming conflict between users.  Also,
arrangements can be made openly and publicly between many
potential communicators.  A disadvantage to this scheme is
that some systems may be incapable of insuring user ID
integrity.

[4ページ] この体系の利点は接続にかかわる両方のホストがユーザID課題を実施するなら、セキュリティの付け違い局面が解決されていて、ユーザの間の闘争を命名するソケットが全くあるはずがないということです。 また、多くの潜在的伝達者の間でオープンに公的に手配をすることができます。 この体系への不都合はいくつかのシステムがユーザID保全を保障できないかもしれないということです。

A VIEW OF SOCKET NAME MEANING (Scheme 4)

ソケット名意味の視点(体系4)

     Another view of Network use is that programs will con-
nect to programs, via NCPs.  Some of these programs may be
multi-access subsystems that are really agents for local
consoles (and TELNETs).  Consoles will generally communicate
through some such software agent rather than directly to
an NCP.
     Programs, then, must have a fixed, unique identifier,
known to its remote users and perhaps to its local logger.
The identifier is constant; it does not change from day to
day.  If such a program is to allow multiple concurrent
connections (for many or a single user) then it must have
a range of variable identifiers as well.  It makes sense
to group these sockets in a contiguous range.  The variable
identifiers are transient and are dynamically associated
with Network logical connections.

Network使用の別の視点はプログラムがNCPでプログラムにnectをだますということです。 これらのいくつかのプログラムが本当に地方のコンソール(そして、TELNETs)のためのエージェントであるマルチアクセスサブシステムであるかもしれません。 一般に、コンソールは直接NCPにというよりむしろそのようなソフトウェアエージェントを通って交信するでしょう。 そして、プログラムには、リモート・ユーザーと恐らくその地元のきこりにとって知られている修理されて、ユニークな識別子がなければなりません。 識別子は一定です。 それは日々に変化しません。 そのようなプログラムが複数の同時接続(多くかシングルユーザーのための)を許容するつもりであるなら、それには、また、さまざまな変数名がなければなりません。 それは隣接の範囲でこれらを分類する意味をソケットにします。 変数名は、一時的であり、ダイナミックにNetworkの論理的な接続に関連づけられます。

      +---------------------   ---------------------+
      |                                           |
      | Fixed, unique       /  /  Variable          |
      | Identifier         /  /  Identifier         |
      |                                           |
      +---------------------   ---------------------+

+--------------------- ---------------------+ | | | 修理されて、ユニークな//可変です。| | 識別子//識別子| | | +--------------------- ---------------------+

      _________  _________/   _________  _________/
                /                       /
       Identifies the           Identifies a particular
       program uniquely         connection of the program

_________ _________/ _________ _________///が特定する、Identifies a事項は唯一プログラムの接続をプログラムします。

                                                                [Page 5]

The above premise is that the program (or agent) is
doing the communicating with an NCP and thus needs to be
identified for message traffic routing from an NCP.  In
the past it has been said that users can be mobile, i.e.,
log on from different sites, and thus it is the user that
needs identification.  In many typical on-line systems the
user first requests a service and then identifies himself
to the service for purposes of accounting, etc.  User IDs
can be transmitted after requesting a service and can thus
be elevated above the meaning of socket names.
     A program might typically associate the terminals, for
which it is an agent, with the variable part of the identi-
fier, i.e., the particular connection(s).  For example,
the Network Services Program (NSP) at Rand now uses the
following format for socket names.  The first 24 bits are
administratively assigned and would be known to a logger.
The multiplex code is normally chosen randomly.  Predefined,
fixed multiplex codes are possible also.

[5ページ] 上の前提は、プログラム(または、エージェント)がNCPで交信する予定であるということであり、その結果、メッセージトラフィックルーティングのためにNCPから特定される必要があります。 すなわち、ユーザモバイルである場合があると言われる過去に、異なったサイトからログオンしてください。そうすれば、その結果、それは識別を必要とするユーザです。 多くの典型的なオンラインシステムでは、ユーザは、会計などの目的のためのサービスに最初に、サービスを要求して、そして、身元を明らかにします。 ユーザIDをサービスを要求した後に、伝えることができて、その結果、ソケット名の意味の上に上げることができます。 プログラムはそれがエージェントである端末を通常関連づけるかもしれません、identi- fierの可変部分で、すなわち、特定の接続。 例えば、RandのNetwork Services Program(NSP)は現在、ソケット名に以下の形式を使用します。 最初の24ビットは、行政上割り当てられて、きこりにとって知られているでしょう。 通常、マルチプレックスコードは手当たりしだいに選ばれています。 また、事前に定義されて、固定されたマルチプレックスコードも可能です。

                24                   7     1
       +------------------------+---------+-+
       | Program Number         |Multiplex| | <-- Gender
       |                        |  Code   | |
       +------------------------+---------+-+

24 7 1 +------------------------+---------+-+ | プログラム番号|マルチプレックス| | <-- 性| | コード| | +------------------------+---------+-+

     The Socket name structure #1 (page 1) thus accomodates
the above example as well as other exploratory socket name
structures and various "standards" superimposed on the arbi-
trary field.

Socketは#1(1ページ)と構造を命名します、その結果、上記の例の、そして、他の踏査のソケットが構造と様々な「規格」と命名するaccomodatesはarbi- trary分野を上に重ねました。

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

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

                                                                [Page 6]

[6ページ]