RFC269 日本語訳

Network Working Group                                   H. Brodie
Request for Comments #269                               UCLA-NMC
NIC # 7817                                              6 December 71
Categories:  File Transfer
Updates:  122, 238, 172
Obsoletes:  None

コメント#269UCLA-NMC NIC#7817の1971年12月6日のカテゴリを求めるワーキンググループH.飛び込み要求をネットワークでつないでください: ファイル転送アップデート: 122、238、172は以下を時代遅れにします。 なし

                   Some Experience with File Transfer

ファイル転送の何らかの経験

At UCLA-NMC we have recently completed implementation of a program which
utilizes UCSB's storage capability via their Simple Minded File System
(See RFC #122 by Jim White for a description of SMFS).  The use of the
program is detailed in Appendix A.

UCLA-NMCでは、私たちはそれらのSimple Minded File Systemを通してUCSBのストレージ能力を利用するプログラムの最近完成した実装を持っています(ジム・ホワイトはSMFSの記述に関してRFC#122を見てください)。 プログラムの使用はAppendix Aで詳細です。

We learned a number of things in the implementation effort and
subsequent usage.  We think a number of these apply towards the
development of a net- word-wide File Transfer Protocol, and we hope to
stimulate further dis- cussion of these issues.  We discovered some
things in the UCSB protocol that we would like to see included in the
network-wide protocol, and we see some things that are in the currently
proposed net protocol and are unfortunately absent from the UCSB
protocol.

私たちは実装取り組みとその後の用法で多くのことを学びました。 私たちは、これらの数がネットの単語全体のFile Transferプロトコルの開発に向かって適用されると思います、そして、これらの問題の一層の不-cussionを刺激することを望んでいます。 私たちはネットワーク全体のプロトコルに含まれているのを見たいと思うUCSBプロトコルでいくつかのことを発見しました、そして、いくつかの現在提案されたネットのプロトコルにはある、残念ながら、UCSBプロトコルから欠けているものを見ます。

In the first category, is the UCSB file retrieval procedure.  The user
specifies among other things, a bit count of the number of bits to be
retrieved in the current request.

1番目では、カテゴリはUCSBファイル検索手順です。 ユーザは、現在の要求で検索されるためにビットの数のカウントを特に、そして、少し指定します。

Successive RTF commands yield successive pieces of the file.  Portions
of the file can be spaced over by use of the SPF command.  We think that
the ability of the user to specify the size of the "chunks" of the file
he is about to receive, along with the ability to access any part of the
file without having to get the entire file, is definitely an advantage.
It makes the user programs easier to write since the problem of parsing
the input stream virtually disappears, as the user program knows exactly
what to expect at all times.  In addition, the one request, one response
nature of the protocol avoids the problem of sending a request and then
receiving pieces of data of unpredictable size at unknown intervals.
The response to each RTF gives the comforting knowledge that "they're
still listening".  This leads us to believe that there is much to be
gained by the adoption of a one request, one response type of protocol.
We might point out that for any significant file transfer, this does not
seriously cut down on the overall data transfer rate, since a
"defaulting" type of approach, as SMFS uses can be used to keep the
request messages very small.  We also have found the mandatory password
scheme of UCSB quite easily used, and any server site, (i.e. a site
specifically advertising file storage) can reasonably be expected, in
our opinion, to require passwords (see also RFC #238 by R. Braden).

連続したRTFコマンドはファイルの連続した断片をもたらします。 SPFコマンドの使用でファイルの一部を区切ることができます。 私たちは、ユーザが彼がファイル全体を手に入れる必要はなくてファイルのどんな部分にもアクセスする能力と共に受け取ろうとしているファイルの「塊」のサイズを指定する能力が確実に利点であると思います。 それは、入力ストリームを分析するという問題が実際には見えなくなるのでユーザ・プログラムが書くのをより簡単にします、ユーザ・プログラムが、いつもまさに何を予想したらよいかを知っているとき。 追加、1つの要求では、プロトコルの1つの応答の本質は要求を送って、次に、未知の間隔における予測できないサイズに関するデータの断片を受けるという問題を避けます。 各RTFへの応答は「彼らはまだ聴いている」という元気づけている知識を与えます。 これは、私たちが、1つの要求(1つの応答タイプのプロトコル)の採用で獲得するために多くがあると信じているように導きます。 私たちは、どんな重要なファイル転送のためにも、これが真剣に総合的なデータ転送速度を減らさないと指摘するかもしれません、アプローチの「デフォルト」タイプ以来、非常に小さく要求メッセージを保つのにSMFS用途を使用できるとき。 また、私たちは、UCSBの義務的なパスワード体系が全く容易に使用されているのがわかりました、そして、合理的に、私たちの意見でどんなサーバサイト、(すなわち、明確にファイル記憶装置の広告を出すサイト)もパスワードを必要とすると予想できます。(また、R.ブレーデンでRFC#238を見てください。).

                                                                [Page 1]

Network Working Group                                   H. Brodie
Request for Comments #269                               UCLA-NMC
NIC #7817                                               6 December 71

[1ページ] コメント#269UCLA-NMC NIC#7817 1971年12月6日を求めるネットワークワーキンググループH.飛び込み要求

Almost immediately after starting to use SMFS we found a serious lack in
one area.  There is no way for a user to ask "what files do I have
there?"  As a matter of fact, the author suspects that there are already
several files there which he has "forgotten" about!  It is reasonable,
perhaps even necessary, for any server to supply a nicely formatted
character string describing the files stored there for this password, or
user, or whatever division is used.  The listing should also contain
other pertinent information, such as date created, size etc.

SMFSを使用し始めるほとんど直後、私たちは1つの領域における重大な不足を見つけました。 「私はそこにどんなファイルを持っていますか?」を尋ねるために、ユーザのための方法は全くありません。 実は、作者は、既に彼が「忘れた」いくつかのファイルがそこに周囲にあると疑います! そこにこのパスワード、ユーザ、またはいかなる使用された分割としても保存されたファイルについて説明するうまくフォーマットされた文字列を供給するのが、どんなサーバにも妥当であって、恐らく必要でさえあります。 また、リストは作成されたサイズ日付などの他の適切な情報を含むはずです。

In the meantime, UCSB is providing the SEX system with valuable "out-of-
line on-line" storage, and we look forward to the development of a
widely accepted file transfer protocol, implemented on a large number of
server sites, hopefully equipped with low cost bulk storage.

差し当たり、UCSBがSEXシステムを貴重に提供している、「外、-多くのサーバ遺跡で実装された広く受け入れられたファイル転送プロトコルの開発への系列のオンライン」 ストレージ、および私たちの外観フォワードは希望をいだいて低価格大容量記憶装置を備えていました。

                                                                [Page 2]

SEX Notebook                    Appendix A              H. Brodie
Section 23.29                                           3 December 71

[2ページ]セックスノート付録はH.飛び込みセクション23.29 1971年12月3日です。

                                 FXFER

FXFER

FXFER is a re-entrant program written in Symbol which is used to send a
receive file from UCSB, using their Simple Minded File System.  For the
description of the Network interface to SMFS, see RFC #122 by Jim White.

FXFERはSymbolに書かれたリエントラントプログラムです(UCSBからファイルを受け取って、それらのSimple Minded File Systemを使用することでaを送るのに使用されます)。 SMFSへのNetworkインタフェースの記述に関しては、ジム・ホワイトでRFC#122を見てください。

Files are stored there in a paged format identical to the paged format
that the tape process uses: <header><data page><data page>...  Thus a
file which Master lists as having n pages will take 2048 n bytes of
storage at UCSB.  The user's sign-on initials are used as both the
access and modification passwords, so that if a file is sent under on
user's sign-on, they can only be retrieved or deleted by him.

ファイルはそこ、テーププロセスが使用する呼び出された形式と同じ呼び出された形式で保存されます: <ヘッダー><データページ><データページ>… したがって、Masterがnページを持っているとしてリストアップするファイルはUCSBで2048nバイトのストレージを取るでしょう。 ユーザのサインオンなイニシャルはアクセスと変更パスワードの両方として使用されます、署名であるところでユーザのファイルで発信する場合にだけ、彼がそれらを検索するか、または削除できるように。

Commands

コマンド

PA - Increments "print All" counter.  Different settings of this
     counter yield different levels of program trace output on
     the console.

PA--「印刷All」が打ち返す増分。 このカウンタの異なった設定はコンソールの上に異なったレベルのプログラム跡の出力をもたらします。

NP - No print.  This sets the "Print All" counter to zero.

NP--印刷がありません。 これは「すべてを印刷してください」というカウンタをゼロに設定します。

DF FOO - This deletes the file "FOO" located at UCSB.

DF FOO--これは"FOO"がUCSBで場所を見つけたファイルを削除します。

PF FOO - This sends the file "FOO", pointed to by the user's root
         directory, to UCSB.  Only read access is needed to "FOO".

PF FOO--これはユーザのルートディレクトリによって示された"FOO"というファイルをUCSBに送ります。 読まれるだけであって、アクセスが"FOO"に必要です。

GF FOO - The file "FOO" located at UCSB is retrieved and put in the
         user's root (with write access).  Note that it must have been
         sent by the user to have the right password.

GF FOO、--、UCSBに位置するファイル"FOO"が検索されて、ユーザの根に入れられる(書く、アクセス) それが正しいパスワードを持つためにユーザによって送られたに違いないことに注意してください。

RN FOO BAR - Rename the file "FOO" at UCSB to "BAR".  The same password
             restrictions as with PF and GF apply.  (Not yet implemented)

RN FOO BAR--「バー」へのUCSBで"FOO"にファイルを改名してください。 同じパスワード制限、PFとGFのように、適用してください。 (まだ実装されていません)

ST - Status.  Tells what program is doing and how much its done.

--第状態。 プログラムが何をしているか、そして、どれほどそれをしたかを言います。

X - Exit Program.

X--プログラムを出てください。

If the system and/or UCSB is particularly slow, then UCSBFIL may type a
time-out message.  At this point the user has the option of continuing,
or exiting the program.  The message is self-explanatory, as are most of
the program's messages.

システム、そして/または、UCSBが特に遅いなら、UCSBFILはタイムアウトメッセージをタイプするかもしれません。 ここに、ユーザには、プログラムを続けているか、または出るオプションがあります。 メッセージはプログラムのメッセージの大部分のように自明です。

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Nick Christenson 10/97]

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

                                                                [Page 3]

[3ページ]