RFC617 日本語訳

Network Working Group                                   Edward Taft (PARC-MAXC)
Request for Comments: 617                                              Feb 1974
NIC #21771

ネットワークワーキンググループエドワードタフト(PARC-MAXC)はコメントのために以下を要求します。 617 1974年2月のNIC#21771

              A Note on Socket Number Assignment 2

ソケット数の課題2に関する注

INTRODUCTION

序論

In several current and proposed protocols, as well as in a few
other documents, the assumption is made (or implied) that a user
process in control of one end of a Telnet connection has free
access to a group of socket numbers beginning with or surrounding
the Telnet socket numbers.

いくつかの現在の、そして、提案されたプロトコル、および他のいくつかのドキュメントでは、Telnet接続の片端のコントロールにおけるユーザ・プロセスがTelnetソケット番号を始まるか、または囲むソケット番号のグループにフリー・アクセスを持っているという仮定はされます(または、含意されます)。

For example, the File Transfer Protocol (RFC 542, NIC #17759)
specifies that the default data transfer sockets are S+2, S+3,
U+4, and U+5, where S and U are the server and user sockets
involved in the initial connection (ICP).

例えば、File Transferプロトコル(RFC542、NIC#17759)は、デフォルトデータ転送ソケットがS+2と、S+3と、U+4と、U+5であると指定します。そこでは、SとUは、ソケットが初期の接続(ICP)にかかわったサーバとユーザです。

Similarly, the proposed Network Graphics Protocol (NIC #19933)
provides for a second connection pair for graphics data,
parallel to the Telnet connection, using (at both ends) sockets
n+6 and n+7, where n is the Telnet receive socket.

提案されたNetwork Graphicsプロトコル(NIC#19933)は、Telnet接続に平行にソケットn+6とn+7を使用する(両端で)グラフィックスデータのためにnがTelnetであるところで同様にソケットを受けるように2番目の接続組に前提とします。

I would like to point out to designers of protocols that the
Host-Host Protocol (NIC #8246) quite explicitly places no
interpretations or constraints on host assignment of socket
numbers, except for the use of the low-order bit to indicate
direction of data flow. We should refrain from making further
assumptions (as does the "Socket Number List" document (RFC 503,
NIC #15747) in stating that the low-order 8 bits are
"user-specified"), lest we inadvertently exclude certain host
software architectures or protocol implementations.

Host-ホストプロトコル(NIC#8246)がデータフローの方向を示すために全く明らかに下位のビットの使用以外のソケット番号のホスト課題にどんな解釈も規制も置かないとプロトコルのデザイナーに指摘したいと思います。 私たちは、さらなる仮定(「ソケット数のリスト」という下位の8ビットが「ユーザによって指定されている」と述べることにおけるドキュメント(RFC503、NIC#15747)のような)をするのを控えるべきです、私たちがうっかりあるホストソフトウェア・アーキテクチャかプロトコル実装を除くといけないので。

AN EXAMPLE

例

To illustrate the source of my concern, let me briefly describe
the user software interface to the network in the PDP-10 NCP
implementation currently in use at HARV-10, CMU-10A, and CMU-108.
I will then show why the fixed socket number requirements of the
two protocols I mentioned above present implementation
difficulties, especially at the server end.

私の関心の源を例証するには、現在HARV-10、米カーネギーメロン大学-10A、および米カーネギーメロン大学-108で使用中のPDP-10 NCP実装でユーザソフトウェア・インタフェースについてネットワークに簡潔に説明させてください。 そして、私は、私が特にサーバにおける現在の実装困難を超えて言及した2つのプロトコルの固定ソケット数の要件がなぜ終わるかを示すつもりです。

Opening a connection at one of these hosts causes the creation of
a "device" (in approximately the same manner as, say, mounting a
disk pack). As such, an open connection is subject to any one of
a number of operations on devices in 10/50, including assignment
of logical names, opening for data transfer, and reassignment to
another job.

これらのホストのひとりで接続を開くと、「デバイス」(たとえば、ディスクパックを取り付けるのとほとんど同じ方法による)の作成は引き起こされます。 そういうものとして、オープンな接続は10/50におけるデバイスで手術件数のどれかを受けることがあります、論理的な名前の課題を含んでいて、データ転送、および再割当てのために別口の仕事に開いて。

                               -1-


-1-

The NCP allows a (non-privileged) user program to specify the
low-order 8 bits of the socket number of any connection which it
opens, and to specify that the other 24 bits be assigned in one of
three ways:

NCPで、(非特権がある)のユーザ・プログラムをそれが開くどんな接続のソケット番号の下位の8ビットも指定して、他の24ビットが3つの方法の1つで割り当てられると指定します:

-- As a function of the job number, making a "job-relative"
socket.

-- 「仕事親類」ソケットを作る職務番号の関数として。

-- As a function of the user identification, making a
"user-relative" socket.

-- 「ユーザ親類」ソケットを作るユーザ登録名の機能として。

-- As a "guaranteed unique" number, i.e. one assigned by the
NCP such that no other socket number in use has the same
high-order 24 bits.

-- a、「」 数、すなわち、使用中の他のものでないソケット番号には高位同じ24ビットがあるようにNCPによって割り当てられた保証されたユニークなもの。

A program may also specify all 32 bits of a local socket number
provided the high-order 24 bits are the same as the corresponding
bits in some other socket already owned by the same job.

また、高位24ビットが同じ仕事で既に所有されていたある他のソケットで対応するビットと同じであるなら、プログラムは地方のソケット番号のすべての32ビットを指定するかもしれません。

The NCP will, of course, allow assignment of a socket generated in
any of the above ways only if it is not already in use by the same
or any other job.

NCPはもちろんそれが同じくらいかいかなる他の仕事でも既に使用中でない場合にだけ上の方法について少しも生成されたソケットの課題を許容するでしょう。

PROBLEMS IN THE FTP SERVER IMPLEMENTATION 5

FTPサーバ実装5における問題

The FTP server is implemented in a manner that some readers may
find reminiscent of Padlipsky's "Unified User Level Protocol" (RFC
451, NIC #14135). Rather than directly executing most FTP
functions (in particular, system access and file transfer
functions), it merely maps FTP commands into local commands which
it "types" on a pseudo-Teletype (PTY) to a subjob, and similarly
maps local responses into FTP responses.

FTPサーバは何人かの読者がPadlipskyの「ユーザの統一されたレベルプロトコル」(RFC451、NIC#14135)のなごりであることがわかるかもしれない方法で実装されます。 直接、ほとんどのFTP機能(特にシステムアクセスとファイル転送機能)を実行するよりむしろ、それは、単にそれが疑似テレタイプ(PTY)でsubjobに「タイプする」ローカルのコマンドにFTPコマンドを写像して、同様にFTP応答に局所反応を写像します。

This scheme makes maximum use of existing software and
mechanisms for user authentication, accounting, and file
access, and eliminates the need for the (privileged) FTP server
to perform them interpretively. (This conforms to the
"principle of least privilege" described in RFC 501, NIC
#15818.)

この体系は、既存のソフトウェアとメカニズムのユーザー認証、会計、およびファイルアクセスの最大の使用をして、(特権がある)のFTPサーバが解釈的にそれらを実行する必要性を排除します。 (これはRFC501、NIC#15818で説明された「最少の特権の原則」に従います。)

In this implementation, FTP data transfers are performed by an
entirely different process (with a different user identification)
from the one that manages the server end of the Telnet connection.
Hence, since server sockets S and S+1 belong to the server
"control" job and sockets S+2 and S+3 are in the same 256-socket
number range, the latter two sockets are inaccessible to the "data
transfer" subjob.

この実装では、完全にTelnet接続のサーバ終わりを管理するものと異なったプロセス(異なったユーザ登録名がある)によってFTPデータ転送は実行されます。 したがって、サーバソケットSとS+1がサーバ「コントロール」仕事に属して、ソケットS+2とS+3が同じ256ソケットの数の範囲にあるので、後者の2個のソケットが「データ転送」subjobに近づきがたいです。

                                 -2-


-2-

Those who attended last spring's FTP meeting may recall that I
objected strenuously to the requirement that the FTP server use
a fixed pair of data sockets relative to its Telnet sockets, as
opposed to the old scheme in which the server has complete
freedom in the choice of its data sockets. The principal
reason is that it would seem to rule out the "two-process"
scheme I have just described.

去年の春のFTPミーティングに出席した人は、私がFTPサーバがTelnetソケットに比例してデータソケットの固定組を使用するという要件に激しく抗議したと思い出すかもしれません、サーバがデータソケットの選択における完全な自由を持っている古い体系と対照的に。 主要な理由は私がちょうど説明した「2プロセス」の体系を除外するように思えるだろうということです。

In fact, in our case there is a way around the problem. The
FTP server control job can open the data connections itself,
then "reassign" the created "device" to the data transfer
subjob. A kludgey solution at best, and one I would rather
have avoided! Inter-job socket reassignment is hardly an
operation one is likely to find available in most operating
systems.

事実上、私たちの場合には、問題の周りに道があります。 FTPサーバコントロール仕事は、データ転送subjobにそれ自体でデータ接続を開いて、次に、作成された「デバイス」を「再選任できます」。 せいぜいkludgeyソリューション、および私が避ける方がましであった1つ! 相互仕事のソケット再割当てはほとんど1つが利用可能であることがほとんどのオペレーティングシステムでわかりそうである操作ではありません。

DIFFICULTIES WITH THE GRAPHICS PROTOCOL

グラフィックスプロトコルにおける困難

Providing a graphics connection parallel (at a fixed socket number
distance) to the Telnet connection might potentially present the
same difficulty as described above for FTP connections.

グラフィックス接続平行線(固定ソケット数の距離の)をTelnet接続に提供すると、FTP接続のための上で説明されるのと同じ困難は潜在的に提示されるかもしれません。

In the most frequently used model of Telnet communication, as
well as in many implementations, the server Telnet is a process
quite distinct from the "user" process under its control. The
two processes are typically interfaced through the operating
system's terminal service in such a way that the "user" process
perceives a ,terminal" as opposed to a "network connection".

Telnetコミュニケーションの最も頻繁に使用されたモデル、および多くの実装では、サーバTelnetはコントロールの下における「ユーザ」プロセスと全く異なったプロセスです。 「ネットワーク接続」と対照的に「2つのプロセスがオペレーティングシステムのターミナルサービスで通常「ユーザ」プロセスがaを知覚するような方法で連結されます、端末です」。

In Tenex, for example, a job controlled from a network
terminal has no handle whatever on the server Telnet
connection; hence, it has no way of obtaining control of
sockets n+6 and n+7 for a graphics connection.

Tenexでは、例えば、いいえはサーバTelnet接続のときにネットワーク端末から制御された仕事で何でも扱います。 したがって、それには、グラフィックス接続のためのソケットn+6とn+7のコントロールを得る方法が全くありません。

In the Harvard-Carnegie 10/50 implementation, it happens (for
largely accidental reasons) that a job logged in from the
network does have control (i.e. is considered the owner) of the
server Telnet sockets.

ハーバード-カーネギー10/50実装では、ネットワークからログインされた仕事がサーバTelnetソケットのコントロール(すなわち、所有者であると考えられる)を持っているのは起こります(主に偶然の理由で)。

However, there is another problem. Many operating systems provide
means by which the association between terminals and jobs may be
changed.

しかしながら、別の問題があります。 多くのオペレーティングシステムが端末と仕事との協会が変えられるかもしれない手段を提供します。

To use familiar terminology, a terminal may be "detached" from
one job and "attached" to another, in a manner which does not
destroy any jobs or any network connections.

端末は、身近な用語を使用するために、1つの仕事から「取り外され」て、別のものに「付けられるかもしれません」、どんな仕事か少しのネットワーク接続も滅ぼさない方法で。

                              -3-


-3-

Hence, it is entirely possible that a user could start up a
program that uses sockets n+6 and n+7 (where n is the server
Telnet receive socket), detach his terminal from that job, attach
it to another, attempt to run a program using the Graphics
Protocol, and have the attempted data connection fail because
sockets n+6 and n+7 are already in use (for the same value of n,
since we are referring to the same network terminal).

したがって、ソケットn+6とn+7が既に使用中であるので(私たちが同じくらい言及しているので、nの同じ値のために、端末をネットワークでつないでください)、ユーザがソケットn+6とn+7(nがサーバであるところでは、Telnetはソケットを受ける)を使用するプログラムを立ち上げて、その仕事から彼の端末を離して、別のものにそれを付けて、Graphicsプロトコルを使用することでプログラムを動かすのを試みて、試みられたデータ接続が失敗できたのは、完全に可能です。

CONCLUSION 7

結論7

There are, of course, a few network-wide socket number conventions
necessary for establishing initial connection.

もちろん、初期の接続を確立するのに必要ないくつかのネットワーク全体のソケット数のコンベンションがあります。

Reserving sockets 0-255 for standard ICP functions is an
example of one such convention.

標準のICP機能のためにソケット0-255を予約するのは、そのようなコンベンションの1つに関する例です。

Additionally, I think that for the purpose of simplicity it is
reasonable to expect any process to be able to gain control of
a small block of "adjacent" sockets, such as an even-odd pair
(as in ICP), if it asks for them at the same time.

さらに、私は、どんなプロセスも予想するのが妥当である簡単さの目的のためのそれが「隣接している」ソケットのわずかなブロックのコントロールを獲得できると思います、変な組のようにさえ(ICPのように)、同時にそれらを求めるなら。

However, as the foregoing examples have demonstrated, to impose
further fixed socket number requirements is to risk the danger of
making unwarranted assumptions about the nature of protocol
implementations, the structure of user processes, etc., at
individual hosts.

しかしながら、さらなる固定ソケット数の要件を課すのは、以上の例が示したようにプロトコル実装の本質、ユーザ・プロセスの構造などに関する根拠のない推定をするという危険の危険を冒すことです、個々のホストで。

Once the initial Telnet connection is established, any other
necessary connections should be established by negotiation over
the Telnet connection (e.g. by messages of the form "Please
connect to my socket xxxxxx", "OK, connecting via my socket
yyyyyy"). There is absolutely no need for any protocol to specify
fixed socket numbers, except for the purposes of the initial
connection (ICP).

初期のTelnet接続がいったん確立されると、いかなる他の必要な接続もTelnet接続(例えば、「私のソケットxxxxxxに接続してください」というフォームに関するメッセージによる「私のソケットyyyyyyを通して接続するOK」)の上の交渉で確立されるべきです。 どんなプロトコルも固定ソケット番号を指定する必要は全く絶対にありません、初期の接続(ICP)の目的を除いて。

                                    -4-

-4-