RFC310 日本語訳
0310 Another Look at Data and File Transfer Protocols. A.K. Bhushan. April 1972. (Format: TXT=18593 bytes) (Updates RFC0264, RFC0265) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Bhushan Request for Comments: 310 MIT-MAC NIC: 9261 April 3, 1972
Bhushanがコメントのために要求するワーキンググループA.をネットワークでつないでください: 310 MIT-Mac NIC: 9261 1972年4月3日
Another Look At Data And File Transfer Protocols
データとファイル転送プロトコルへの別の一見
Our experience with ad hoc techniques of data and file transfer over the ARPANET together with a better knowledge of terminal IMP (TIP) capabilities and Datacomputer requirements has indicated to us that the Data Transfer Protocol (DTP) (see ref 1) and the File Transfer Protocol (FTP) (see ref 2) could undergo revision. Our effort in implementing DTP and FTP has revealed areas in which the protocols could be simplified without degrading their usefulness.
端末のIMP(TIP)能力とDatacomputer要件に関する、より良い知識に伴うアルパネットの上のデータとファイル転送の臨時のテクニックの私たちの経験は、Data Transferプロトコル(DTP)(審判1を見る)とFile Transferプロトコル(FTP)(審判2を見ます)が改正を受けることができたのを私たちに示しました。 DTPとFTPを実装することにおける私たちの取り組みはそれらの有用性を下げないでプロトコルを簡素化できた領域を明らかにしました。
This paper suggests some specific changes in DTP and FTP that should make them more useful and/or simplify implementation. The attempt here is to stimulate thinking so that we may come up with a better protocol at the forthcoming Data and File Transfer Workshop (see ref 3).
この紙はそれらをより役に立つようにする、そして/または、実装を簡素化するべきであるDTPとFTPにおけるいくつかの特定の変化を示します。 ここの試みは私たちが今度のDataとFile Transfer Workshopで、より良いプロトコルを思いつくことができる(審判3を見る)ように思いながら刺激となることです。
Experience to Date
これまでの経験
A number of ad hoc techniques of transmitting data and files across the ARPANET already exist. Perhaps, the most versatile of these existing methods is the TENEX "CPYNET" system. The "CPYNET" system uses an ad hoc or interim file transfer protocol developed by Ray Tomlinson and others at BBN to transmit files among the TENEX systems on the ARPANET. [Private Communication with Bill Crowther, BBN.]
アルパネットの向こう側にデータとファイルを送る多くの臨時のテクニックが既に存在しています。 恐らく、これらの既存の方法で最も多能であるのは、TENEX"CPYNET"システムです。 "CPYNET"システムはアルパネットでTENEXシステムにファイルを送るためにBBNでレイ・トムリンスンと他のものによって開発された臨時の、または、当座のファイル転送プロトコルを使用します。 [ビル・クラウザー、BBNとの私信。]
In CPYNET, the using process goes through the Initial Connection Protocol (ICP) to server socket 7, establishing a full-duplex connection with an 8-bit byte size. Control information, including user name, password, command (read, write, or append), file name, and byte size for the data connection is transmitted from the using process to the serving process. The original full-duplex connection is then closed, and a new full-duplex connection is established using the original socket numbers but with possibly a different byte size. The file is now transmitted on this newly established connection. The end-of-file is indicated by closing the connection (the mode of transfer is thus similar to DTP "indefinite bit-stream").
CPYNETでは、使用プロセスはInitial Connectionプロトコル(ICP)にサーバソケット7に直面しています、8ビットのバイトサイズとの全二重関係を確立して。 制御情報、データ接続のためにユーザ名、パスワード、コマンド(読むか、書くか、または追加する)、ファイル名、およびバイトサイズを含んでいるのは使用プロセスから給仕プロセスまで伝えられます。 次に、オリジナルの全二重接続が閉店して、新しい全二重接続は、元のソケット番号を使用することで設立されますが、ことによると異なったバイトサイズで閉店します。 ファイルはこの新設された接続のときに現在、送られます。 ファイルの終りは、接続を終えることによって、示されます(その結果、転送の方法はDTP「無期ビットストリーム」と同様です)。
CPYNET has been used quite extensively for transfer of TENEX system files. Because data is not reformatted, and because the optimum connection byte size may be used for data transfer, CPYNET is quite efficient. The PDP-10 (and there are quite a lot in the ARPANET) works more efficiently with a 36 bit byte size which minimizes packing and unpacking of data, and increases effective I/O speed
CPYNETはTENEXシステムファイルの転送に全く手広く使用されました。 データが再フォーマットされないで、最適な接続バイトサイズがデータ転送に使用されるかもしれないので、CPYNETはかなり効率的です。 PDP-10(アルパネットにはかなり多くがある)はデータのパッキングと荷を解くことを最小にして、有効な入出力速度を増強する36ビットのバイトサイズで、より効率的に働いています。
Bhushan [Page 1] RFC 310 Another Look At Data And FTP April 1972
Bhushan[1ページ]RFC310 データとFTP1972年4月への別の一見
(bit rate is 36 times the I/O word transfer rate instead of 8 times). The closing and reopening of connections does increase overhead but this is small in TENEX when compared with inefficiency introduced in data transfer using an inappropriate byte size.
(ビット伝送速度は8回の代わりに転送レートという入出力単語の36倍です。) 接続の閉鎖と再開はオーバーヘッドを増強しますが、不適当なバイトサイズを使用することでデータ転送で導入する非能率と比べると、これはTENEXで小さいです。
Data and file transfer has been achieved at other sites by a simple modification of the user TELNET to enable the transfer of ASCII files as terminal I/O data streams within the constraints of the TELNET protocol. An example of this approach is the use of the "send.file" and "script" features within the MIT-DMCG user-TELNET. Send.file enables the PDP-10 (DMCG) user to transmit his local ASCII files to a receiving process such as an editor at the remote host via a TELNET connection. The program allows for a variable buffer size for transmission, and measures the transfer rate of information bits. Script enables a user to receive an ASCII file from a remote host by essentially printing it out (the terminal output stream is directed to a local file).
データとファイル転送は、端末の入出力データがTELNETプロトコルの規制の中を流れるときASCIIファイルの転送を可能にするために他のサイトでユーザTELNETの簡単な変更で達成されました。 このアプローチに関する例はMIT-DMCGユーザ-TELNETの中の"send.file"と「スクリプト」の特徴の使用です。 Send.fileは、PDP-10(DMCG)ユーザがTELNET接続でリモートホストのエディタなどの受信プロセスに地元のASCIIファイルを送るのを可能にします。 プログラムは情報ビットの転送率のトランスミッション、および測定に関して可変バッファサイズを考慮します。 スクリプトは、ユーザがリモートホストから本質的にはそれを印刷することによってASCIIファイルを受け取るのを可能にします(期末生産高ストリームはローカルファイルに向けられます)。
Our initial experience with the use of send.file program has affirmed the almost linear relationship between buffer size and transmission rate (inverse relationship to processing cost) until the limits imposed by allocates, NCP sending buffers, the IMP message size, or the receiving process speed, are reached. Our experiments have indicated that TELNET processes in which the receiving process "looks" at each character are slow and expensive. The transfer rate to most TELNET receiving processes ranges between 200 and 2,000 bits per second. The NCP-to-NCP transmission rate however is an order- of-magnitude higher (2,000 to 20,000 bits per second).
課された限界がNCPがバッファを送って、IMPメッセージサイズ、または受信にプロセス速度を割り当てて、達するまで、send.fileプログラムの使用の私たちの初体験はバッファサイズと通信速度(加工費との逆さの関係)とのほとんど直線的な関係を確言しました。 私たちの実験は、受信プロセスが各キャラクタが「見る」TELNETプロセスが遅くて、高価であることを示しました。 プロセスを受けるほとんどのTELNETへの転送レートは200と2,000のbpsの間で及びます。 しかしながら、NCPからNCPへの通信速度はより多くの高さに(2,000〜2万のbps)大きさの注文です。
A variation of the above method which avoids the character-by- character processing of TELNET, is transmitting files via auxiliary connections (other than the TELNET connections) with or without the use of DTP. We are collecting data on response times, connect times and transfer speeds employing different transfer and buffering strategies.
DTPの使用のあるなしにかかわらず補助の接続(TELNET接続を除いた)でTELNETの近くキャラクタ文字処理を避ける上のメソッドの変化はファイルを送ることです。 私たちは、異なった転送を使って、戦略をバッファリングする応答時間に関する資料収集と、接続時間と転送速度です。
TIP Capabilities and TIP Users
チップ能力とチップユーザ
It appears now that TIPs will not support DTP in its present form. The more elaborate TIPs with magnetic tape units will however, support the DTP block mode (descriptor and counts) [Private Communication with Bill Crowther, BBN.] It is inconvenient, at the very least, for a TIP user to use services based on DTP (such as remote job service, file transfer, mail, and Datacomputer). The TIP philosophy is that "the computational load and storage should be in the hosts or in the terminals and not in the terminal processor." (See ref 4.) To be consistent with this philosophy the protocols should be simple and convenient to use from the user viewpoint.
TIPsが現行様式でDTPをサポートしないので、それは現れます。 しかしながら、磁気テープ装置がある、より入念なTIPsはそうして、サポートはDTPブロックモード(記述子とカウント)[ビル・クラウザー(BBN)がいる個人的なCommunication]です。 TIPユーザがDTP(リモート・ジョブのサービスや、ファイル転送や、メールや、Datacomputerなどの)に基づくサービスを利用するのは、少なくとも不便です。 TIP哲学は「ホストか端末のであるべきであるいずれの端末のプロセッサでコンピュータの負荷とストレージはそうではありませんも」ということです。 (審判4を見てください。) この哲学と一致しているように、プロトコルは、ユーザ観点からの使用に簡単であって、便利であるはずです。
Bhushan [Page 2] RFC 310 Another Look At Data And FTP April 1972
Bhushan[2ページ]RFC310 データとFTP1972年4月への別の一見
Ideally, TIP users would like to connect (using the initial connection protocol) to the advertised service socket (including logger socket1) in the remote host and type their commands in a uniform, easy to use, format. Allowing the use of ASCII within DTP would facilitate this. (An alternate approach is extending TELNET to include DTP modes, particularly the indefinite bit-stream mode.) Another step would be to use printable ASCII strings instead of numeric codes for commands and arguments in user-level protocols. Use of standard file system commands (with uniform interpretation and format) will lead towards the existence of a Network Virtual File System, much in the same line as Network Virtual Terminal defined in TELNET protocol.
理想的に、TIPユーザは、リモートホストで広告を出しているサービスソケット(きこりのsocket1を含んでいる)に接続して(初期の接続プロトコルを使用します)、彼らのコマンドをユニフォームにタイプしたがっています、使用するのは簡単です、形式。 DTPの中でASCIIの使用を許すと、これは容易にされるでしょう。 (代替のアプローチはDTPモード、特に無期ビットストリームモードを含むようにTELNETを広げています。) もう1ステップはユーザレベルプロトコルにコマンドと議論のための数字コードの代わりに印刷可能なASCIIストリングを使用するだろうことです。 標準ファイルシステム・コマンド(同一解釈と形式がある)の使用はNetwork Virtual File System(TELNETプロトコルで定義されたNetwork Virtual Terminalと同じ系列における多く)の存在に向かって導くでしょう。
The transparent mode in DTP was specifically included to allow convenient use by TIPs. Since the TIPs will not support transparent mode, it makes sense to do away with it. This change would lead to a simplier DTP which allows transfer in Block mode, and the indefinite bit-stream mode. (The suggested default which would be acceptable to all including the TIPs, as it involves no overhead.). We can then make optional or do away with the now mandatory modes available handshake. The using process can indicate if it also accepts the block mode for transfer. (Either by modes available transaction, or by an argument in the command string). The server should accept input in DTP mode as well as ASCII. These fundamental changes in DTP will make communication with TIPs a lot easier.
DTPの透過モードは、TIPsによる便利な使用を許すために明確に含まれていました。 TIPsが透過モードをサポートしないので、それはそれを片づける意味になります。 この変化はBlockモード、および無期ビットストリームモードにおける転送を許容するsimplier DTPに通じるでしょう。 (それとしてTIPsを含んでいて、すべてに許容できる提案されたデフォルトはオーバーヘッドを全く伴いません。) 私たちは、そしてときに造の任意の状態ですることができるか、または現在義務的なモードが利用可能の遠くで握手します。 使用プロセスは、また、それが転送のためのブロックモードを受け入れるかどうかを示すことができます。 (利用可能なモードのどちらか、トランザクション、コマンドストリングにおける議論、) サーバはASCIIと同様にDTPモードによる入力を受け入れるべきです。 TIPsがはるかに簡単な状態でDTPにおけるこれらの根本的変化はコミュニケーションを作るでしょう。
TIP users who do not have a mediating user-FTP process and a file system in their TIP, would probably want to transfer files from input devices or to output devices such as line printer, card reader or punch, or magnetic tape. These devices "listen" on specific "ports" or sockets on a TIP. It would be desirable to modify FTP to allow sending data to a specified socket in a specified mode and type. TIP users would then find it convenient to obtain listing of their files on a high-speed line printer, input their files from a card reader, and keep back-up on cards or magnetic tapes.
彼らのTIPに仲介のユーザFTPプロセスとファイルシステムを持っていないTIPユーザ、たぶん、入力装置かラインプリンタ、カードリーダ、パンチ、または磁気テープなどの出力装置にファイルを移したいでしょう。 これらのデバイスはTIPの上の特定の「ポート」かソケットで「聴かれます」。 指定されたモードで指定されたソケットにデータを送るのを許容して、タイプするようにFTPを変更するのは望ましいでしょう。 TIPユーザは、カードか磁気テープの上に次に、高速ラインプリンタの上に彼らのファイルのリストを入手するのが便利であることがわかって、カードリーダからそれらのファイルを入力して、バックアップを保つでしょう。
Datacomputer Requirements
Datacomputer要件
We have been having a continuing dialogue with CCA personnel (Dick Winter in particular), regarding CCA's plans for data and file transfer on the Datacomputer, and their specific requirements. Dick
私たちには、CCA人員(特にディックWinter)との継続する対話があります、データのためのCCAのプラン、Datacomputerにおけるファイル転送、およびそれらの決められた一定の要求に関して。 ディック
Bhushan [Page 3] RFC 310 Another Look At Data And FTP April 1972
Bhushan[3ページ]RFC310 データとFTP1972年4月への別の一見
Winter will be speaking on this subject at the Data and File Transfer Workshop. This is an attempt to summarize the main points of our discussion, and their implication for data and file transfer.
冬はDataとFile Transfer Workshopでこの対象について演説するでしょう。 これは私たちの議論の要点、およびデータとファイル転送のためのそれらの含意をまとめる試みです。
First, CCA appears quite flexible at this stage regarding the manner in which Datacomputer is to be used. Even the Datalanguage (see ref 5) is flexible and can undergo change. However, CCA would like some changes in the current file transfer protocol and its envisioned use.
まず最初に、CCAは現在のところ、Datacomputerが使用されていることになっている方法に関してかなりフレキシブルに見えます。 Datalanguage(審判5を見る)をさえフレキシブルであり、変化させることができます。 しかしながら、CCAは現在のファイル転送プロトコルとその思い描かれた使用におけるいくつかの変化が欲しいです。
Ideally, CCA would like to see a single full-duplex connection for transfer of all control information which is in Datalanguage. This information is generated by a process, which may be a user at a console, or a user program. Ability to inter-mix data and control information would be definite advantage. The Datacomputer would probably support DTP and allow use of TELNET-ASCII.
理想的に、CCAはDatalanguageにあるすべての制御情報の転送のための単独の全二重接続に会いたがっています。 この情報はプロセス、どれがコンソールのユーザであるかもしれないか、そして、またはユーザ・プログラムで生成されます。 相互データと制御情報を混ぜる能力は明らかな優勢でしょう。 DatacomputerはたぶんDTPをサポートして、TELNET-ASCIIの使用を許すでしょう。
Data may alternatively be sent to or received from a separate user defined port (which may be a socket). It would be advantageous if a user could instruct the Datacomputer to transfer data to or from a file in remote system via FTP (assuming a server-FTP in remote system). CCA is currently not committed to this idea, but is considering it.
あるいはまた、データは、定義されたポート(ソケットであるかもしれない)を送るか、または別々のユーザから受け取るかもしれません。 FTP(リモートシステムのサーバFTPを仮定する)でユーザが、リモートシステムでファイルかファイルからデータを移すようDatacomputerに命令できるなら、有利でしょうに。 CCAは現在この考えに公約しませんが、それを考えています。
In the CCA view, the Datacomputer represents a data management facility with Datalanguage as its command language. From the viewpoint of Datacomputer as an FTP server, FTP commands be a subset of the Datalanguage. It is therefore desirable that FTP commands be printable ASCII strings instead of numeric codes.
CCA視点では、Datacomputerはコマンド言語としてDatalanguageにおけるデータ管理施設を表します。 FTPサーバとしてのDatacomputerの観点から、FTPは、Datalanguageの部分集合であるように命令します。 したがって、FTPコマンドが数字コードの代わりに印刷可能なASCIIストリングであることは望ましいです。
Remote Job Service Requirements
リモート・ジョブサービス要件
Initially two separate protocols were proposed for Remote Job Service (RJS). One was the NETRJS protocol (see ref 6) for remote job service from large Hosts and the other was the NETRJT Protocol (see ref 7) for remote job service from TIPs (and other mini-Hosts). The current thinking however, is to move towards a single RJS with "as much overlap as possible between the methods of dealing with these two user populations." (See ref 8.) Perhaps inclusion of ASCII within DTP would make this feasible.
初めは、2つの別々のプロトコルがRemote Job Service(RJS)のために提案されました。 1つは大きいHostsからのリモート・ジョブサービスのためのNETRJSプロトコル(審判6を見る)でした、そして、もう片方がTIPs(そして、他のミニHosts)からのリモート・ジョブサービスのためのNETRJTプロトコル(審判7を見る)でした。 しかしながら、シングルに向かった移動にはRJSが「これらの2つのユーザ人口に対処するメソッドの間のできるだけ多くのオーバラップ」であると思う電流。 (審判8を見てください。) 恐らく、DTPの中のASCIIの包含で、これは可能になるでしょう。
The existing proposals for DTP and FTP have been considered somewhat less than optimal for RJS needs. Specific drawbacks of DTP and FTP have been pointed out in the handling of data structures and data types. Most of these problems seem relatively easy to resolve. It would involve making Network ASCII the default data type (acceptable to all hosts) and providing a way in FTP for proposing and rejecting alternative data types and data structures.
DTPとFTPのための既存の提案はRJSの必要性に最適であるというよりもいくらか検討されていません。 DTPとFTPの特定の欠点はデータ構造とデータ型の取り扱いで指摘されました。 これらの問題の大部分は決議するのが比較的簡単に見えます。 それは、Network ASCIIを(すべてのホストにとって許容できる)の、そして、代替のデータ型とデータ構造を提案して、拒絶するためにFTPを入口に提供しているデフォルトデータ型にすることを伴うでしょう。
Bhushan [Page 4] RFC 310 Another Look At Data And FTP April 1972
Bhushan[4ページ]RFC310 データとFTP1972年4月への別の一見
Another inadequacy of FTP (which pertains to other applications as well) is in the area of error recovery. Currently there is no way to "restart" transmission if an element in the transmission path fails. One solution suggested has involved the use of sequence number (see ref 9). A number of other solutions exist to the problem. These are discussed later in the section 'FTP Reconsidered'.
FTP(また、他のアプリケーションに関係する)の別の不適当はエラー回復の領域にあります。 現在、トランスミッション経路の要素が失敗するなら、トランスミッションを「再開する」方法が全くありません。 示された1つのソリューションが一連番号の使用にかかわりました(審判9を見てください)。 他の多くのソリューションが問題に存在しています。 後で'FTP Reconsidered'というセクションでこれらについて議論します。
DTP Reconsidered
DTPは再考しました。
The aspiration for DTP was that it would provide a uniform mechanism for separating information into its logical structure (records, files, and control), and rudimentary error control. The evaluation of DTP and its modes should be on the basis of speed (real-time), efficiency (processing cost), reliability (error control and recovery), and the ease of its use.
DTPへの切望はその論理構造(レコード、ファイル、およびコントロール)、および初歩的なミスコントロールに情報を切り離すのに一定のメカニズムを提供するだろうということでした。 DTPの評価とそのモードが速度の基礎(リアルタイムの)、効率(加工費)、信頼性(誤り制御と回復)、および使用の容易さにあるべきです。
It is now clear that unless DTP was significantly revised, the TIP and other mini-Host user would find it difficult to use services based on use of DTP. Allowing the use of ASCII within DTP, and using defaults instead of the "modes available" handshake, would alleviate this problem, but compromise the DTP error control function. Whether error control belongs at the DTP level or at a higher level needs further discussion.
DTPがかなり改訂されていない場合、TIPと他のミニHostユーザが、DTPの使用に基づくサービスを利用するのが難しいのがわかるのは、現在、明確です。 DTPの中でASCIIの使用を許して、「利用可能なモード」握手の代わりにデフォルトを使用すると、この問題は軽減するでしょうが、DTP誤り制御機能に感染してください。 誤り制御がDTPレベルにおいて、または、より高いレベルにおいて属するかどうかがさらなる議論を必要とします。
DTP, in its present form, does not provide sufficient error control and recovery procedures. To make DTP more useful, either it should be simplified (at least from a user viewpoint), or it should be extended to include better error control with built in error recovery, and possible handling of data types and data structures.
DTPは十分な誤り制御とリカバリ手順を現行様式に提供しません。 DTPをより役に立つようにするように、それが簡素化されるべきですか(少なくともユーザ観点から)、または組立の間違った回復に伴う、より良い誤り制御、およびデータ型とデータ構造の可能な取り扱いを含んでいるのは拡張されているべきです。
In the simplified version, DTP would only be a format procedure in which data could be transmitted as ASCII (no format) with escape to an 8-bit transparent (indefinite bit-stream) mode or in data blocks (descriptor and count mode). The choice of which mode to use, and all error control, error recovery, and aborts would be handled by the higher-level protocol.
簡易型のバージョンでは、DTPは8ビットの見え透いた(無期ビットストリーム)モードかデータにおけるエスケープがあるASCII(形式がない)が(記述子とカウントモード)を妨げるときデータを送ることができるだろう書式手続きにすぎないでしょう。 選択、どのモードを使用するかをすべての誤り制御、エラー回復、およびアボートは上位レベル・プロトコルによって扱われるでしょう。
The utility of the block mode in data transfer has been questioned by many who suggest that it puts a large overhead for providing the simple function of indicating end-of-file, and separating data and control information. The alternative data transfer strategy is to use separate connections for control and data information and/or close and reopen connections. This causes an overhead of a different sort, but has the advantage that the byte size for connection may be chosen to optimize data transfer.
データ転送によるブロックモードに関するユーティリティはファイルの終りを示す簡単な機能を提供して、データと制御情報を切り離すために大きいオーバーヘッドを置くのを示す多くによって質問されました。 代替のデータ転送戦略は、接続をコントロールとデータ情報に別々の接続を使用する、終えて、そして/または、再開させることです。 これは、データ転送を最適化するために、異なった種類のオーバーヘッドを引き起こしますが、接続のためのバイトサイズが選ばれるかもしれない利点を持っています。
Bhushan [Page 5] RFC 310 Another Look At Data And FTP April 1972
Bhushan[5ページ]RFC310 データとFTP1972年4月への別の一見
A drawback of present DTP is that it is geared to transfer of 8-bit bytes. Perhaps a good strategy for data transfer would be to allow sending data in an agreed upon transfer mode. The transfer mode chosen should determine the byte size for connection, the data type chosen, and any data structure information. This mode may be chosen at the DTP level, or at the using protocol level.
現在のDTPの欠点は8ビットのバイトの転送に適合しているということです。 恐らく、データ転送のための優れた戦略がデータを送るのを許容するだろうことである、転送モードに同意しました。 選ばれた転送モードは接続、選ばれたデータ型、およびどんなデータ構造情報のためにもバイトサイズを決定するべきです。 このモードは、DTPレベルで選ばれているか、または使用のときにレベルについて議定書の中で述べるかもしれません。
FTP Reconsidered
再考されたFTP
The aspiration for FTP was that it would facilitate file management and file transfer in the ARPANET Virtual File System. FTP success should be evaluated by the extent of its use, convenience and efficiency in its use, and its suitability for other applications such as Datacomputer, RJS, and Mail.
FTPへの切望はアルパネットVirtual File Systemにおけるファイル管理とファイル転送を容易にするだろうということでした。 FTP成功はDatacomputerや、RJSや、メールなどの使用、便利と使用中である効率、および他のアプリケーションへのその適合の範囲によって評価されるべきです。
Wide use of FTP would be possible if a user could use an FTP-server directly without the help of a mediating DTP/FTP-User process. This would require that commands be ASCII strings instead of numeric codes, and that ASCII characters be an acceptable input. Such a change in FTP would greatly increase its acceptance at the cost of making the server-implementation more complex. Combined implementation, however, would be simplified as the mediating FTP- user process (if used at all) would be simplified.
ユーザが直接仲介FTP DTP/ユーザ・プロセスの助けなしでFTPサーバを使用できるなら、FTPの広い使用は可能でしょうに。 これはコマンドが数字コードの代わりにASCIIストリングであり、ASCII文字が許容できる入力であることを必要とするでしょう。 FTPにおけるそのような変化はサーバ実装をより複雑にする費用で承認を大いに増強するでしょう。 しかしながら、仲介のFTPユーザプロセス(少しでも使用されるなら)が簡素化されるだろうというのに応じて、結合した実装は簡素化されるでしょう。
Efficiency of transfer is an important factor affecting the usefulness of FTP. File transfer may be very expensive (in terms of CPU time) and slow (in real-time) if an inappropriate transfer strategy is used (e.g., inappropriate byte size). Every attempt should be made to optimize transfer of data. A good strategy may be to allow transfer of files over a separate connection or close and reopen connections (using perhaps a different byte size). A problem with indicating end-of-file by closing connection is that is uncertain if the connection was closed because end-of-file was reached, or because of a failure or error condition. Perhaps "NCP interrupts" could be used in addition to a "close" to indicate definite end-of-file condition.
転送の効率はFTPの有用性に影響する重要な要素です。 不適当な転送戦略が使用されているなら(例えば、不適当なバイトサイズ)、ファイル転送は、非常に高価であって(CPU時間に関する)、遅いかもしれません(リアルタイムでの)。 データ転送を最適化するように最善の努力をするべきです。 優れた戦略は、接続(恐らく、異なったバイトサイズを使用する)を別々の接続の上にファイルの転送を許容するか、終えて、または再開させることであるかもしれません。 接続を終えるのによるファイルの終りがそれであることを示すことに関する問題は接続がファイルの終りに達したためか失敗かエラー条件に閉店したかどうか不確実です。 恐らく、明確なファイル終了条件を示すのに「閉鎖」に加えて「NCP中断」を使用できました。
A drawback in the present FTP strategy is that it has no restart procedure. One proposal for restart has involved the use of the sequence numbers used in DTP block mode. Our feeling is that perhaps restart may best be accomplished by incorporating a command in FTP that allows a user to specify the place in file where to begin retransmission. A possible solution is to use the "SPF" command implemented in the UCSB Simple-Minded File System (see ref 10). Another solution may be to have optional arguments for retrieve and store commands that allow selective retrieval and replacement (specified by bits, character, words, lines, pages or segments).
現在のFTP戦略による欠点はそれには再開手順が全くないということです。 再開のための1つの提案がDTPブロックモードで使用される一連番号の使用にかかわりました。 私たちの感じは恐らく、ユーザがコネが「再-トランスミッション」を始めるためにどこをファイルする場所を指定できるFTPにコマンドを取り入れることによって再開を実行するかもしれないのが最も良いということです。 可能なソリューションはUCSBの純真なファイルシステムで実装された"SPF"コマンドを使用する(審判10を見てください)ことです。 他の解決法には任意の議論があることになっているかもしれない、選択している検索と交換(ビット、キャラクタ、単語、系列、ページまたはセグメントで、指定される)を許すコマンドを、検索して、保存してください。
Bhushan [Page 6] RFC 310 Another Look At Data And FTP April 1972
Bhushan[6ページ]RFC310 データとFTP1972年4月への別の一見
Another useful addition to FTP would be a protocol procedure between user and server to agree to data type, data structure, and mode for file transfer. This would enable the user and server to reach the optimum file transfer strategy acceptable to both.
FTPへの別の役に立つ追加は、ファイル転送のためにデータ型、データ構造、およびモードに同意するためにはユーザとサーバの間のプロトコル手順でしょう。 これは、ユーザとサーバが両方に許容できる最適なファイル転送戦略に達するのを可能にするでしょう。
Concluding Remarks
結びの言葉
We have discussed in this paper what we see as the major problem areas in the present DTP and FTP specifications. We hope this discussion will stimulate thinking, so that we can arrive at revised specifications for DTP and FTP that satisfy all the diverse needs in an elegant manner.
私たちはこの紙で自分が現在のDTPとFTP仕様で大した問題領域をみなすことについて議論しました。 この議論が考えを刺激することを願っています、私たちが上品な態度ですべてのさまざまの需要を満たすDTPとFTPのための訂正明細書に到着できるように。
REFERENCES
参照
1. The Data Transfer Protocol, Bhushan, et al, NWG/RFC #264, NIC #7212.
1. Data Transferプロトコル、Bhushan、他、NWG/RFC#264、NIC#7212。
2. The File Transfer Protocol, Bhushan, et al, NWG/RFC #265, NIC #7213.
2. File Transferプロトコル、Bhushan、他、NWG/RFC#265、NIC#7213。
3. Data and File Transfer Workshop Announcement, A. Bhushan, NWG/RFC #309, NIC #9260.
3. データファイル転送ワークショップ発表、A.Bhushan NWG/RFC#309、NIC#9260。
4. The Terminal IMP for the ARPA Compuer Network, Ornstein, et al, SJCC, 1972, NIC #8218.
4. 1972、8218SJCC、年の他、オーンスティーン、ARPA Compuer Network、NIC#Terminal IMP
5. Datalanguage, Computer Operation of America, Datacomputer Project, Working Paper No.3, October 29, 1971, NIC #8208.
5. Datalanguage、アメリカのコンピュータ操作、Datacomputerプロジェクト、監査調書No.3、1971年10月29日、NIC#8208。
6. Interim NETRJS Specifications, R. T. Braden, NWG/RFC #189, NIC #7133.
6. 当座のNETRJS仕様、R.T.ブレーデンNWG/RFC#189、NIC#7133。
7. NETRJT - - Remote Job Service Protocol for TIPs, R. T. Braden, NWG/RFC #283, NIC #8165.
7. NETRJT----チップ、R.T.ブレーデンNWG/RFC#283、NIC#8165のためのリモート・ジョブサービスプロトコル。
8. RJS Protocol Meeting Notes, 25 February 1972, A. McKenzie (limited distribution).
8. RJSプロトコルMeeting Notes、1972年2月25日、A.マッケンジー(限定販路)。
9. A Suggested Addition to File Transfer Protocol, A. McKenzie, NWG/RFC #281, NIC #8163.
9. ファイル転送プロトコル、A.マッケンジー、NWG/RFC#281、NIC#8163への提案された追加。
10. Network Specifications for UCSB's Simple-Minded Files System, James E. White, NWG/RFC #122, NIC #5834
10. UCSBの純真なファイルシステム、ジェームス・E.ホワイト、NWG/RFC#122、NIC#5834のためのネットワーク指定
[This RFC was put into machine readable form for entry] [into the online RFC archives by H駘鈩e Morin, Viag駭ie 10/99]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][H駘鈩eモーリンによるオンラインRFCアーカイブへのViag駭ie10/99]
Bhushan [Page 7]
Bhushan[7ページ]
一覧
スポンサーリンク