RFC2348 日本語訳
2348 TFTP Blocksize Option. G. Malkin, A. Harkin. May 1998. (Format: TXT=9515 bytes) (Obsoletes RFC1783) (Updates RFC1350) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Malkin Request for Commments: 2348 Bay Networks Updates: 1350 A. Harkin Obsoletes: 1783 Hewlett Packard Co. Category: Standards Track May 1998
Commmentsを求めるワーキンググループG.マルキンの要求をネットワークでつないでください: 2348のベイネットワークスアップデート: 1350 A.ハーキンは以下を時代遅れにします。 1783年のヒューレットパッカード社のカテゴリ: 標準化過程1998年5月
TFTP Blocksize Option
TFTP Blocksizeオプション
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. One of its primary uses is the booting of diskless nodes on a Local Area Network. TFTP is used because it is very simple to implement in a small node's limited ROM space. However, the choice of a 512-octet blocksize is not the most efficient for use on a LAN whose MTU may 1500 octets or greater.
トリビアル・ファイル転送プロトコル[1]はクライアントがリモートホストにファイルを届けるか、または置く簡単で、堅苦しいファイル転送プロトコルです。 プライマリ用途の1つはローカル・エリア・ネットワークにおけるディスクレスノードの穂ばらみです。 小さいノードの限られたROMでスペースを実装するのが非常に簡単であるので、TFTPは使用されています。 しかしながら、LANにおけるMTUが1500以上の八重奏がそうするかもしれない使用には、512八重奏がblocksizeするaの選択は最も効率的ではありません。
This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. The TFTP Option Extension mechanism is described in [2].
このドキュメントはクライアントを許容するTFTPオプションについて説明します、そして、aを交渉するサーバはネットワーク媒体により適切な状態でblocksizeされます。 TFTP Option Extensionメカニズムは[2]で説明されます。
Blocksize Option Specification
オプション仕様をBlocksizeします。
The TFTP Read Request or Write Request packet is modified to include the blocksize option as follows. Note that all fields except "opc" are NULL-terminated.
TFTP Read RequestかWrite Requestパケットが含むように変更される、blocksizeする、以下のオプション。 "opc"を除いたすべての分野がNULLによって終えられることに注意してください。
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
| opc |filename| 0 | mode | 0 | blksize| 0 | #octets| 0 |
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+ | opc|ファイル名| 0 | モード| 0 | blksizeします。| 0 | #octets| 0 | +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
opc
The opcode field contains either a 1, for Read Requests, or 2,
for Write Requests, as defined in [1].
opcodeがさばくopcは[1]で定義されるようにRead RequestsのためのWrite Requestsのための1か2つの1を含んでいます。
Malkin & Harkin Standards Track [Page 1] RFC 2348 TFTP Blocksize Option May 1998
マルキンとハーキンStandardsはTFTP Blocksizeオプション1998年5月にRFC2348を追跡します[1ページ]。
filename
The name of the file to be read or written, as defined in [1].
ファイル名、[1]で定義されるような読まれるか、または書かれているファイルの名前。
mode
The mode of the file transfer: "netascii", "octet", or "mail",
as defined in [1].
モード、ファイル転送の方法: [1]の"netascii"、「八重奏」、または定義されるとしての「メール。」
blksize
The Blocksize option, "blksize" (case in-sensitive).
blksizeする、Blocksizeオプション、"blksizeする"(ケース神経の鈍い)。
#octets
The number of octets in a block, specified in ASCII. Valid
values range between "8" and "65464" octets, inclusive. The
blocksize refers to the number of data octets; it does not
include the four octets of TFTP header.
#oASCIIで指定されたブロックの八重奏の数をctetsします。 有効値は「8インチと「65464」八重奏的で、包括的であること」の間で及びます。 blocksizeする、データ八重奏の数について言及します。 それはTFTPヘッダーの4つの八重奏を含んでいません。
For example:
例えば:
+-------+--------+---+--------+---+--------+---+--------+---+
| 1 | foobar | 0 | octet | 0 | blksize| 0 | 1428 | 0 |
+-------+--------+---+--------+---+--------+---+--------+---+
+-------+--------+---+--------+---+--------+---+--------+---+ | 1 | foobar| 0 | 八重奏| 0 | blksizeします。| 0 | 1428 | 0 | +-------+--------+---+--------+---+--------+---+--------+---+
is a Read Request, for the file named "foobar", in octet (binary) transfer mode, with a block size of 1428 octets (Ethernet MTU, less the TFTP, UDP and IP header lengths).
ファイルのためのRead Requestが1428の八重奏のブロック・サイズで八重奏(バイナリー)転送モードで"foobar"と命名される、(イーサネットMTUで、より少ない、TFTP、UDP、およびIPヘッダ長)
If the server is willing to accept the blocksize option, it sends an Option Acknowledgment (OACK) to the client. The specified value must be less than or equal to the value specified by the client. The client must then either use the size specified in the OACK, or send an ERROR packet, with error code 8, to terminate the transfer.
サーバが、受け入れても構わないと思っている、blocksizeする、オプション、それはOption Acknowledgment(OACK)をクライアントに送ります。 規定値はクライアントによって指定されたより値以下でなければなりません。 そして、クライアントは、OACKで指定されたサイズを使用しなければならないか、または転送を終えるためにエラーコード8と共にERRORパケットを送らなければなりません。
The rules for determining the final packet are unchanged from [1]. The reception of a data packet with a data length less than the negotiated blocksize is the final packet. If the blocksize is greater than the amount of data to be transfered, the first packet is the final packet. If the amount of data to be transfered is an integral multiple of the blocksize, an extra data packet containing no data is sent to end the transfer.
最終的なパケットを決定するための規則は[1]から変わりがありません。 データの長さが交渉がblocksizeされるより少ないデータ・パケットのレセプションは最終的なパケットです。 blocksizeする、transferedされるべきデータ量よりすばらしくて、最初のパケットは最終的なパケットです。 transferedされるべきデータ量が不可欠の倍数である、blocksizeする、転送を終わらせるためにデータを全く含まない付加的なデータ・パケットを送ります。
Proof of Concept
概念の証拠
Performance tests were run on the prototype implementation using a variety of block sizes. The tests were run on a lightly loaded Ethernet, between two HP-UX 9000, in "octet" mode, on 2.25MB files. The average (5x) transfer times for paths with (g-time) and without (n-time) a intermediate gateway are graphed as follows:
パフォーマンステストはさまざまなブロック・サイズを使用するプロトタイプ実装における走行でした。 テストは2.25MBのファイルの「八重奏」モードにおける2ヒューレット・パッカード-UX9000の間の軽くロードされたイーサネットにおける走行でした。 (g-時間)と(n-時間)中間ゲートウェイのない経路への平均した(5x)転送回数は以下の通りグラフで表されます:
Malkin & Harkin Standards Track [Page 2] RFC 2348 TFTP Blocksize Option May 1998
マルキンとハーキンStandardsはTFTP Blocksizeオプション1998年5月にRFC2348を追跡します[2ページ]。
|
37 + g
|
35 +
|
33 +
|
31 +
|
29 +
|
27 +
| g blocksize n-time g-time
25 + --------- ------ ------
s | n 512 23.85 37.05
e 23 + g 1024 16.15 25.65
c | 1428 13.70 23.10
o 21 + 2048 10.90 16.90
n | 4096 6.85 9.65
d 19 + 8192 4.90 6.15
s |
17 + g
| n
15 +
| n
13 +
|
11 + n
| g
9 +
|
7 + n
| g
5 + n
"
0 +------+------+--+---+------+------+---
512 1K | 2K 4K 8K
1428
blocksize (octets)
| 37+g| 35 + | 33 + | 31 + | 29 + | 27 + | g blocksize n-時間g-時間25+--------- ------ ------ s| n512 23.85 37.05e23+g1024 16.15 25.65c| 1428 13.70 23.10 o21+2048 10.90 16.90n| 4096 6.85 9.65 d19+8192 4.906.15秒間| 17+g| n15+| n13+| 11+n| g9+| 7+n| g5+n、「0+、」------+------+--+---+------+------+--- 512 1K| 2 K4K8K1428はblocksizeされます。(八重奏)
The comparisons between transfer times (without a gateway) between the standard 512-octet blocksize and the negotiated blocksizes are:
標準の512八重奏の間の回(ゲートウェイのない)がblocksizeして、交渉がblocksizesする転送での比較は以下の通りです。
1024 2x -32%
1428 2.8x -42%
2048 4x -54%
4096 8x -71%
8192 16x -80%
1024 2x-32%1428 2.8x-42%2048 4x-54%4096 8x-71%8192 16x-80%
Malkin & Harkin Standards Track [Page 3] RFC 2348 TFTP Blocksize Option May 1998
マルキンとハーキンStandardsはTFTP Blocksizeオプション1998年5月にRFC2348を追跡します[3ページ]。
As was anticipated, the transfer time decreases with an increase in blocksize. The reason for the reduction in time is the reduction in the number of packets sent. For example, by increasing the blocksize from 512 octets to 1024 octets, not only are the number of data packets halved, but the number of acknowledgement packets is also halved (along with the number of times the data transmitter must wait for an ACK). A secondary effect is the efficiency gained by reducing the per-packet framing and processing overhead.
予期されていたように、中に増加がある転送時間減少はblocksizeされます。 理由は、時間内にの減少がパケットの数が減少であるので、発信しました。 例えば増加する、blocksizeする、また、データ・パケットの数が半分にされるだけではなく、512の八重奏から1024の八重奏まで、確認応答パケットの数は半分にされます(回数と共に、データ送信機はACKを待たなければなりません)。 副次的効果は1パケットあたりの縁どりと処理オーバヘッドを抑えることによって獲得された効率です。
Of course, if the blocksize exceeds the path MTU, IP fragmentation and reassembly will begin to add more overhead. This will be more noticable the greater the number of gateways in the path.
もちろん、blocksizeする、IPのMTU、断片化、および再アセンブリが頭上でもう少し加え始める経路を超えています。 経路のゲートウェイの数が大きければ大きいほど、これは、より目立つでしょう。
Security Considerations
セキュリティ問題
The basic TFTP protocol has no security mechanism. This is why it has no rename, delete, or file overwrite capabilities. This document does not add any security to TFTP; however, the specified extensions do not add any additional security risks.
基本的なTFTPプロトコルには、セキュリティー対策が全くありません。 これはそれがいいえが重ね書き能力を改名するか、削除するか、またはファイルするのをさせる理由です。 このドキュメントは少しのセキュリティもTFTPに加えません。 しかしながら、指定された拡大は少しの追加担保危険も加えません。
References
参照
[1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350,
October 1992.
[1]Sollins、K.、「TFTPプロトコル(改正2)」、STD33、RFC1350、1992年10月。
[2] Malkin, G., and A. Harkin, "TFTP Option Extension", RFC 2347,
May 1998.
[2] マルキン、G.、およびA.ハーキン、「TFTPオプション拡張子」、RFC2347は1998がそうするかもしれません。
Authors' Addresses
作者のアドレス
Gary Scott Malkin Bay Networks 8 Federal Street Billerica, MA 10821
ビルリカ、ゲーリースコットマルキンベイネットワークス8の連邦政府の通りMA 10821
Phone: (978) 916-4237 EMail: gmalkin@baynetworks.com
以下に電話をしてください。 (978) 916-4237 メールしてください: gmalkin@baynetworks.com
Art Harkin Networked Computing Division Hewlett-Packard Company 19420 Homestead Road MS 43LN Cupertino, CA 95014
事業部ヒューレット・パッカード会社19420を計算するハーキンがネットワークでつないだ芸術が道路MS43LNカルパチーノ、カリフォルニア 95014に入植します。
Phone: (408) 447-3755 EMail: ash@cup.hp.com
以下に電話をしてください。 (408) 447-3755 メールしてください: ash@cup.hp.com
Malkin & Harkin Standards Track [Page 4] RFC 2348 TFTP Blocksize Option May 1998
マルキンとハーキンStandardsはTFTP Blocksizeオプション1998年5月にRFC2348を追跡します[4ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Malkin & Harkin Standards Track [Page 5]
マルキンとハーキン標準化過程[5ページ]
一覧
スポンサーリンク
