RFC683 日本語訳

                              RFC 683, NIC 32251

RFC683、NIC32251

                FTPSRV - TENEX FTP EXTENSIONS FOR PAGED FILES

FTPSRV--呼び出されたファイルのためのTENEX FTP拡張子

                        R. Clements - BBN - 3 April 75

R.クレメンツ--BBN--1975年4月3日

1   Introduction

1つの序論

    In response to a long-known need for the ability to transfer TENEX paged
files over the net via FTP, the TENEX FTP implementation has been extended.

移す能力の長く知られている必要性に対応して、TENEXはネットの上にFTPでファイルを呼び出して、TENEX FTP実装を広げてあります。

    This implementation is an extension to the "OLD" protocol (RFC 354).  It
was built after useful discussions with Postel, Neigus, et al.  I do not mean
to imply that they agreed that this implementation is correct, nor for that
matter do I feel it is correct.  A "correct" implementation will be negotiated
and implemented in the "NEW" protocol (RFC 542), if funding ever appears for
that task.

この実装は「古い」プロトコル(RFC354)への拡大です。 それはポステル、Neigus、他との役に立つ議論の後に建てられました。 私は、彼らが、この実装が正しいのに同意したのを含意するのを意図しません、そして、さらに言えば、それが正しいと感じません。 「正しい」実装は、「新しい」プロトコル(RFC542)で交渉されて、実装されるでしょう、基金がそのタスクの弁護に出廷するなら。

2   The Problem(s)

2 問題(s)

    This extension attacks two separate problems: Network reliability and
TENEX disk file format's incompatibility with FTP.  A checksummed and
block-sequence-numbered transmission mode is seriously needed, in my opinion.
This mode should also allow data compression.

この拡大は二つの別々な問題を攻撃します: FTPで信頼性とTENEXディスクファイル形式の不一致をネットワークでつないでください。 checksummedされて付番された系列を妨げている転送方式が私の意見で真剣に必要です。 また、このモードはデータ圧縮を許容するべきです。

    It is also necessary to handle paged, holey TENEX files.  This latter
problem, seriously needed for NLS, is the motivation for the current
extension.

また、呼び出されたholey TENEXファイルを扱うのも必要です。 この後者の真剣にNLSに必要な問題は現在の拡大に関する動機です。

    The former problem requires a new MODE command, if done correctly;
probably two MODEs, to allow data compression in addition to checksumming.
Actually, I think that is the tip of an iceberg which grows as 2**N for
additional sorts of modes, so maybe some mode combination system needs to be
dreamed up.  Cf the AN, AT, AC, EN, ET, EC TYPEs.  Also, one should be able to
use MODE B and MODE C together (NEW protocol) to gain both the compression and
restart facilities if one wanted.

正しくするなら、前の問題は新しいMODEコマンドを必要とします。 たぶん2MODEs、checksummingに加えたデータ圧縮を許容するために。 実際に、私が、それが追加種類のモードのための2**Nとして成長する氷山の一角であると思うので、多分何らかのモード併用制が、発明される必要があります。 Cf、西暦、アン、ET、ECはタイプされます。 また、1つが欲しいなら、圧縮とリスタート機能の両方を獲得するのにMODE BとMODE Cを一緒に(NEWは議定書を作る)使用できるでしょうに。

    The second problem, TENEX files, are probably a new kind of STRUcture.
However, it should be possible to send a paper tape to a disk file, or vice
versa, with the transfer looking like a paged file; so perhaps we are dealing
with a data representation TYPE.  This argument is a bit strained, though, so
a paged STRUcture is quite likely correct.  I admit to feeling very unsure
about what is a MODE, what is a TYPE and what is a STRUcture.

2番目の問題であり、TENEXファイルはたぶんSTRUctureの新しい種類です。 しかしながら、紙テープをディスクファイルに送るのが可能であるべきであるか、逆もまた同様です、転送が呼び出されたファイルに似ていて。 恐らくそれで、私たちはデータ表現TYPEに対処しています。 もっとも、したがって、呼び出されたSTRUctureはこの議論が少し張られるのがおそらく全く正しいです。 私は、何がMODEであるか、そして、何がTYPEであるか、そして、何がSTRUctureであるかに関して非常に不確かであると感じることを認めます。

3   The (Incorrect) choices made

(不正確)の選択が作った3

    Having decided that new MODEs and STRUctures were needed, I instead
implemented the whole thing as a single new TYPE.  After all, I rationalize,
checksumming the data on the network (MODE) and representing the data in the
processing system as a checksummed TYPE are really just a matter of where you
draw the imaginary line between the net and the data.  Also, a single new TYPE
command reduced the size of the surgery required on the FTP user and server
programs.

新しいMODEsとSTRUcturesが必要であったと決めたので、私は代わりに独身の新しいTYPEとして全体のものを実装しました。 結局、私は推論して、ネットワーク(MODE)でデータをchecksummingして、checksummed TYPEとして処理システムのデータを表すのは、本当にただあなたがネットとデータの間でイマジナリーラインを引くところに関する問題です。 また、ただ一つの新しいTYPEコマンドはFTPユーザとサーバプログラムのときに必要であった外科のサイズを減少させました。

4   Implementation details

4 実装の詳細

    The name of the new TYPE is "XTP".  I propose this as a standard for all
the Key Letter class of FTP commands: the "X" stands for "experimental" --
agreed on between cooperating sites.  The letter after the "X" is signed out
from the protocol deity by an implementor for a given system.  In this case,
"T" is for TENEX.  Subsequent letter(s) distinguish among possibly multiple
private values of the FTP command.  Here "P" is "Paged" type.

新しいTYPEという名前は"XTP"です。 私はすべてのKey LetterのクラスのFTPコマンドの規格としてこれを提案します: 「X」は「実験的」に表します--協力サイトの間で同意されます。 「X」の後の手紙は与えられたシステムのために作成者によってプロトコル神からサインアウトされます。 この場合、「T」はTENEXのためのものです。 その後の手紙はFTPコマンドのことによると複数の個人的な値の中で区別されます。 ここで、「P」は「呼び出された」タイプです。

   TYPE XTP is only implemented for STRU F, BYTE 36, and MODE S.

TYPE XTPはSTRU F、BYTE36、およびMODE Sのために実装されるだけです。

    Information of TYPE XTP is transfered in chunks (I intentionally avoid the
words RECORD and BLOCK) which consist of a header and some data.  The data in
a chunk may be part of the data portion of the file being transferred, or it
may be the FDB (File Descriptor Block) associated with the file.

TYPE XTPに関する情報はヘッダーといくつかのデータから成る塊(私は故意に単語のRECORDとBLOCKを避ける)でtransferedされます。 塊におけるデータは移されるファイルのデータ部の一部であるかもしれませんかそれがファイルに関連しているFDBであるかもしれません(ファイルDescriptor Block)。

5   Diversion: the TENEX Disk File

5転換: TENEXディスクファイル

    For those not familiar with the TENEX file system, a brief dissertation is
included here to make the rest of the implementation meaningful.

TENEXファイルシステムに詳しくないそれらに関しては、簡潔な論文は、実装の残りを重要にするようにここに含まれています。

    A TENEX disk file consists of four things: a pathname, a page table, a
(possibly empty) set of pages, and a set of attributes.

TENEXディスクファイルは4つのものから成ります: パス名、ページテーブル、(ことによると空)のセットのページ、および1セットの属性。

    The pathname is specified in the RETR or STOR verb.  It includes the
directory name, file name, file name extension, and version number.

パス名はRETRかSTOR動詞で指定されます。 それはディレクトリ名、ファイル名、ファイル名の拡張子、およびバージョン番号を含んでいます。

    The page table contains up to 2**18 entries.  Each entry may be EMPTY, or
may point to a page.  If it is not empty, there are also some page-specific
access bits; not all pages of a file need have the same access protection.

ページテーブルは18のエントリーを2**まで含んでいます。 各エントリーは、EMPTYであるかもしれない、または1ページを示すかもしれません。 また、それが空でないなら、いくつかのページ特有のアクセスビットがあります。 ファイルのページが必要とするというわけではないすべてが同じアクセス保護を持っています。

    A page is a contiguous set of 512 words of 36 bits each.

1ページはそれぞれ36ビットの512の単語の隣接のセットです。

    The attributes of the file, in the FDB, contain such things as creation
time, write time, read time, writer's byte-size, end of file pointer, count of
reads and writes, backup system tape numbers, etc.

FDBのファイルの属性は、作成時間のようなものを含んでいて、時間を書いて、時間、作家のバイトサイズ、ファイルの終り指針、読書のカウントを読んで、書いて、システム・テープ番号のバックアップをとりますなど。

    NOTE: there is NO requirement that pages in the page table be contiguous.
There may be empty page table slots between occupied ones.  Also, the end of
file pointer is simply a number.  There is no requirement that it in fact
point at the "last" datum in the file. Ordinary sequential I/O calls in TENEX
will cause the end of file pointer to be left after the last datum written,
but other operations may cause it not to be so, if a particular programming
system so requires.

以下に注意してください。 ページテーブルのページが隣接であるという要件が全くありません。 占領されたものの間には、空のページテーブルスロットがあるかもしれません。 また、ファイルの終り指針は単に数です。 事実上、ファイルにおける「最後」のデータを指し示すという要件が全くありません。 最後のデータの書かれましたが、他の操作が、したがって、それがそうでないことを引き起こしたかもしれない後にTENEXでの普通の連続した入出力呼び出しでファイルの終り指針を残すでしょう、特定のプログラミング・システムがそう必要であるなら。

    In fact both of these special cases, "holey" files and end-of-file
pointers not at the end of the file, occur with NLS data files.  These files
were the motivation for the new TYPE.

事実上、ファイルの端でないところのこれらの特別な場合、"holey"ファイル、およびファイルの終り指針では、NLSデータファイルで、起こってください。 これらのファイルは新しいTYPEに関する動機でした。

6   Meanwhile, back at the implementation,...

6 実装で…

    Each chunk of information has a header.  The first byte, which is the
first word (since TYPE XTP is only implemented for BYTE 36) of the chunk, is a
small number, currently 6, which is the number of following words which are
still in the header.  Next come those six words, and then come some data
words.

情報の各塊には、ヘッダーがあります。 現在、最初のバイト(塊の最初の単語(TYPE XTPがBYTE36のために実装されるだけであるので)である)は少ない数、6です。(その6はまだヘッダーにある次の単語の数です)。 それらの6つの知らせが次に来て、いくつかのデータ・ワードがその時、来ます。

   The six header words are:
      Word 1: a checksum.
         This is a one's complement sum (magnitude and end-around carry) of 
         the six header words and the following data words (but not the 
         leading "6" itself).  The sum of all words including the checksum 
         must come out + or - zero.
      Word 2: A sequence number.
         The first chunk is number 1, the second is number 2, etc.
      Word 3: NDW,
         the number of data words in this chunk, following the header.  Thus
         the total length of the chunk is 1 (the word containing NHEAD) + 
         NHEAD +NDW.  The checksum checks all but the first of these.
      Word 4: Page number.
         If the data is a disk file page, this is the number of that page in
         the file's page map.  Empty pages (holes) in the file are simply 
         not sent.  Note that a hole is NOT the same as a page of zeroes.
      Word 5: ACCESS.
         The access bits associated with the page in the file's page map.  
         (This full word quantity is put into AC2 of an SPACS by the program
         reading from net to disk.)
      Word 6: TYPE.
         A code for what type of chunk this is. Currently, only type zero 
         for a data page, and type -3 for an FDB are sent.

6つのヘッダー単語は以下の通りです。 Word1: チェックサム。 これが6つのヘッダー単語と以下のデータ・ワードの1の補数合計(大きさとエンドアラウンドは運ばれる)である、(先導でない、「6インチ自体)」 または、チェックサムを含むすべての単語の合計が+から来なければならない、--ゼロ。 Word2: 一連番号。 最初の塊がNo.1である、2番目はNo.2ですなど。 Word3: NDW、ヘッダーに続くこの塊における、データ・ワードの数。 したがって、塊の全長は1(含有という単語NHEAD)+のNHEAD+NDWです。 チェックサムはこれらの1番目を除いたすべてをチェックします。 Word4: ページ番号。 データがディスクファイルページであるなら、これはファイルのページマップのそのページの数です。 ファイルの何も書いていないページ(穴)は絶対に送られません。 穴が1ページのゼロと同じでないことに注意してください。 Word5: アクセサリー ファイルのページマップでページに関連しているアクセスビット。 (ネットからディスクまで読むプログラムでこのフルワード量をSPACSのAC2に入れます。) Word6: タイプしてください。 何が塊をタイプするかコード。 現在、FDBのための-3が送られるデータページ、およびタイプのために単にゼロをタイプしてください。

    After the header are NDW data words.  NDW is currently either 1000 octal
for a data page or 25 octal for an FDB.  Trailing zeroes in a disk file page
will soon be discarded, making NDW less than 1000 in that case.  The receiving
portions of FTP server and user will accept these shortened pages.  The sender
doesn't happen to send them that way yet.

ヘッダーの後に、NDWデータ・ワードがあります。 現在、NDWは1000年のデータページ8進かFDBのための25 8進のどちらかです。 その場合NDWを1000未満にして、ディスクファイルページの末尾のゼロはすぐ、捨てられるでしょう。 FTPサーバとユーザの受信一部がこれらの短くされたページを受け入れるでしょう。 送付者はそのようにまだそれらを偶然でない送りません。

Verification is performed such that an error is reported if either:
   The checksum fails,
   The sequence number is not correct,
   NDW is unreasonable for the given chunk type, or
   The network file ends at some point other than immediately following the 
data portion of an FDB chunk.

検証が実行されるので、誤りはどちらかなら報告されます: 一連番号が適度でない、チェックサムは失敗するか、与えられた塊タイプに、NDWが無理であるか、またはFDB塊のデータ部に続いて、ネットワークファイルがすぐにを除いた何らかのポイントで終わります。

7   Closing comments

7 コメントを終えること。

    This FTP server and user are in operation on all the BBN systems and at
some other sites -- the user being more widely distributed since fewer sites
have made local modifications to the user process.

このFTPサーバとユーザはすべてのBBNシステムの上と、そして、ある他のサイトで稼働中です--より少ないサイトがユーザ・プロセスへの地方の変更をしたので、より広く分配されるユーザ。

    I believe the issues of checksumming and sequencing should be addressed
for the "NEW" protocol.  I hope the dissertation on TENEX files has been
useful to users of other systems.  It may explain my lack of comprehension of
the "record" concept, for example.  A TENEX file is just a bunch of words
pointed to by a page table.  If those words contain CRLF's, fine -- but that
doesn't mean "record" to TENEX. I think this RFC also points out clearly that
net data transfers are implemented like the layers of an onion: some
characters are packaged into a line.  Some lines are packaged into a file.
The file is broken into other managable units for transmission.  Those units
have compression applied to them.  The units may be flagged by restart markers
(has anyone actually done that?).  The compressed units may be checksummed,
sequence numbered, date-and-time stamped, and flagged special delivery.  On
the other end, the process is reversed.  Perhaps MODE, TYPE, and STRU don't
really adequately describe the situation. This RFC was written to allow
implementors to interface with the new FTP server at TENEX sites which install
it.  It is also really a request for comments on some of these other issues.

私は、checksummingと配列の問題が「新しい」プロトコルのために扱われるべきであると信じています。 TENEXファイルの上の論文が他のシステムのユーザの役に立っていることを願っています。それで、私の例えば、「記録的な」概念の読解の不足がわかるかもしれません。 TENEXファイルはページテーブルによって示されたまさしく多くの言葉です。 それらの単語がCRLFのものを含んでいるなら、きめ細かに、それだけが、TENEXに「記録すること」を意味しません。 私は、また、このRFCが、ネットのデータ転送がたまねぎの層のように実装されると明確に指摘すると思います: 系列にパッケージされるキャラクタもあります。 いくつかの系列がファイルの中にパッケージされます。 トランスミッションのための他の管理可能ユニットはファイルに細かく分けられます。 それらのユニットで、圧縮をそれらに適用します。 ユニットは再開マーカーによって旗を揚げられるかもしれません(だれか実際にそれをしましたか?)。 圧縮されたユニットは、押し込まれた、checksummedされて、系列番号付の日時と、旗を揚げさせられた速達郵便であるかもしれません。 もう一方の端では、プロセスは逆にされます。 恐らく、MODE、TYPE、およびSTRUは本当に適切に状況について説明しません。 このRFCは、作成者がそれをインストールするTENEXサイトの新しいFTPサーバに接続するのを許容するために書かれました。 これらの他のいくつかの問題のコメントを求めてそれは本当にも要求です。