RFC281 日本語訳
0281 Suggested addition to File Transfer Protocol. A.M. McKenzie. December 1971. (Format: TXT=12006 bytes) (Updates RFC0265) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. McKenzie Request for Comment: 281 BBN NIC: 8163 8 December 1971 Category: D.7 Reference: RFC #264, #265
コメントを求めるワーキンググループA.マッケンジー要求をネットワークでつないでください: 281BBN NIC: 8163年の1971年12月8日のカテゴリ: D.7参照: RFC#264、#265
A suggested Addition to File Transfer Protocol
File Transferプロトコルへの提案されたAddition
On November 16, an informal meeting was held at UCLA to discuss prospects for a network standard Remote Job Service (RJS) protocol. In attendance were representatives of UCLA-CCN and UCSB, the network's only current RJS sites, as well as UCLA-NMC and the BBN network project. A report on that discussion will be published as an RFC shortly and will not be discussed here. In thinking about the use of the proposed File Transfer Protocol (FTP) (RFC #265) for RJS, however, we came to the conclusion that a "restart" procedure might be an extremely useful addition to the FTP.
11月16日に、非公式会議が、ネットワーク標準のRemote Job Service(RJS)プロトコルの見通しについて議論するためにUCLAで行われました。 ネットワークのUCLA-CCN、UCSB、唯一の現在のRJSサイト、およびUCLA-NMCの代表とBBNネットワークプロジェクトが付き添っていました。 その議論に関するレポートについて、まもなく、RFCとして発表されて、ここで議論しないでしょう。 しかしながら、提案されたFile Transferプロトコル(FTP)(RFC#265)のRJSの使用について考える際に、私たちは「再開」手順が非常に役に立つ追加であるかもしれないという結論にFTPに達しました。
Many, perhaps most, of the individuals involved in protocol design thus far are oriented toward the use of short date transmissions over the network the transmission lengths that have been considered "typical" are a few characters, a print line, or perhaps as much as a page of text. The experience of the current RJS sites, however, is that single files are commonly much longer, for example a line-printer output file of 400 pages would not seem unusual to these sites. Further, one might reasonably predict that network use of Remote Job Services will be preselected with a tendency toward large jobs (although large jobs do not necessarily imply large I/O files) and that the addition of other batch service sites (ILLIAC, UCSD) will increase the number of long-file transfers. In light of this kind of experience/prediction, it would seem that the FTP should include (perhaps as an option which interactive-user oriented systems could ignore) a method of "restarting" a long file transfer if some element in the transmission path fails after a large volume of data has been transferred.
多くです、ネットワークの上の短期の送信の使用に向かったこれまでのところ適応したプロトコルデザインにかかわった個人では、「典型的である」と考えられたトランスミッションの長さは、恐らく、テキストのいくつかのキャラクタ、印刷系列、または最大恐らく1最もページです。 しかしながら、現在のRJSサイトの経験がただ一つのファイルが一般的にはるかに長いということである、例えば、400ページのラインプリンタ出力ファイルはこれらのサイトに珍しく見えないでしょう。 さらに、人は、Remote Job Servicesのネットワーク使用が大きい仕事に向かった傾向で前選択されて(大きい仕事が必ず大きい入出力ファイルを含意するというわけではありませんが)、他のバッチサービスサイト(ILLIAC、UCSD)の追加が長いファイル転送の数を増強すると合理的に予測するかもしれません。 この種類の経験/予測の観点から、FTPが多くのデータを移した後にトランスミッション経路の何らかの要素が失敗するなら長いファイル転送の「再開」であるメソッドを含むべきであるように(恐らく対話的なユーザの指向のシステムが無視できたオプションとして)思えるでしょう。
The critical element in a "restart" procedure is the ability to arrange agreement between both ends of the transmission path as to where, exactly, the retransmission should begin. There are two potential candidates for marking possible restart locations already built into the proposed Data Transfer Protocol (RFC #264) which underlies the FTP; these are:
「再開」手順による重要な要素はちょうど「再-トランスミッション」が始まるはずであるところに関してトランスミッション経路の両端の間の協定をアレンジする能力です。 可能なFTPの基礎となる提案されたData Transferプロトコル(RFC#264)が既に組み込まれた再開位置を示す2人の有力候補がいます。 これらは以下の通りです。
a) The "information separators" (transaction type B4) which are
available in both "transparent block" transfers and "descriptor
and counts" transfers, and
a) そして「見え透いたブロック」転送と「記述子とカウント」の両方で利用可能な「情報分離」(トランザクションタイプB4)が移される。
McKenzie [Page 1] RFC 281 A Suggested Addition to File Transfer ProtocolDecember 1971
ファイル転送ProtocolDecember1971への提案された追加あたりマッケンジー[1ページ]RFC281
b) The "sequence numbers" which can be used with the "descriptor
and counts" transfer mode.
b) 「記述子とカウント」と共に使用できる「一連番号」はモードを移します。
McKenzie [Page 2] RFC 281 A Suggested Addition to File Transfer ProtocolDecember 1971
ファイル転送ProtocolDecember1971への提案された追加あたりマッケンジー[2ページ]RFC281
After some discussion, we seemed to agree that the "information separators" (as they would be used in "transparent block" transfer mode, i.e., without "sequence numbers") were unlikely to serve as UNAMBIGUOUS restart location marker, and therefore we suggest the use of "sequence numbers" as markers. We were aware of the fact that this choice might exclude TIPs and other Hosts which do not use sequence numbering from the type of recovery under discussion; we believe, however, that our suggestion eliminates at least some of this problem.
何らかの議論の後に、私たちは、UNAMBIGUOUSが位置のマーカーを再出発するので「情報分離」(それらがすなわち、「見え透いたブロック」転送モード、「一連番号」なしで使用されるだろうというとき)が役立ちそうになくて、したがって、私たちがマーカーとして「一連番号」の使用を勧めるのに同意するように思えました。 私たちはこの選択が議論で回復のタイプからの系列付番を使用しないTIPsと他のHostsを除くかもしれないという事実を知っていました。 しかしながら、私たちは、私たちの提案が少なくともこの問題のいくつかを解決すると信じています。
Imagine that some site, which we will call the "user site" or "user", has initiated a connection from its own file transfer process to a file transfer process at some other site, which we will call the "server site" or "server". After the appropriate exchanges of information, a file transfer (using the File Transfer Protocol) begins over the path between these two sites. After some information is transferred, the path between the user and server is broken. At some later time the user initiates a new connection between the file transfer processes at user and server, establishes relevant access privileges, and wishes to resume the transmission which was in progress when the path was broken. First we describe four new op- codes for the File Transfer Protocol:
何らかのサイト(私たちは「ユーザの現場かユーザ」と呼ぶつもりである)が私たちが「サーバサイトかサーバ」と呼ぶつもりであるある他のサイトでのそれ自身のファイル転送プロセスからファイル転送プロセスまでの関係を開始したと想像してください。 情報の適切な交換の後に、ファイル転送(File Transferプロトコルを使用する)はこれらの2つのサイトの間の経路の上で始まります。 何らかの情報がわたっていた後に、ユーザとサーバの間の経路は起伏が多いです。 何らかの後の時間に、ユーザは、ユーザとサーバでファイル転送プロセスの間の新しい接続を開始して、関連アクセス権を確立して、経路が起伏が多かったときに進行していたトランスミッションを再開したがっています。 まず最初に、私たちはFile Transferプロトコルのために4つの新しいオプアートコードについて説明します:
Hex Operation --- --------- 10 Append at sequence number
十六進法操作--- --------- 10は一連番号で追加します。
This command is essentially the same as any of the "Store"
or "Append..." commands except that a 16-bit sequence
number immediately follows the op-code (before the
pathname).
このコマンドは16ビットの一連番号がすぐに演算コード(パス名の前の)に従うのを除いて、「ストア」か「追加」のどれかが命令するのと…本質的には同じです。
11 Retrieve at sequence number
11は一連番号で検索します。
This is the same as the "Retrieve"command except that a
16-bit sequence number immediately follows the op-code
(before the pathname).
16ビットの一連番号がすぐに演算コード(パス名の前の)に従うのを除いて、これは「検索」コマンドと同じです。
12 Resume Retrieve
履歴書が検索する12
To be used when the user wishes the server to choose the
sequence number; in other respects this is identical to
the "Retrieve" command.
ユーザが一連番号を選ぶためにサーバを願っているとき、使用されるために。 その他の点ではこれは「検索」コマンドと同じです。
McKenzie [Page 3] RFC 281 A Suggested Addition to File Transfer ProtocolDecember 1971
ファイル転送ProtocolDecember1971への提案された追加あたりマッケンジー[3ページ]RFC281
13 Use the sequence number
13は一連番号を使用します。
This command contains only the op-code and a 16-bit
sequence number. It is intended as a denial of the
ability to locate the sequence number given in an "Append
at sequence number" or "Retrieve at sequence number"
command and, simultaneously, to suggest another number
which can be located.
このコマンドは演算コードと16ビットの一連番号だけを含んでいます。 または、中に与えられた一連番号の場所を見つける能力の否定として意図する、「一連番号での追加」、「一連番号で」 コマンドを検索してください、そして、同時に、そうすることができるもう1つの数を示すために、位置してください。
There are several possible cases which are shown below. The user site is always presumed to be the site at the left of the page.
以下で見せられる数個の可能なケースがあります。 ユーザの現場はページ左側あえていつもサイトです。
McKenzie [Page 4] RFC 281 A Suggested Addition to File Transfer ProtocolDecember 1971
ファイル転送ProtocolDecember1971への提案された追加あたりマッケンジー[4ページ]RFC281
A. User site sending at time path is broken:
/
/ Append at sequence number
| ------------------------------------------->
| Acknowledge
| <------------------------------------------
| Data
| ------------------------------------------->
|
\ The server site agrees to resume at the user-chosen point.
\ The first data transaction is numbered with the chosen
\ sequence number.
時間経路で発信するA.ユーザの現場は起伏が多いです: /が一連番号で追加する/| ------------------------------------------->| 承認します。| <------------------------------------------ | データ| ------------------------------------------->| サーバサイトがユーザによって選ばれたポイントで再開するのに同意する\。 \、最初のデータトランザクションは選ばれた\一連番号で付番されます。
/ Append at sequence number
/ ------------------------------------------->
| Unsuccessful Terminate
| <-------------------------------------------
|
\ The server site will never permit restart for some reason
\ (seq. #s were ignored or not used initially, seq #s were not
\ stored with the file, the file was lost when the path was
\broken, etc.)
/は一連番号で/を追加します。------------------------------------------->| 失敗、終わり| <------------------------------------------- | サーバサイトがいくつかの理由\のための再開を決して可能にしない\(seq。 #seq#sがファイルで保存された\でない、sは、無視されたか、または初めは使用されないで、経路が壊された\であったのなどときに、ファイルは失われました。)
/ Append at sequence number
/ ------------------------------------------->
| Use this sequence number
| <-------------------------------------------
| / Data
| / --------------------------------->
| \ The user site agrees to use the server-chosen number
| \ and the first data transaction is numbered with the
| \ chosen number.
|
| or
|
| / Unsuccessful Terminate
\ / ------------------------------->
\ \ The user site cannot restart at this number for
\ \ some reason.
/は一連番号で/を追加します。------------------------------------------->| この一連番号を使用してください。| <------------------------------------------- | /データ| / --------------------------------->| ユーザの現場が同意する\はサーバで選ばれた数を使用します。| \とトランザクションが付番される最初のデータ| 数が選ばれた\。 | | または| | /失敗、\/を終えてください。-------------------------------ユーザの現場が或るものが推論する\\のこの数で再開できない>\\。
McKenzie [Page 5] RFC 281 A Suggested Addition to File Transfer ProtocolDecember 1971
ファイル転送ProtocolDecember1971への提案された追加あたりマッケンジー[5ページ]RFC281
B. User site receiving at time path is broken, and the user site does not particularly care about the exact sequence number (for example, if the user site is sending the file to a printer, some duplicate pages are probably acceptable and the user site would probably not want to remember sequence numbers).
時間経路で受信されるB.ユーザの現場は起伏が多いです、そして、ユーザの現場は特に完全系列番号を心配しません(例えば、ユーザの現場がファイルをプリンタに送るなら、いくつかの写しページがたぶん許容できます、そして、ユーザの現場はたぶん一連番号を覚えていたがっていないでしょう)。
/ Resume Retrieve
/ ------------------------------------>
| Data
| <------------------------------------
| The server picks some point and begins transmission at
| that point. If sequence numbers were used during the
| original transmission, then the first transaction of
| this transmission must exactly match (including
| sequence number) some transaction of the original
\ transmission.
/履歴書は/を検索します。------------------------------------>| データ| <------------------------------------ | 或るものが指して、トランスミッションを始めるサーバ選択| そのポイント。 一連番号は使用されました。| そして、オリジナルのトランスミッション、最初のトランザクション| このトランスミッションはまさにオリジナルの\トランスミッションの何らかのトランザクションに合わなければなりません(包含| 一連番号)。
/ Resume Retrieve
/ ------------------------------------>
| Unsuccessful Terminate
\ <------------------------------------
\ The server site is unable or unwilling to restart the
\ transmission.
/履歴書は/を検索します。------------------------------------>| 失敗、\<を終えてください。------------------------------------ サーバサイトが不本意である\は\トランスミッションを再開します。
McKenzie [Page 6] RFC 281 A Suggested Addition to File Transfer ProtocolDecember 1971
ファイル転送ProtocolDecember1971への提案された追加あたりマッケンジー[6ページ]RFC281
C. User site receiving at time path is broken, and does care about the value of the sequence number.
時間経路で受信されるC.ユーザの現場は、壊れて、一連番号の値を心配します。
/ Retrieve at sequence number
/ ---------------------------------------->
| Data
| <----------------------------------------
\ The server agrees to resume at the user-chosen
\ point. The first data transaction is numbered
\ with the chosen sequence number.
/は一連番号で/を検索します。---------------------------------------->| データ| <---------------------------------------- サーバがユーザによって選ばれた\ポイントで再開するのに同意する\。 最初のデータトランザクションは選ばれた一連番号がある番号付の\です。
/ Retrieve at sequence number
/ ---------------------------------------->
| Unsuccessful Terminate
| <----------------------------------------
|
| The server site will never permit restart for some
| reason.
| Retrieve at sequence number
| ---------------------------------------->
| Use this sequence number
| <-----------------------------------------
| / Acknowledge
| / ---------------------------->
| | Data
| | <----------------------------
| \ The user site agrees to use the
| \ server-chosen number. The first data
| \ transaction is numbered with the chosen
| \ number.
|
| or
|
| / Unsuccessful Terminate
| / ----------------------------->
| |
\ \ The server cannot use the user-chosen
\ \ number and the user cannot use the
\ \ server-chosen number. Therefore the attempt
\ \ to restart must be abandoned.
/は一連番号で/を検索します。---------------------------------------->| 失敗、終わり| <---------------------------------------- | | サーバサイトはいくつかのための再開を決して可能にしないでしょう。| 推論してください。 | 一連番号で、検索します。| ---------------------------------------->| この一連番号を使用してください。| <----------------------------------------- | /は承認します。| / ---------------------------->|、| データ| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| ユーザの現場が使用するのに同意する\| \サーバで選ばれた番号。 最初のデータ| \トランザクションは選ぶことで付番されます。| \番号。 | | または| | /失敗、終わり| / ----------------------------->|、| \\、サーバはユーザによって選ばれた\\番号を使用できないで、ユーザは\\サーバで選ばれた番号を使用できません。 したがって、再開する試み\\を捨てなければなりません。
McKenzie [Page 7] RFC 281 A Suggested Addition to File Transfer ProtocolDecember 1971
ファイル転送ProtocolDecember1971への提案された追加あたりマッケンジー[7ページ]RFC281
Some sites (e.g., UCLA-CCN) have agreed (in principle, at least) to implement these commands and, more important, to store sequence numbers (with files being transferred) on a non-volatile storage medium so that restarts may be effected. This will be done, of course, only if this, or some similar, proposal is accepted by the NWG as part of the File Transfer Protocol. We hope interested parties will communicate comments or counter-proposals to the FTP committee and/or publish their ideas in the RFC series.
いくつかのサイト(例えば、UCLA-CCN)が一致していた、(原則として、少なくとも)、道具に、これらは命令して、それが再開して、店一連番号に非揮発性記憶装置で、より重要な(ファイルを移している)媒体は作用するかもしれません。 これによるこれである場合にだけもちろんいくつかして、同様であることで、提案がFile Transferプロトコルの一部としてNWGによって認められるということでしょう。 私たち望み利害関係者は、コメントか対案をFTP委員会に伝える、そして/または、RFCシリーズで彼らの考えを発表するでしょう。
AAM/jm
AAM/jm
[This RFC was put into machine readable form for entry]
[into the online RFC archives by Kelly Tardif, Viaginie 10/99]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ケリーTardifによるオンラインRFCアーカイブへのViaginie10/99]
McKenzie [Page 8]
マッケンジー[8ページ]
一覧
スポンサーリンク
