RFC133 日本語訳

Network Working Group                                      R. L. Sunberg
Request for Comments: 133                             Harvard University
NIC 6710                                                   27 April 1971
[Categories C.4, C.5, C.6, D.4, D.7, D.7]

L.Sunbergがコメントのために要求するワーキンググループR.をネットワークでつないでください: 133 ハーバード大学NIC6710 1971年4月27日[カテゴリC.4、C.5、C.6、D.4、D.7、D.7]

                    FILE TRANSFER AND ERROR RECOVERY

ファイル転送ANDエラー回復

1   FILE TRANSFER PROTOCOL

1 ファイル転送プロトコル

1A   Handshaking

1Aハンドシェイク

   I think that Mr Bhushan(RFC #114, NIC 5823) is not strict enough in
   his concept of a transaction sequence.  Every transaction should
   prompt a response from its recipient (recall Kalin's crates --
   RFC #60, NIC 4762).  Control should pass back and forth until the
   server terminates.  The server _always_ gets the last word (more on
   error recovery later).

私は、Bhushanさん(RFC#114、NIC5823)が彼のトランザクション系列の概念で十分厳しくないと思います。 あらゆるトランザクションが受取人(リコールKalinのかご--RFC#60、NIC4762)から応答をうながすべきです。 サーバが終わるまで、コントロールは前後に通るはずです。 いつも_が締め括りの言葉(さらに後でのエラー回復の)を得るサーバ_。

   Some sample interchanges are given.

いくつかのサンプル置き換えを与えます。

       User                Server       Comments

ユーザサーバコメント

       <...>       ==>                  Establish a connection
                   <==     <...>
       <I><...>    ==>                  Identify self
                   <==     <+>          Ok, ready

<…>=>は接続<=<を設立します…><I><…>=>は<+>Okで、準備ができていた状態で自己<=を特定します。

       <R><...>    ==>                  Retrieval request
                   <==     <rs>         I've got your file
       <rr>        ==>                  Send it
                   <==     <,><...>     Here's the first part
       <rr>        ==>                  Got it
                   <==     <+>          All done

<R><…>=私が>あなたのファイル<rr>=Sendを手に入れた<rs>検索要求<=>、それ、<=<、><…ここの>が最初のパート<rr>=>Gotである、それ、行われた<+><=All

       <S><...>    ==>                  Store request
                   <==     <rr>         Ok, go ahead
       <#><...>    ==>                  Here's some protection stuff
                   <==     <rr>         Ok
       <*><...>    ==>                  Here's the file
                   <==     <+>          Got it.  All done.

<S><…>=>は<rr>要求<=Okを保存して、先の碁は<#><です…>=ここの>はいくつかの保護ものの<=<rr>Ok<*><です…>=ここの>による<+>ファイル<=Gotです。それ。 行われたすべて。

   See section 2B, below, for examples of error recovery.

以下でエラー回復の例に関してセクション2Bを見てください。

Sunberg                                                         [Page 1]

RFC 133             File Transfer and Error Recovery          April 1971

Sunberg[1ページ]RFC133ファイル転送とエラー回復1971年4月

1B  Extensions to the file transfer protocol

ファイル転送プロトコルへの1B拡張子

   The file transfer protocol needs a mechanism for accessing individual
   records of a file.  This will be particularly useful when very large
   data bases appear on the network.  The following definitions should
   be added to the protocol:

ファイル転送プロトコルはファイルの個々の記録にアクセスするのにメカニズムを必要とします。 非常に大きいデータベースがネットワークに現れるとき、これは特に役に立ちます。 以下の定義はプロトコルに追加されるべきです:

   The store(S) and retrieve(R) requests have the data field format
   <key>, where <key> has the syntax:

(S)を保存してください、そして、(R)を検索してください。(そこでは、<の主要な>が構文を持っています)。要求には、データフィールド形式の<の主要な>があります:

    <key>::=<devicename>RS<filename>US<keyname> | <filename>US<keyname>.
                           --          --                      --

<の主要な>:、:=<devicename>RS<ファイル名>米国<keyname>。| <ファイル名>米国<keyname>。 -- -- --

   The <pathname> syntax is changed to:

以下のことのために<パス名>構文を変えます。

       <pathname>::=<devicename> | <filename> | <pathname>RS<filename>.
                                                          --
   If a retrieve(R) request is given with a data field with <key>
   syntax rather than <pathname> syntax, then the returned data will
   consist of the record following the matching <key>.  If a store(S)
   request is given with a data field of <key> syntax, then the
   supplied data will replace the record following the matching
   <keyname>.  If the keyname does not exist, the record will be
   appended to the named file.  The individual installation must
   provide the linkage between the <keyname> and the record it
   references.

<パス名>:、:=<devicename>。| <ファイル名>。| <パス名>RS<ファイル名>。 -- aが(R) 要求を検索するなら、当然のことが<パス名>構文よりむしろ<の主要な>構文があるデータ・フィールドと共にあって、次に、返されたデータは合っている<主要な>に続く記録から成るでしょう。 <の主要な>構文のデータ・フィールドと共に店(S)要求を与えると、合っている<keyname>に続いて、供給されたデータは記録を置き換えるでしょう。 keynameが存在していないと、指定されたファイルに記録を追加するでしょう。 個々のインストールは<keyname>とそれが参照をつける記録の間のリンケージを供給しなければなりません。

   In addition, the lookup(L) request will provide a list of keynames
   into a file (or the name of a file which contains the keynames).

さらに、ルックアップ(L)要求はファイル(または、keynamesを入れてあるファイルの名前)の中にkeynamesのリストを供給するでしょう。

   Transaction code F (request File directory) requests a listing of
   available files.  The data field of the F transaction is of the
   form:  <pathname>GS<pathname>GS...  All files in the server system
                    --          --
   which match one or more of the given <pathname> specifiers are
   listed in a return file.  The format of the data fields of this
   file is:  <pathname>GS<pathname>GS...  If a <pathname> field in
                       --          --
   the request transaction does not include a <name> field, the
   default is all files on the given device.  Some examples are given:

トランザクション・コードF(Fileディレクトリを要求します)は利用可能なファイルのリストを要求します。 Fトランザクションのデータ・フィールドはフォームのものです: <パス名>GS<パス名>GS… サーバシステムのすべてのファイル----どれが1つに合っているか、そして、一層の与えられた<パス名>特許説明書の作成書がリターンファイルに記載されています。 このファイルのデータ・フィールドの形式は以下の通りです。 <パス名>GS<パス名>GS… <パス名>であるならコネをさばいてください。----要求トランザクションは<名前>分野を含まないで、デフォルトはすべて、与えられたデバイスのファイルです。 いくつかの例が出されます:

       <F><DC1 DSK[62,50]] GS JOE>
           ---             --

<F><DC1 DSK[62、50] GSジョー>。--- --

Sunberg                                                         [Page 2]

RFC 133             File Transfer and Error Recovery          April 1971

Sunberg[2ページ]RFC133ファイル転送とエラー回復1971年4月

   This example requests a list of all files on the disk specified by
   [62,50] plus all files named JOE.  The response could contain in
   the data field:

この例は[62、50]時までに指定されたディスクの上のすべてのファイルのリストとJOEというすべてのファイルを要求します。 応答はデータ・フィールドに以下を保管するかもしれません。

     <DC1 DSK[62,50] RS ALPHA RS BETA RS JOE GS DC1 DSK[10,50] RS JOE>
      ---            --       --      --     -- ---            --

<DC1 DSK[62、50]RSアルファRSベータRSジョーGS DC1 DSK[10、50]RSジョー>。--- -- -- -- -- --- --

   This message states that in the [62,50] area of the disk there are
   files ALPHA, BETA, and JOE, and that JOE is also a file in the
   [10,50] area of the disk.

このメッセージは[62、50]ではあるディスクの領域がアルファー、BETA、およびJOEをファイルして、また、JOEがディスクの[10、50]領域のファイルであると述べます。

2   ERROR RECOVERY

2エラー回復

2A   Error recovery procedures have been noticeably lacking to date.
   The usual approach has been to close the connection and start from
   scratch.  Mr Bhushan proposes a third level abort but doesn't
   really detail the implementation.  I propose a multilevel error
   recovery procedure as follows.

2A Errorリカバリ手順はこれまで顕著に欠けていたことです。 普通のアプローチは、接続を終えて、最初から始まることです。 Bhushanさんは、3番目の平らなアボートを提案しますが、本当に実装を詳しく述べません。 私は以下の多レベルエラー回復手順を提案します。

2B   If an error occurs which does not cause a loss of third level
   transaction boundaries and only affects one side of a duplex
   connection, a third level recovery is possible via a transaction
   sequence abort.  An example is given:

3番目の平らなトランザクション境界の損失を引き起こさないで、重複の接続、3番目の平らな回復の半面に影響するだけである誤りが発生するなら、2Bはトランザクション系列アボートで可能です。 例は出されます:

       User                Server          Comments

ユーザサーバコメント

       <R><...>    ==>                     Send me this file
                   <==     <rs>            Ok, I've got it
       <rr>        ==>                     Ready
                   <==     <*><...error>   Here it is (with an error)
       <-><D>      ==>                     No.  (data) error
                   <==     <-><D>          Sorry, forget it
       <R><...>    ==>                     Send the file (again)
                   |<==    <rs>            Ready (doesn't get there)
                   ...                     (waiting)
       <-><0>      ==>                     Error, timeout
                   <==     <-><0>          Sorry, forget it
       <R><...>    ==>                     Send the file (third time)
                   <==     <rs>            Got it
       <rr>        ==>                     Ready
                   <==     <*><...>        There it is
       <rr>        ==>                     Got it
                   <==     <+>             Done (finally>

<R><…>=>はこのファイル<=<rs>Okを私に送って、私は<*>>Ready<rr>=<=<をそれに手に入れました…誤り>Here、それは>(誤りがある)<-><D>=No.です。 (データ) 誤り<=<->、<D>、すみません、それを忘れてください、<R><…>=>は(再び)ファイルを送ります。|<= <rs>Ready(そこに到着しません)… (待ち) <。<><0>誤り、タイムアウト><0>=<=>、すみません、それを忘れてください、<R><…>=>が<rs>ファイル(3番目に、調節する)<=Gotを送る、それ、>Ready<<rr>==<*><…>、それがそこでは、><rr>=Gotである、それ、<+><=Done、(最終的に>。

   Note that the server always gets the last word in error situations
   as well as normal transmission.

サーバがいつも通常のトランスミッションと同様にエラー状態における締め括りの言葉を得ることに注意してください。

Sunberg                                                         [Page 3]

RFC 133             File Transfer and Error Recovery          April 1971

Sunberg[3ページ]RFC133ファイル転送とエラー回復1971年4月

2C   Although the above examples are given in terms of Bhushan's
   transaction codes, this form of error recovery is implementable in
   any protocol which uses flagged blocking and duplex connections.

上記の例はBhushanのトランザクション・コードで出されますが、このフォームのエラー回復は旗を揚げさせられたブロッキングと重複の接続を使用するどんなプロトコルでも2C、実装可能です。

2D   If errors cannot be recovered as above, then some means must be
   available to clear the link completely and resynchronize.  I
   suggest that an 8-bit argument be appended to the interrupt-on-link
   NCP message (INR, INS).  The receiver would send <INR><error> to
   indicate that the block boundaries were lost and all incoming data
   is being discarded.  The sender, upon receiving the INR, would
   flush all queued output and wait for the link to clear.  The NCP
   would then send a <INS><newsync> message and, when it was received
   (RFNM returned), a negative termination would be sent on the link.
   The receiver begins accepting data again when the INS is received.
   This assumes that any process can flush untransmitted data and
   detect a clear link.  Note that this method is useable on any
   simplex connection.

次に、いくつかの手段がリンクを完全にきれいにして、再連動するように上で入手できなければならないとき、2D If誤りを回復できません。 私は、8ビットの議論がリンクにおける中断NCPメッセージ(INR、INS)に追加されることを提案します。 受信機は、ブロック境界が失われて、すべての受信データが捨てられているのを示すために<INR><誤り>を送るでしょう。 INRを受けるとき、送付者は、すべての列に並ばせられた出力を洗い流して、リンクがきれいにされるのを待つでしょう。 次に、NCPは<INS><newsync>メッセージを送るでしょう、そして、それを受け取ったとき(RFNMは戻りました)、否定的終了をリンクに送るでしょう。 INSが受け取られているとき、受信機は再びデータを受け入れ始めます。 これは、どんなプロセスも「非-伝え」られたデータを洗い流して、明確な関連を検出できると仮定します。 このメソッドがどんなシンプレクス接続のときにもuseableであることに注意してください。

2E  If all else fails, one can resort to closing the faulty socket.

人は、不完全なソケットを閉じながら、すべてほかなら2Eが失敗するのを当てにすることができます。

3   NCP VERSION NUMBERS

3 NCPバージョン番号

3A  I suggest that the NCP be given a version number and the next
   version include two new message types: <WRU> ('Who aRe yoU?')
   requests a version number from the receiving host and <IAM><version>
   ('I AM') supplies that number.

3A Iは、NCPがバージョン番号と次のバージョンが2つの新しいメッセージタイプを含んでいるという当然のことであると示唆します: <WRU>、('、だれ、aRe yoU?、'、)、受信ホストと<IAM><バージョン>('I AM')からのバージョン番号がその数を供給する要求。

3B  The messages would probably be initially used in a 'can I talk to
   you?' sense or not at all.  Eventually, it would take on a 'what
   can you do?' meaning.  Accordingly, the <version> field should be
   large (32 bits?) for expansion.

3B、メッセージは初めは、たぶん'私はあなたと話してもよいですか?'意味か全く使用されないでしょう。 結局、それは'あなたは何ができますか?'意味を帯びるでしょう。 それに従って、拡張には、<バージョン>分野は大きいはずです(32ビット?)。

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

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

Sunberg                                                         [Page 4]

Sunberg[4ページ]