RFC91 日本語訳

Network Working Group                                    George H. Mealy
Request for Comments: 91                              Harvard University
                                                       December 27, 1970

コメントを求めるワーキンググループのジョージH.Mealyの要求をネットワークでつないでください: 91 1970年12月27日のハーバード大学

                     A PROPOSED USER-USER PROTOCOL

提案されたユーザユーザプロトコル

INTRODUCTION:

序論:

   There are many good reasons, and maybe one or two bad ones, for
   making it appear that communication over the Network is only a
   special case of input/output -- at least as far as user programming
   is concerned.  Thus, for instance, the Harvard approach toward
   implementing the HOST-HOST protocol and Network Control Program
   treats each link as a "logical device" in PDP-10 terminology.
   Setting up a connection is similar to local device assignment, and
   communication over a link will make use of the standard system
   input/output UUO's.  This makes it possible to use existing programs
   in conjunction with the Network without modification -- at least if
   other PDP-10's are being dealt with.

多くのもっともな理由、および多分1か2つの悪いものがあります、Networkの上のコミュニケーションが入力/出力の特別なケースにすぎないことを現れさせるように--ユーザプログラミングは関係があるのと少なくとも同じくらい遠いです。 このようにして、そして、例えば、HOST-HOSTプロトコルとNetwork Control Programを実装することに向かったハーバードのアプローチはPDP-10用語で「論理的なデバイス」として各リンクを扱います。 接続をセットアップするのはローカル装置課題と同様です、そして、リンクの上のコミュニケーションは標準のUUOのシステム入力/出力ものを利用するでしょう。 これで、変更のないNetworkに関連して既存のプログラムを使用するのは可能になります--他なら、少なくとも、PDP-10のものは対処されています。

   This takes us only so far, however.  The notion of a "logical device"
   does not exist on the PDP-10; it does on the IBM 360 (I am speaking
   here at the level of the operating system -- user program interface).
   Furthermore, in the absence of a Network standard requiring fixed
   representations for integers, reals, etc. (which I would oppose), any
   pair of user processes must arrive at a local agreement, and one or
   both must assume the burden of data conversion where necessary.  Any
   standard protocol should allow such agreements to be given expression
   and should accommodate at least the minimum of control information
   that will allow such agreements to function in practice.  Finally, we
   must note that the IMP-IMP and HOST-HOST protocols do not provide for
   a check that an action requested by a user process is actually
   accomplished by the other processes; this type of issue has always
   been regarded as subject to treatment at the USER-USER protocol
   level.

しかしながら、これは今までのところだけ、私たちを連れて行きます。「論理的なデバイス」の概念はPDP-10に存在していません。 それはIBM360でそうします(私はここ、オペレーティングシステムのレベルで話しています--ユーザ・プログラムは連結します)。 その上、Networkが不在のとき、標準の必要さは整数、本物などの表現を修理しました。 (私が反対するだろう), どんな組のユーザ・プロセスも現地協定に到達しなければなりません、そして、ものか両方が必要であるところでデータ変換の負担を仮定しなければなりません。 どんな標準プロトコルも、式が与えられているそのような協定を許すべきであり、実際には機能するそのような協定を許す制御情報の最小限を収容するべきです。 最終的に、私たちは、IMP-IMPとHOST-HOSTプロトコルが、ユーザ・プロセスで要求された動作が実際に他のプロセスによって実行されるのをチェックに前提としないことに注意しなければなりません。 このタイプの問題はいつもUSER-USERプロトコルレベルにおける処理を条件として見なされました。

   This proposal is intended to face the above three types of issue only
   to a certain extent.  I can best explain that extent by stating the
   criteria I would use to judge any USER-USER protocol proposal:

この提案がある程度だけ上の3つのタイプの問題に直面していることを意図します。 私は私がどんなUSER-USERもプロトコル提案であると判断するのに使用する評価基準を述べることによって、その範囲について最もよく説明できます:

Mealy                                                           [Page 1]

RFC 91               A Proposed User-User Protocol         December 1970

提案されたユーザユーザプロトコル1970年12月あたり粉だらけ[1ページ]のRFC91

   1.   The notion of a (logical) _record_ should be present, and the
        notion of a _message_ should be suppressed. (To a FORTRAN pro-
        grammer, that which is written using one WRITE statement with no
        accompanying FORMAT is a record; to an OS/360 machine language
        programmer, PUT writes a record).

1. (論理的な)_記録_の概念は、プレゼントと、_が抑圧されるべきであるという_メッセージの概念であるべきです。 (FORTRAN親grammerに、付随のFORMATなしで1つのWRITE声明を使用することで書かれているそれは記録です; OS/360機械語プログラマに、PUTは記録を書きます。)

   2.   It should be possible to so implement the protocol in HOST sys-
        tems and/or library routines that now existing user programs can
        access files anywhere in the Network without program modifica-
        tion. (Initially, at least, this ability must be restricted to
        HOST systems of the same type).

2. 現在既存のユーザ・プログラムがNetworkでどこでもプログラムmodifica- tionなしでファイルにアクセスできるのは、したがって、HOST sys- temsのプロトコル、そして/または、ライブラリ・ルーチンを実装するのにおいて可能であるべきです。 (少なくとも初めは、この能力を同じタイプのHOSTシステムに制限しなければなりません。)

   3.   The protocol should be implementable (not necessarily imple-
        mented) in any HOST system at the SVC or UUO level.  Specific
        knowledge of the characteristics of the other HOST involved
        should be unnecessary.

3. プロトコルはどんなHOSTシステムでもSVCかUUOレベルで実装可能であるはずです(必ずimple- mentedであるというわけではない)。 HOSTがかかわったもう片方の特性に関する特定の知識は不要であるべきです。

   It should be noted that the above imply that some user programs must
   be aware of the nature of the other HOST -- at least in each case
   where the second criterion fails.  As we make progress in (or give up
   on) the cases where the failure now occurs, the burden of accommodat-
   ing system differences will shift toward implementation in protocols
   (i.e., the HOST systems) or, by default, in user programs.

上記が、いくつかのユーザ・プログラムが少なくとも2番目の評価基準が失敗する各場合でもう片方のHOSTの自然を意識しているに違いないのを含意することに注意されるべきです。 私たちが失敗が現在起こる(上をオンに与えてください)場合で進展するとき、accommodat- ingシステム差の負担はプロトコル(すなわち、HOSTシステム)かデフォルトでユーザ・プログラムにおける実装に向かって移行するでしょう。

   Quite clearly, any proposal initiated today should be suspect as to
   the extent to which it "solves" ultimate problems.  How ambitious to
   be is strictly a matter of taste.  At this stage, I prefer to try
   something which I believe can be used by all of us (and, hence, is
   worth doing), goes a reasonable distance towards solving our short-
   range problems, is easy to do, and offers hope of viability in the
   long range view.  In the following, I intend to describe the proposal
   itself with, I hope, proper motivational arguments for its pieces.  I
   will then sketch the specific implementation we at Harvard are making
   for the PDP-10 and describe how we intend to apply it in the specific
   case of storage of files on other PDP-10's in the Network.

どれくらい野心満々であるかは、厳密にそうです。全く明確に、今日開始されているどんな提案もそれが究極の問題を「解決する」範囲に関して疑わしいはずです。好き好き。 現在のところ、私は、私が長い範囲眺望で私たちのすべてで使用できて(したがって、価値はです)、私たちの短い範囲問題を解決することに向かって妥当な距離で行って、するのが簡単であり、生存力の希望を提供すると信じている何かを試すのを好みます。 私が、以下で望んでいると提案自体を説明するつもりである、断片のための適切な動機づけの議論。 私は、次に、ハーバードの私たちがPDP-10のために作っている特定の実装についてスケッチして、私たちがNetworkでPDP-10の他のところにおけるファイルのストレージの特定の場合でどうそれを適用するつもりであるかを説明するつもりです。

USER-USER PROTOCOL (PROPOSAL)

ユーザユーザプロトコル(提案)

   The following protocol is intended to apply to the data bits in mes-
   sages between the end of the marking bits and the beginning of the
   padding bits. _The present IMP-IMP and HOST-HOST protocols are unaf-
   fected by this proposal_.

以下のプロトコルがマークビットの端と詰め物ビットの始まりの間でmes賢人でデータ・ビットに適用することを意図します。 _この提案_によって現在のIMP-IMPとHOST-HOSTプロトコルはunaf- fectedです。

   The general principle is that each segment (this is not a technical
   term) of data is preceded by control information specifying its
   nature and extent.  The basic scheme has been evolved from that used
   in the SOS buffering system (see the papers in JACM, April 1959 and
   especially that by O.R. Mock).

一般的な原則はその自然と範囲を指定する制御情報がデータの各セグメント(これは専門用語でない)に先行するということです。 基本的な体系はシステムをバッファリングしながらSOSで使用されるそれから発展されました。(JACM、1959年4月、および特にそれでO.R.Mockで書類を見てください。).

Mealy                                                           [Page 2]

RFC 91               A Proposed User-User Protocol         December 1970

提案されたユーザユーザプロトコル1970年12月あたり粉だらけ[2ページ]のRFC91

   Our point of view is that a link is a carrier of information.  Infor-
   mation is carried in segments of a fixed maximum length called _mes-
   sages_ [1].  That this is so is an accident, from the user's point of
   view; when he wishes to transmit a contiguous stream of data, he will
   in general, segment it in a different (from the IMP-IMP or HOST-HOST
   protocol view) manner -- we will call his segment a _record_.  It
   should be clear that this is entirely analogous between the notion of
   (physical) _block_ and (logical) record.  On the side, file storage
   systems also make use of control and status information; we will
   also.

私たちの観点はリンクが情報のキャリヤーであるということです。 Infor- mationは_mes賢人_[1]と呼ばれる固定最大の長さのセグメントで運ばれます。 これがそうは、ユーザの観点からの事故です。 一般に、彼は、彼がデータの隣接のストリームを伝えたがっているとき、異なった(IMP-IMPかHOST-HOSTプロトコル視点からの)方法でそれを区分するように望んでいます--私たちは、_それがこれが完全に類似しているのが明確であるはずである彼のセグメントa_記録を(身体検査)_ブロック_の概念と呼んで、記録するつもりです(論理的な)。 また、側では、ファイルストレージシステムがコントロールと状態情報を利用します。 また、私たちはそうするつもりです。

   At the USER-USER protocol level, all information transmitted over the
   link is a sequence of flags followed by (possibly null) data blocks.

USER-USERプロトコルレベルでは、リンクの上に伝えられたすべての情報が(ことによるとヌル)のデータ・ブロックが支えた旗の系列です。

   The general format will be:

一般形式は以下の通りになるでしょう。

        OPERATION     COUNT     DATA

操作カウントデータ

   The OPERATION field is always present and is four bits long.  The
   COUNT field, when present, gives the number of data bytes following
   in the data block.  The byte size is set by the last preceding SIZE
   flag (in most cases).  The byte may be between zero and 255 bits long
   (Yes, Virginia, zero is zero even when you have a System/360).  The
   OPERATION field and the COUNT field (when present) are called the
   flag and the data bytes (when present) the data block.  Flags fol-
   lowed by data blocks (even when null due to a zero count) are called
   block flags, and other flags are called whyte [2] flags.

OPERATION分野は、いつも存在していて、長さ4ビットです。 存在しているとき、COUNT分野はデータ・バイトの数をデータ・ブロックで次のである与えます。 最後の前のSIZE旗(多くの場合)でバイトサイズは設定されます。 バイトが長い間、ゼロと255ビットの間あるかもしれません(はい、ヴァージニア、あなたがSystem/360を持つときさえ、ゼロはゼロです)。 OPERATION分野とCOUNT分野(存在しているとき)はデータが妨げる旗とデータ・バイト(存在しているとき)と呼ばれます。 データによるfol- lowedが妨げる(ゼロのためにヌルでさえあるときには、数えてください)旗はブロック旗と呼ばれます、そして、他の旗はwhyte[2]旗と呼ばれます。

   It is to be noted that, since the SIZE flag sets the byte size for
   the following blocks, byte size may be set at that "natural" for the
   sending or for the receiving HOST, depending on local agreement
   between the sending and receiving processes.  It is specifically
   required that a SIZE flag appear in each message prior to any block
   flag (except the ASCII flag); the SIZE flag may be introduced on a
   default basis by the routine(s) implementing the protocol and is
   intended partially as a means of detecting certain classes of error.

SIZE旗が以下のブロックにバイトサイズを設定するのでバイトサイズがおまけに、発信か受信HOSTに「自然な」状態で設定されるかもしれないことに注意されることになっています、送受信プロセスの間の現地協定によって。 明確に、SIZE旗がどんなブロック旗(ASCII旗を除いた)の前にも各メッセージに現れるのが必要です。 SIZE旗は、プロトコルを実装しながらデフォルトベースでルーチンで導入されるかもしれなくて、あるクラスの誤りを検出する手段として部分的に意図します。

   The COUNT field is 8 bits in length (except in the EOM flag, where it
   is 16 bits long).  The flags are as follows:

長さ(EOM旗を除いてそれが長さ16ビットであるところで)はCOUNT分野が8ビットです。 旗は以下の通りです:

   Whyte Flags:

ホワイトは弛みます:

      0 - NUL             No operation (consider next flag)
      1 - RS              Record Separator (end of record)
      2 - GS              Group Separator (end of group)
      3 - FS              File Separator (end of file)
      4 - ESC             Escape to local convention for flags
      5 -                 (reserved for later assignment)

0 --NULいいえ操作(次の旗を考える)1--RS Record Separator(記録の終わり)2--GS Group Separator(グループの終わり)3--FS File Separator(ファイルの終り)4--旗5のための地方のコンベンションへのESC Escape、-(後の課題のために、予約されます)

Mealy                                                           [Page 3]

RFC 91               A Proposed User-User Protocol         December 1970

提案されたユーザユーザプロトコル1970年12月あたり粉だらけ[3ページ]のRFC91

      6 - EOM N           End of Message (N is total bit count)
      7 - SIZE N          Byte size is N bits
      8 - IGNORE N        Ignore following data bits

IGNORE N Ignoreが続いて、6--Message(Nは総噛み付いているカウントである)7のEOM N End--SIZE N ByteサイズがNビット8である、データ・ビット

   Block Flags:
       9 - SYS N          N bytes of data for receiving HOST system
      10 - CONTROL N      N bytes of control data follow
      11 - STATUS N       N bytes of status data follow
      12 - LABEL N        N bytes of identification data follow
      13 - KEY N          N bytes of key data follow
      14 - ASCII N        N (8-bit) bytes of ASCII data follow
      15 - BLOCK N        N bytes of data follow

旗を妨げてください: 9--HOSTシステム10を受け止めるためのSYS N Nバイトのデータ--CONTROL N Nバイトの制御データは11に続きます--STATUS N Nバイトの状態データは12に続きます--LABEL N Nバイトの識別情報は13に続きます--KEY N Nバイトの重要なデータは14に続きます--ASCII N N(8ビット)バイトのASCIIデータは15に続きます--BLOCK N Nバイトのデータは従います。

   I have already mentioned the requirement for SIZE.  Absence of the
   SIZE flag in any message containing block flags (except ASCII) is a
   definite error.  EOM is partially another error-checking device and
   partially a device for bypassing the padding conundrum.  A user pro-
   gram should never see EOM on input; the user may write an EOM to
   force transmission.  EOM delimits the end of the useful information
   in the message and restates the total number of bits in the message,
   starting with the first bit following the marking and ending with the
   last bit of the EOM count field, to check possible loss of informa-
   tion.  This is a check against errors in the IMP-HOST electrical
   interface and in the HOST mushyware.  EOM must appear at the end of
   each messager, unless ESC has apeared.

私は既にSIZEのための要件について言及しました。 ブロック旗(ASCIIを除いた)を含むどんなメッセージでも、SIZE旗の欠如は明確な誤りです。 EOMは、部分的にデバイスを誤りでチェックしながら、部分的に別のものです。そっと歩いている謎を迂回させるためのデバイス。 ユーザ親グラムは入力にEOMを決して見るべきではありません。 ユーザは、トランスミッションを強制するためにEOMに書くかもしれません。 EOMはメッセージで役に立つ情報の終わりを区切って、メッセージでビットの総数を言い直します、informa- tionの可能な損失をチェックするためにEOMカウント分野の最後のビットでマークと結末に続いて、最初のビットから始まって。 これはIMP-HOSTの電気インタフェースとHOST mushywareの誤りに対するチェックです。 ESCがapearedしていない場合、EOMはそれぞれのmessagerの端に現れなければなりません。

   ESC is intended as a (hopefully) unused escape hatch, for nonuse by
   those installations and/or applications wishing to avoid using more
   than four bits of the USER-USER protocol on any link.  For instance,
   it may be desired to use a link as a bit stream, ignoring even mes-
   sage boundaries.  If and when anarchists can achieve local agreement,
   more power to them!

ESCは不使用のために(希望をいだいて)未使用の脱出口としてどんなリンクの上にもUSER-USERプロトコルの4ビット以上を使用するのを避けたがっているそれらのインストール、そして/または、アプリケーションで意図します。 例えば、mesの賢人の境界さえ無視して、少し流れるときリンクを使用することが望まれるかもしれません。 アナキストが現地協定を達成できるなら、彼らにより多くのパワーです!

   NUL and IGNORE are intended to be space fillers, in case it is help-
   ful to make the first bit of the subsequent data block occur on a
   convenient address boundary. (An especially helpful HOST interrupt
   routine might even paste a combination of NUL and IGNORE over the
   marking bits when receiving a message -- in which case, their bit
   count should be transmitted on to the GET routines to correct the EOM
   bit count check).  The separator operations introduce the notions of
   logical record, group, and file.  Specifically, there is no require-
   ment that a record be contained entirely within a message or that
   only a single record be contained in a message!  In addition, there
   is no requirement that only one file be transmitted during a connec-
   tion.  For instance, a user might wish to use a link to transmit a
   collection of rountines, and then do something else with the link.

NULとIGNOREは詰物であることを意図します、それが順次データブロックの最初のビットを便利なアドレスの限界に現れさせる助けfulであるといけないので。 (メッセージを受け取るとき、特に役立っているHOST割り込みルーチンはNULとIGNOREの組み合わせをマークビットの上貼りさえするかもしれません--その場合、彼らの噛み付いているカウントはEOMビット件数検査を修正するためにGETルーチンに伝えられるべきです。) 分離符操作は、論理レコードの概念を紹介して、分類して、ファイルされます。 明確に、いいえがメッセージの中に完全に含まれて、aが記録するmentが必要である、またはシングルだけが記録する含まれたコネがメッセージであったならあります! さらに、1個のファイルだけがconnec- tionの間送られるという要件が全くありません。 例えば、ユーザは、rountinesの収集を伝えるのにリンクを使用して、次に、リンクで他の何かをしたがっているかもしれません。

Mealy                                                           [Page 4]

RFC 91               A Proposed User-User Protocol         December 1970

提案されたユーザユーザプロトコル1970年12月あたり粉だらけ[4ページ]のRFC91

   By local agreement, then, a single routine might consist of a number
   of records forming a group, the whole collection might form a file,
   and the link might remain connected after the FS flag is received.

現地協定で、次に、ただ一つのルーチンはグループを作る多くの記録から成るかもしれません、そして、全体の収集はファイルを形成するかもしれません、そして、FS旗が受け取られていた後にリンクは接続されていたままで残るかもしれません。

   The interpretation of the various block flags is similarly open to
   local agreement.  The two flags intended to convey pure data are
   ASCII and BLOCK; the difference between them is only (as far as the
   protocol is concerned) that the byte size is implicit for ASCII (8
   bits) and explicit for BLOCK (the count field of the next preceding
   SIZE flag).  Beyond this, however, the semantic content of the block
   following ASCII is governed by the current standards for ASCII;
   EBCDIC information may not be transmitted in an ASCII block!!

様々なブロック旗の解釈は同様に現地協定に開かれています。 純粋なデータを伝えることを意図する2個の旗が、ASCIIとBLOCKです。 それらの違いはバイトサイズがASCII(8ビット)において暗黙であってBLOCK(次の前のSIZE旗のカウント分野)だけに、明白であるということです。 しかしながら、これを超えて、ASCIIに続くブロックの意味内容はASCIIの現在の規格によって支配されます。 EBCDIC情報はASCIIブロックで伝えられないかもしれません!

   CONTROL and STATUS are intended for communication of control informa-
   tion between user processes, and the interpretation of their accom-
   panying data blocks is open to local agreement.  Generically, CONTROL
   means "try to do the following" and STATUS means "but I feel this
   way, doctor."  A CONTROL flag will prompt a returned STATUS flag,
   sooner or later, or never.  LABEL is intended for use in identifying
   the following unit(s) of data, at the file or group level.  Again,
   the specific interpretation is a matter of local agreement.  KEY is
   intended to mimic the notion of address or key -- this is at the
   record, data item, or even physical storage block level.  For the
   familiar with PDP-10 system and/or OS/360, the following parallels
   are offered for guidance:

CONTROLとSTATUSはコントロールinforma- tionに関するコミュニケーションのためにユーザ・プロセスの間で意図します、そして、それらのaccom- panyingデータ・ブロックの解釈は現地協定に開かれています。 一般的に、CONTROLは、「以下をしようとします」と意味します、そして、STATUSは「医師、しかし、私はこの道を感じます。」と意味します。 CONTROL旗は返されたSTATUS旗を決してうながさないでしょう。LABELは以下のユニットのデータを特定することにおける使用のために意図します、ファイルかグループレベルで。 一方、特定の解釈は現地協定の問題です。 KEYがアドレスかキーの概念をまねることを意図します--これが記録、データ項目、または物理的な記憶ブロックレベルにさえあります。 PDP-10システム、そして/または、OS/360へのなじみ深さに関しては、指導のために以下の平行線を提供します:

   USER-USER protocol      OS/360            PDP-10
   __________________      ______            ______

USER-USERプロトコルOS/360PDP-10__________________ ______ ______

     CONTROL               OPEN              OPEN

開いている戸外を制御してください。

                           CLOSE             CLOSE

近くに閉じてください。

     LABEL                 DSCB              File retrieval information

LABEL DSCB File検索情報

     KEY                   KEY               USETI/USETO argument

KEY KEY USETI/USETO議論

     CONTROL               READ              IN/INPUT

読まれるか、または入力されたコントロール

                           WRITE             OUT/OUTPUT

/出力を書き上げてください。

                           ALLOCATE ?        ENTER

割り当てますか? 入ってください。

                           OPEN ?            LOOKUP

開きますか? ルックアップ

     STATUS                ?                 GETSTS

状態? GETSTS

Mealy                                                           [Page 5]

RFC 91               A Proposed User-User Protocol         December 1970

提案されたユーザユーザプロトコル1970年12月あたり粉だらけ[5ページ]のRFC91

   The "?" notations above indicate lack of a very direct parallel.  It
   is worth noting that the OS/360 GET and PUT have direct parallels in
   any implementation of the USER-USER protocol that embodies the notion
   of record; our implementation of the protocol will lead to introduc-
   tion of this notion for all PDP-10 input/output involving disc and
   tape storage, as well as IMP communication.

上の“?"記法は非常にダイレクトな類似の不足を示します。 OS/360GETとPUTには記録の概念を具体化するUSER-USERプロトコルのどんな実装でもダイレクト類似があることに注意する価値があります。 私たちのプロトコルの実装はディスクとテープ記憶装置にかかわるすべてのPDP-10入力/出力のためのこの概念のintroduc- tionに通じるでしょう、IMPコミュニケーションと同様に。

   If I knew the MULTICS terminology, I could extend the set of paral-
   lels above with more precision.  Although my terminology has been
   drawn from systems with explicit input/output imperatives, I wish to
   emphasize that this setup in intended to handle control and data com-
   munication in general; MULTICS is a system in which the classical
   distinction between external and internal storage is blurred (from
   the user's point of view) in a manner I wish it blurred in the USER-
   USER protocol.  I offer SYS with only slight trepidation.  The gen-
   eral notion is that one should be able to communicate directly with a
   foreign HOST rather than via a foreign user process as its intermedi-
   ary.  SYS is like a UUO or SVC, but for the foreign HOST's consump-
   tion rather than my HOST's.  From the HOST's point of view, the prob-
   lem in implementation is in establishing a process context record
   unconnected with any local user process.  This, however, is strongly
   associated with our current LOGON conundrum.  On the PDP-10, for
   instance, users are more or less identified with local teletype
   lines, and any link is not one of those! Hence, subterfuge is neces-
   sary to let a foreign user log on.  OS/360 is as (actually, more)
   perverse in its own way.

私がMULTICS用語を知っているなら、より多くの精度による上のparal- lelsのセットを広げることができるでしょうに。 明白な入力/出力命令でシステムから私の用語を得て、私がハンドルへの意図されるところのこのセットアップが制御されると強調するという願望と一般に、データcom- municationですが。 MULTICSは外部と内部記憶装置の古典的な区別が私が、それをUSER- USERプロトコルでぼけさせることを願っている方法でぼかされる(ユーザの観点から)システムです。 私はわずかな恐怖だけを伴うSYSを提供します。 情報を得てください。eral概念は外国ユーザ・プロセスでというよりむしろ外国HOSTと共にintermedi- aryとして直接伝達できるべきであるということです。 SYSはUUOかSVCに似ていますが、私のHOSTのものよりむしろ外国HOSTのconsump- tionのためにあります。 HOSTの観点から、実装におけるprob- lemはどんなローカルのユーザ・プロセスによる無関係のプロセス文脈記録も確立する際に来ています。 しかしながら、これは強く私たちの現在のLOGON謎に関連づけられます。 例えば、PDP-10では、ユーザは多少地方のテレタイプ系列と同一視されています、そして、どんなリンクもそれらの1つではありません! したがって、逃げ口上は外国人のユーザにログオンさせるneces- saryです。 (実際に以上)として、OS/360はそれなりにへそ曲がりです。

   The process of logging a foreign process onto my local system is not
   (except possibly for MULTICS) a simple matter of having a special
   (!!)  user job present which is responsible for doing it.  When and
   if anything else is possible, the HOST must provide a system instruc-
   tion (UUO or SVC or whatever) that gives the requisite information
   establishing a process independent in all senses of the process that
   made the request.  Otherwise, self-protection mechanisms which are
   reasonable for any system will make us all much more interdependent
   that we wish.  To do this, there must exist in every system a UUO/SVC
   that does the right thing (ATTACH, but forget me).  If this is true,
   then the LOGON process over the Network is tantamount to issuance of
   a foreign UUO/SVC by another node in the Network.  I see no reason-
   able way around this.  If that is the case, then SYS N is the kind of
   flag to use to convey the requisite data.  If that is so, then it is
   only reasonable to let SYS convey a request for any OS instruction at
   the user program-operating system interface level!

私のローカルシステムに外国プロセスを登録するプロセスはそれをするのに原因となる現在の特別な(!!)ユーザ仕事を持つ(ことによるとMULTICS以外の)簡単な事柄ではありません。 そして、いつ、ものが他の何か可能であるなら、HOSTは必需品を与えるシステムinstruc- tion(UUO、SVCまたは何でも)にあらゆる点で要求をしたプロセスのプロセス独立者を確立する情報を供給しなければなりません。 さもなければ、どんなシステムにも、妥当な自己保護メカニズムで私たちは皆、はるかに互いに依存しるようになるでしょう。願っています。 これをするために、正しいことをするUUO/SVCがあらゆるシステムに存在しなければならない、(私を忘れるのを除いたATTACH これが本当であるなら、Networkの上のLOGONプロセスはNetworkの別のノードで外国UUO/SVCの発行と等しいです。 私はこれの周りでどんな理由のできる道も見ません。 それがそうであるなら、SYS Nは必要なデータを伝えるのに使用する旗の種類です。 それがそうなら、SYSにユーザプログラムオペレーティングシステムインタフェースレベルでどんなOS指示を求める要求も単に伝えさせるのは、妥当です!

   The practical questions of implementation are something else! In the
   case of the PDP-10, I can pretty well see how to turn a SYS into
   either a LOGON request to execute a monitor command or UUO (would
   that they were the same) as the case might be.  OS/360 is more

実装の実用的な問題は他の何かです! PDP-10の場合では、私はケースが変わるときSYSをモニタ・コマンドを執行するというLOGON要求かUUO(彼らは同じであった)のどちらかに変える方法をかなりよく見ることができます。 OS/360は、より多いです。

Mealy                                                           [Page 6]

RFC 91               A Proposed User-User Protocol         December 1970

提案されたユーザユーザプロトコル1970年12月あたり粉だらけ[6ページ]のRFC91

   sophisticated, unfortunately.  MULTICS might make it.  Naytheless, I
   hope that is clear that what we want to do, which is what the proto-
   col should reflect, is quite a different question from that of how it
   is to be done in the context of a specific HOST system.  What we want
   to do is, in general, rather independent of the system we are dealing
   with as far as the protocol is concerned, and we should not fail to
   introduce general notions into the protocol just because we are unc-
   ertain as to how they may have to be translated into particular
   implementation practice.

残念ながら、洗練されます。 MULTICSはそれを作るかもしれません。 Naytheless、それがそうしたいと思うものがそうするのが明確である(protoあん部が反映するべきであることです)ことを願って、かなり特定のHOSTシステムの文脈でどうそれをすることになっているかに関するそれと異なった質問がありますか? プロトコルに関する限り、一般に、したいと思うことは私たちが対処しているシステムからかなり独立しています、そして、私たちはまさしくそれらがどう特定の実装習慣に翻訳されなければならないかもしれないかに関するunc- ertainであるので必ず一般的な概念をプロトコルに取り入れるべきです。

   A PDP-10 IMPLEMENTATION

PDP-10実装

   Although the following can be implemented as either a set of user
   routines or imbedded in the monitor as UUO's (our first implementa-
   tion will be the former), the latter version will be used for
   descriptive purposes.  The UUO's would be:

以下はそうすることができますが、1セットのユーザ・ルーチンとして実装されるかUUOのものとしてモニターで埋め込まれてください、そして、(私たちの最初のimplementa- tionは前者になるでしょう)後者のバージョンは描写的である目的に使用されるでしょう。 UUOのものは以下の通りでしょう。

        PUTF    CH, E   Put flag

PUTF CH、E Putは弛みます。

        PUTD    CH, E   Put data

PUTD CH、E Putデータ

        PUT     CH, E   Put record

PUT CH、E Putは記録します。

        GETFD   CH, E   Get flag or data

GETFD CH、E Get旗またはデータ

        GET     CH, E   Get record

GET CH、E Getは記録します。

   In the above, "CH" is the logical channel number.  The customary OPEN
   or INIT UUO is used to open the channel.  Standard format user
   buffers are assigned.  However, the ring and buffer headers will be
   used in a nonstandard way, so that data mode 12 is assigned for use
   with Network buffering and file status bit 31 must be on for input.
   (Any of the devices DSK, DTA, MTA, or IMP can be used in this mode.)

上記では、"CH"は論理チャネル番号です。 通例のオープンかINIT UUOが、チャンネルを開けるのに使用されます。 標準書式ユーザバッファは割り当てられます。 しかしながら、リングとバッファヘッダーは標準的でない方法で使用されるでしょう、データモード12が使用のためにNetworkバッファリングで割り当てられて、入力に、ファイルステータスビット31がオンであるに違いないように。 (このモードでデバイスのDSK、DTA、MTA、またはIMPのどれかを使用できます。)

   In the Harvard NCP and HOST-HOST protocol implementation, user
   buffers do not correspond directly to messages.  On output, each user
   buffer will be formatted into a message; on input, a message may
   become one or two user buffer loads (128 word buffers are used in
   order to make maximum use of the facilities of the disk service rou-
   tines).

ハーバードNCPとHOST-HOSTプロトコル実装では、ユーザバッファは直接メッセージと食い違っています。 出力のときに、それぞれのユーザバッファはメッセージにフォーマットされるでしょう。 入力のときに、メッセージは1か2つのユーザバッファ負荷になるかもしれません(128の単語バッファがディスクサービスrouの施設の最大の使用を歯にするのに使用されています)。

Mealy                                                           [Page 7]

RFC 91               A Proposed User-User Protocol         December 1970

提案されたユーザユーザプロトコル1970年12月あたり粉だらけ[7ページ]のRFC91

   PUTF UUO:

PUTF UUO:

      This UUO places a flag into the output buffer.  The effective
      address is the location of a word:

このUUOは出力バッファの中に旗を置きます。 実効アドレスは単語の位置です:

         XWD operation, count

XWD操作、カウント

      In the case of block flags, the count is ignored, since it will be
      computed from the number of bytes actually placed in the buffer
      before the next use of PUTF.  PUTF and PUTD will insert EOM flags
      automatically as each buffer becomes full; if data bytes are
      currently being placed in the buffer by PUTD, it will also insert
      an EOM flag after computing the count for the previous block flag
      in the buffer and place a new block flag of the same type at the
      beginning of the next buffer, after inserting a SIZE flag stating
      the then current byte size.

ブロック旗の場合では、カウントは無視されます、それがPUTFの次の使用の前に実際にバッファに置かれたバイト数から計算されるので。 各バッファが完全になるのに従って、PUTFとPUTDは自動的にEOM旗を挿入するでしょう。 データ・バイトが現在PUTDによってバッファに置かれていると、また、バッファの前のブロック旗のためのカウントを計算した後に、EOM旗を挿入して、同じタイプの新しいブロック旗を次のバッファの始めに置くでしょう、当時の現在のバイトサイズを述べるSIZE旗を挿入した後に。

   PUTD UUO:

PUTD UUO:

      This UUO places data into the output buffer.  The effective
      address is the location of the data byte (if the byte size is less
      than 36) or of the next 36 bit word of data to be placed in the
      buffer.  In the first case, the byte is assumed to be in the low
      order part of the word addresses.  In the second case, the data
      word containing the final bits of the byte contains them in the
      high order part of the word, and the next data byte starts a new
      word in PDP-10 storage.  Thus, for a byte size of 64, two entries
      to PUTD would be used per byte transmitted, the first containing
      36 bits and the second containing 28 bits, left-justified.  This
      strategy allows maximum use of the PDP-10 byte handling instruc-
      tions.

このUUOは出力バッファの中にデータを置きます。 実効アドレスはデータ・バイト(バイトサイズが36未満であるなら)かバッファに置かれるべきデータの次の36ビットの単語の位置です。 前者の場合、バイトが語アドレスの下位の部分にあると思われます。 2番目の場合では、バイトの最終的なビットを含むデータ・ワードは単語の高位部分にそれらを含んでいます、そして、次のデータ・バイトはPDP-10ストレージにおける新しい単語を始めます。 したがって、PUTDへのエントリーは、28ビット64、2のバイトサイズのための、1 1番目が36ビット含んでいて、伝えられたバイト単位で使用されていて2番目の含有することでしょう、左では、正当です。 この戦略はPDP-10バイト取り扱いinstruc- tionsの最大の使用を許します。

   PUT UUO:

UUOを置いてください:

      This UUO places a whole logical record in the output buffer(s).
      The effective address is that of a word:

このUUOは出力バッファの全体の論理レコードを置きます。 実効アドレスは単語のものです:

         IOWD count, location

IOWDカウント、位置

      A PUTF UUO must have been used to output the proper SIZE flag.
      Thereafter, each use of PUT will output a BLOCK flag, [3] simulate
      a number of calls to PUTD using the IOWD to discover the location
      and size of the user data area, and then output a RS flag to indi-
      cate end of record.

PUTF UUOは、適切なSIZE旗を出力するのに使用されたに違いありません。 [3] その後、PUTの各使用はBLOCK旗を出力して、ユーザデータ領域の位置とサイズを発見して、次に、記録のindi美味エンドまでRS旗を出力するのにIOWDを使用することで多くの呼び出しをPUTDにシミュレートしてください。

Mealy                                                           [Page 8]

RFC 91               A Proposed User-User Protocol         December 1970

提案されたユーザユーザプロトコル1970年12月あたり粉だらけ[8ページ]のRFC91

      In the case of byte size of less than 36 bits, PUT will use the
      ILDB instruction to pick up bytes to be output by PUTD.  Hence,
      the standard PDP-10 byte handling format is used, and the count
      part of the IOWD is the total byte count, not word count.

36ビット未満のバイトサイズの場合では、PUTはPUTDで出力になるようにバイトに選ぶILDB指示を使用するでしょう。 したがって、形式を扱う標準のPDP-10バイトは使用されています、そして、IOWDのカウント部分は語の計数ではなく、総バイト・カウントです。

      The above UUO'S have both an error return and a normal return.

上記UUOのものには、誤りリターンと正常復帰の両方があります。

   GETFD UUO:

GETFD UUO:

      The calling sequence for this UUO is:

このUUOのための呼出し手順は以下の通りです。

         GETFD CH, E
         error return
         whyte flag return
         block flag return
         data return

GETFD CH、リターンwhyte旗のリターンブロック旗のリターンデータが返すE誤り

      The effective address is the location at which the flag or data
      will be returned.  The flag is returned in the same format as for
      PUTF and the data in the same format as for PUTD.  Certain flags
      (NUL, IGNORE, and EOM) will be handled entirely within the UUO and
      will not be reported to the user.  SYS should eventually be han-
      dled this way, but initially will be handled by the user.

実効アドレスは旗かデータが返される位置です。 同じ形式におけるPUTFとデータのようにPUTDのように同じ形式で旗を返します。 ある旗(NUL、IGNORE、およびEOM)は、完全にUUOの中で扱われて、ユーザに報告されないでしょう。 SYSは結局このようにhan- dledであるべきですが、初めは、ユーザによって扱われるでしょう。

   GET UUO:

UUOを手に入れてください:

      The calling sequence for this UUO is:

このUUOのための呼出し手順は以下の通りです。

         GET CH, E
         error return
         end of file return
         end of group return
         normal return

GET CH、グループリターン標準のリターンファイルの終りリターン終わりが返すE誤り

      GET transmits the next logical record to the user, using GETFD
      together with an IOWD in the same format as for PUT.  If the IOWD
      count runs out before end of record, the remainder of the record
      will be skipped.  In any case, the updated IOWD will be returned
      at the effective address of the UUO in order to inform the user
      how much data was transmitted or skipped.

GETは次の論理レコードをユーザに伝えます、IOWDと共にPUTのように同じ形式にGETFDを使用して。 IOWDカウントが記録の終わり以前なくなると、記録の残りはスキップされるでしょう。 どのような場合でも、どのくらいのデータが送られたか、またはスキップされたかをユーザに知らせるためにUUOの実効アドレスでアップデートされたIOWDを返すでしょう。

PDP-10 FILE TRANSMISSION:

PDP-10はトランスミッションをファイルします:

   Assume that I have a link connected to another PDP-10 and a user
   process there that is listening.  In order to get that process to
   send me a file, the sequence of flags that might be transmitted can

私が聴かれている別のPDP-10とそこのユーザ・プロセスにリンクを接続させると仮定してください。 そのプロセスにファイルを私に送らせるように、送られるかもしれない旗の系列はさせることができます。

Mealy                                                           [Page 9]

RFC 91               A Proposed User-User Protocol         December 1970

提案されたユーザユーザプロトコル1970年12月あたり粉だらけ[9ページ]のRFC91

   be represented as follows, where the UUO'S executed by me are in the
   left margin, the flags are indented, and the commentary opposite them
   indicates the nature of the data block transmitted:

以下の通り表されてください、実行されたUUOのものが私による左のマージンにおいてそうであり、旗がギザギザを付けられて、それらの反対側の論評が、データ・ブロックの本質が伝わったのを示すところで:

   PUT F
        CONTROL   Data with OPEN parameters, requesting OPEN
        LABEL     File identification data for LOOKUP
        EOM       Forces message to be transmitted

伝えられるべきLOOKUP EOM ForcesメッセージのためのオープンLABEL File識別情報を要求するオープンパラメタがあるPUT F CONTROL Data

   GETFD
        STATUS    Status returned by OPEN
        SIZE      Byte size to be used
        LABEL     File retrieval information

オープンSIZE Byteサイズに応じてGETFD STATUS Statusは戻って、中古のLABEL File検索情報になりました。

   PUTF
        CONTROL   Data requesting INPUT from file
        EOM       Forces request to be transmitted

EOM Forcesが伝えられるよう要求するファイルからINPUTを要求するPUTF CONTROL Data

   GETFD
        STATUS    Status bits returned by INPUT

INPUTによって返されたGETFD STATUS Statusビット

   GET            Logical record (one file buffer load)
        (loop back to second PUTF, above, for other records)

GET Logical記録(1つのファイルバッファ負荷)(他の記録のための上の第2PUTFへのループバック)

   Finally, the status information returned by the second GETF indicates
   end of file, and I wind up with the sequence:

最終的に、第2GETFによって返された状態情報はファイルの終りを示します、そして、私は系列で終わります:

   PUTF
        CONTROL   Data requesting a CLOSE
        EOM       Forces transmission

CLOSE EOM Forcesトランスミッションを要求するPUTF CONTROL Data

   GETFD
        STATUS    Status bits returned by CLOSE

CLOSEによって返されたGETFD STATUS Statusビット

   In the case I am getting a file, the main loop looks like:

メイン輪は、場合では、私がファイルを手に入れているように見えます:

   PUTF
        CONTROL   Data requesting OUTPUT

OUTPUTを要求するPUTF CONTROL Data

   PUT            Logical record (one file buffer load)

PUT Logical記録(1つのファイルバッファ負荷)

   PUTF
        EOM       Forces transmission

PUTF EOM Forcesトランスミッション

   GETFD
        STATUS    Status bits returned by OUTPUT

OUTPUTによって返されたGETFD STATUS Statusビット

Mealy                                                          [Page 10]

RFC 91               A Proposed User-User Protocol         December 1970

提案されたユーザユーザプロトコル1970年12月あたり粉だらけ[10ページ]のRFC91

   The use of both the record and the flag transmission UUO's is worth
   noting, as well as the use of the EOM flag to force transmission of a
   message when switching between input and output over the link.  PUT
   and GET UUO's are clearly required above for transmission of the CON-
   TROL and LABEL data; I suppressed them for the sake of clarity.

記録と旗のトランスミッションUUOの両方の使用はEOM旗の使用と同様にリンクの上に入出力を切り換えるとき、メッセージの伝達を強制するために注意する価値があります。 PUTとGET UUOのものがCON- TROLとLABELデータの伝達に上で明確に必要です。 私は明快のためにそれらを抑圧しました。

   For this application, the handshaking nature of the transmission of
   CONTROL and STATUS flags are mandatory.  While the protocol would
   permit transmission of a complete file without the handshaking, it
   would be an all or nothing proposition - a single error would neces-
   sitate doing it all over again, presuming that the receiving process
   did not end up in a complete tangle.

このアプリケーションに、CONTROLとSTATUS旗のトランスミッションのハンドシェイク本質は義務的です。 プロトコルがハンドシェイクなしで完全なファイルの伝達を可能にしているだろうという間、それが可能にするだろう、すべてか無、提案--ただ一つの誤りは受信プロセスが完全なもつれで終わらなかったと推定して、もう一度それをするneces- sitateがそうするでしょう。

   BRIEF DISCUSSION:

議論に事情を知らせてください:

   The PDP-10 space required to implement the above protocol is about
   400 instructions, divided equally between the input and the output
   side.  Enough experimental coding has been done to confirm the feasi-
   bility of this basic strategy, taken together with experience with
   implementation and use of the SOS buffering system.

スペースが上のプロトコルを実行するのを必要としたPDP-10は入力とアウトプット側の間で等しく分割されたおよそ400の指示です。 実現の経験と共に取られたこの基本戦略のfeasi- bilityとシステムをバッファリングするSOSの使用を確認するほど実験的なコード化をしました。

   The above does not touch the question of LOGON protocol, except
   indirectly.  My belief is that it can be accommodated in the frame-
   work of this proposal, but I have not tested this theory as yet.  As
   indicated further above, I would be tempted to handle the matter with
   the SYS flag, given that SYS data is interpreted directly by the sys-
   tem (in our system, we would use the RUN UUO to run the LOGON CUSP,
   which would, in turn handshake using ASCII data over the link).  In
   this way, I think we might be able to dispense with the notion of
   dedicated sockets and the reconnection morass.

上は間接的にLOGONプロトコルの問題に触れていません。 私の信念はこの提案のフレーム仕事でそれを設備することができるということですが、私はまだこの理論をテストしていません。 上でさらに示されるように私がSYS旗の問題を扱うように誘惑されるでしょう、SYSデータが直接sys- temによって解釈されるなら。(システムでは、私たちがLOGON CUSPを走らせるそうするだろうRUN UUOを使用するだろう、順番に、リンクの上にASCIIデータを使用する握手) このように、私は、私たちが専用ソケットの概念と再接続沼地を省くことができるかもしれないと思います。

   One other point that needs thought is the question of how to handle
   the interrupt on link facility.  Should it have any direct relation
   to the GET/PUT UUO's, or be handled on the side?  I am inclined to
   think that it should be treated _qua_ interrupt of the user process,
   quite independently of the matter of data transmission over the link.
   Some of our current work on the PDP-10 monitor would lend itself
   rather easily to implementation as a true interrupt.

考えを必要とする他の1ポイントはリンク施設の上のどう中断を扱うかに関する問題です。 それは、何かダイレクト関係をGET/PUT UUOのものに持つべきですか、または側で扱われるべきですか? 私はそれが_ユーザ・プロセスの中断資格で扱われた_であると思う傾向があります、全くリンクの上のデータ伝送の問題の如何にかかわらず。 PDP-10モニターへの私たちの執筆中の作品のいくつかが本当の中断としてかなり容易にそれ自体を実現に与えるでしょう。

   ENDNOTES*

エンドノート*

   1.  A message is that string of bits between any two HOST-HOST
   headers.

1. メッセージはどんな2個のHOST-HOSTヘッダーの間のビットのそのストリングです。

   2.  In memory of an attractive, but nonspelling, SDC secretary who
   could not distinguish between black and white, at least during 1957
   and in manuscript form.

2. 白黒を見分けることができなかった魅力的な、しかし、「非-つづ」っているSDC秘書の思い出、少なくとも1957、および原稿では、形成してください。

Mealy                                                          [Page 11]

RFC 91               A Proposed User-User Protocol         December 1970

提案されたユーザユーザプロトコル1970年12月あたり粉だらけ[11ページ]のRFC91

   3.  PUTF may be used to ouput the block flag, if a different from
   BLOCK is required.

3. BLOCKと異なったaが必要であるなら、PUTFは、ブロック旗をouputするのに使用されるかもしれません。

         [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by Colin Barrett  9/97   ]

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

Mealy                                                          [Page 12]

粉だらけ[12ページ]