RFC1350 日本語訳
1350 The TFTP Protocol (Revision 2). K. Sollins. July 1992. (Format: TXT=24599 bytes) (Obsoletes RFC0783) (Updated by RFC1782, RFC1783, RFC1784, RFC1785, RFC2347, RFC2348, RFC2349) (Also STD0033) (Status: STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. Sollins Request For Comments: 1350 MIT STD: 33 July 1992 Obsoletes: RFC 783
Sollinsがコメントのために要求するワーキンググループK.をネットワークでつないでください: 1350MIT STD: 33 1992年7月は以下を時代遅れにします。 RFC783
THE TFTP PROTOCOL (REVISION 2)
TFTPプロトコル(改正2)
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Summary
概要
TFTP is a very simple protocol used to transfer files. It is from this that its name comes, Trivial File Transfer Protocol or TFTP. Each nonterminal packet is acknowledged separately. This document describes the protocol and its types of packets. The document also explains the reasons behind some of the design decisions.
TFTPはファイルを移すのに使用される非常に簡単なプロトコルです。 それは名前が来させるこれ、トリビアル・ファイル転送プロトコルまたはTFTPから来ています。 それぞれの非終端記号パケットは別々に承認されます。 このドキュメントはプロトコルとそのパケットのタイプについて説明します。 また、ドキュメントで、デザイン決定のいくつか後ろで理由がわかります。
Acknowlegements
Acknowlegements
The protocol was originally designed by Noel Chiappa, and was redesigned by him, Bob Baldwin and Dave Clark, with comments from Steve Szymanski. The current revision of the document includes modifications stemming from discussions with and suggestions from Larry Allen, Noel Chiappa, Dave Clark, Geoff Cooper, Mike Greenwald, Liza Martin, David Reed, Craig Milo Rogers (of USC-ISI), Kathy Yellick, and the author. The acknowledgement and retransmission scheme was inspired by TCP, and the error mechanism was suggested by PARC's EFTP abort message.
プロトコルは、元々クリスマスChiappaによって設計されて、彼、ボブ・ボールドウィン、およびデーブ・クラークによって再設計されました、スティーブSzymanskiからのコメントで。 ドキュメントの現在の改正はラリー・アレン、クリスマスChiappa、デーブ・クラーク、ジェフ・クーパー、マイク・グリーンワルド、ライザ・マーチン、デヴィッド・リード、クレイグ・ミロ・ロジャース(USC-ISIの)、キャシーYellick、および作者からの議論と提案による変更を含んでいます。 承認と「再-トランスミッション」体系はTCPによって奮い立たせられました、そして、誤りメカニズムはPARCのEFTPアボートメッセージによって勧められました。
The May, 1992 revision to fix the "Sorcerer's Apprentice" protocol bug [4] and other minor document problems was done by Noel Chiappa.
1992年5月に、プロトコルバグ[4]と他の小さい方のドキュメント問題を「魔術師の見習い」に固定する改正がクリスマスChiappaによって行われました。
This research was supported by the Advanced Research Projects Agency of the Department of Defense and was monitored by the Office of Naval Research under contract number N00014-75-C-0661.
この研究は、国防総省のAdvanced Research Projects Agencyによってサポートされて、契約番号N00014 75C0661の下で海軍研究事務所によってモニターされました。
1. Purpose
1. 目的
TFTP is a simple protocol to transfer files, and therefore was named the Trivial File Transfer Protocol or TFTP. It has been implemented on top of the Internet User Datagram protocol (UDP or Datagram) [2]
TFTPはファイルを移すのが簡単であるプロトコルであり、したがって、トリビアル・ファイル転送プロトコルかTFTPと命名されました。 それはインターネットUserデータグラムプロトコル(UDPかデータグラム)の上で実装されました。[2]
Sollins [Page 1] RFC 1350 TFTP Revision 2 July 1992
Sollins[1ページ]RFC1350TFTP改正1992年7月2日
so it may be used to move files between machines on different networks implementing UDP. (This should not exclude the possibility of implementing TFTP on top of other datagram protocols.) It is designed to be small and easy to implement. Therefore, it lacks most of the features of a regular FTP. The only thing it can do is read and write files (or mail) from/to a remote server. It cannot list directories, and currently has no provisions for user authentication. In common with other Internet protocols, it passes 8 bit bytes of data.
それで、それは、UDPを実装しながら異なったネットワークでファイルをマシンの間に動かすのに使用されるかもしれません。 (これは他のデータグラムプロトコルの上でTFTPを実装する可能性を除くべきではありません。) それは、小さくて、実装するのが簡単であるように設計されています。 したがって、それは通常のFTPの特徴の大部分を欠いています。 それができる唯一のことが/からリモートサーバまでファイル(または、メール)を読み書きすることです。それには、ディレクトリをリストアップできないで、現在、ユーザー認証のための条項が全くありません。 他のインターネットプロトコルと共用して、それは8ビットのバイトのデータを通過します。
Three modes of transfer are currently supported: netascii (This is ascii as defined in "USA Standard Code for Information Interchange" [1] with the modifications specified in "Telnet Protocol Specification" [3].) Note that it is 8 bit ascii. The term "netascii" will be used throughout this document to mean this particular version of ascii.); octet (This replaces the "binary" mode of previous versions of this document.) raw 8 bit bytes; mail, netascii characters sent to a user rather than a file. (The mail mode is obsolete and should not be implemented or used.) Additional modes can be defined by pairs of cooperating hosts.
転送の3つの方法が現在、サポートされます: netascii(これは変更が「テルネット・プロトコル仕様」[3]で指定されている状態で「米国の標準の情報交換用符号」[1]で定義されるようにASCIIです。) それが8ビットのASCIIであることに注意してください。 "netascii"がASCIIのこの特定のバージョンを意味するのにこのドキュメント中で使用される用語)、。 八重奏(これはこのドキュメントの旧バージョンの「2進」のモードを置き換えます。)の生の8はバイトに噛み付きました。 メール、キャラクタがファイルよりむしろユーザに送ったnetascii。 (メールモードを時代遅れであり、実装するべきではありませんし、また使用するべきではありません。) 協力関係を持っているホストの組は追加モードを定義できます。
Reference [4] (section 4.2) should be consulted for further valuable directives and suggestions on TFTP.
参照[4](セクション4.2)はさらなる貴重な指示と提案のためにTFTPに関して相談されるべきです。
2. Overview of the Protocol
2. プロトコルの概要
Any transfer begins with a request to read or write a file, which also serves to request a connection. If the server grants the request, the connection is opened and the file is sent in fixed length blocks of 512 bytes. Each data packet contains one block of data, and must be acknowledged by an acknowledgment packet before the next packet can be sent. A data packet of less than 512 bytes signals termination of a transfer. If a packet gets lost in the network, the intended recipient will timeout and may retransmit his last packet (which may be data or an acknowledgment), thus causing the sender of the lost packet to retransmit that lost packet. The sender has to keep just one packet on hand for retransmission, since the lock step acknowledgment guarantees that all older packets have been received. Notice that both machines involved in a transfer are considered senders and receivers. One sends data and receives acknowledgments, the other sends acknowledgments and receives data.
どんな転送もまた、役立つファイルを読むか、または書くという要求で接続を要求し始めます。 サーバが要求を承諾するなら、接続を開きます、そして、512バイトの固定長ブロックでファイルを送ります。 各データ・パケットを1ブロックのデータを含んでいて、次のパケットを送ることができる前に確認応答パケットは承認しなければなりません。 512バイト未満のデータ・パケットは転送の終了に合図します。 パケットが失せるなら、ネットワーク、受取人がそうする意図では、それを再送するためにタイムアウトと彼の最後のパケット(データか承認であるかもしれない)を再送するかもしれなくて、その結果、無くなっているパケットの送付者を引き起こすと、パケットは損をしました。 送付者はちょうど1つのパケットを「再-トランスミッション」のためにいるように保たなければなりません、ロックステップ承認が、すべての、より古いパケットが受け取られたのを保証するので。 転送にかかわる両方のマシンが送付者と受信機であると考えられるのに注意してください。 1つがデータを送って、承認を受けて、もう片方が、承認を送って、データを受け取ります。
Most errors cause termination of the connection. An error is signalled by sending an error packet. This packet is not acknowledged, and not retransmitted (i.e., a TFTP server or user may terminate after sending an error message), so the other end of the connection may not get it. Therefore timeouts are used to detect such a termination when the error packet has been lost. Errors are
ほとんどの誤りが接続の終了を引き起こします。 誤りパケットを送ることによって、誤りは合図されます。 このパケットが承認されないで、また再送されないので(エラーメッセージを送った後に、すなわち、TFTPサーバかユーザが終わるかもしれません)、接続のもう一方の端はそれを得ないかもしれません。 したがって、タイムアウトは、誤りパケットが失われたとき、そのような終了を検出するのに使用されます。 誤りはそうです。
Sollins [Page 2] RFC 1350 TFTP Revision 2 July 1992
Sollins[2ページ]RFC1350TFTP改正1992年7月2日
caused by three types of events: not being able to satisfy the request (e.g., file not found, access violation, or no such user), receiving a packet which cannot be explained by a delay or duplication in the network (e.g., an incorrectly formed packet), and losing access to a necessary resource (e.g., disk full or access denied during a transfer).
3つのタイプのイベントで、引き起こされます: 要望(例えば、ファイルが見つからない、違反にアクセスしますが、どんなそのようなユーザもアクセスしない)に応じることができないで、ネットワーク(例えば、不当に形成されたパケット)で遅れか複製で説明できないパケットを受けて、必要なリソース(転送の間の例えば、ディスク満かアクセス拒否)にアクセスを失っています。
TFTP recognizes only one error condition that does not cause termination, the source port of a received packet being incorrect. In this case, an error packet is sent to the originating host.
TFTPは容認されたパケットのソースポートが不正確であることで、終了を引き起こさない1つのエラー条件だけを認識します。 この場合、誤りパケットを送信元ホストに送ります。
This protocol is very restrictive, in order to simplify implementation. For example, the fixed length blocks make allocation straight forward, and the lock step acknowledgement provides flow control and eliminates the need to reorder incoming data packets.
このプロトコルは、実装を簡素化するために非常に制限しています。 例えば、固定長ブロックで配分が前方にまっすぐになって、ロックステップ承認は、追加注文受信データパケットにフロー制御を提供して、必要性を排除します。
3. Relation to other Protocols
3. 他のプロトコルとの関係
As mentioned TFTP is designed to be implemented on top of the Datagram protocol (UDP). Since Datagram is implemented on the Internet protocol, packets will have an Internet header, a Datagram header, and a TFTP header. Additionally, the packets may have a header (LNI, ARPA header, etc.) to allow them through the local transport medium. As shown in Figure 3-1, the order of the contents of a packet will be: local medium header, if used, Internet header, Datagram header, TFTP header, followed by the remainder of the TFTP packet. (This may or may not be data depending on the type of packet as specified in the TFTP header.) TFTP does not specify any of the values in the Internet header. On the other hand, the source and destination port fields of the Datagram header (its format is given in the appendix) are used by TFTP and the length field reflects the size of the TFTP packet. The transfer identifiers (TID's) used by TFTP are passed to the Datagram layer to be used as ports; therefore they must be between 0 and 65,535. The initialization of TID's is discussed in the section on initial connection protocol.
言及されるように、TFTPはデータグラムプロトコル(UDP)の上で実装されるように設計されています。 データグラムがインターネットプロトコルで実装されるので、パケットには、インターネット・ヘッダー、データグラムヘッダー、およびTFTPヘッダーがあるでしょう。 さらに、パケットには、ローカル運送媒体にそれらの通ることを許すヘッダー(LNI、ARPAヘッダーなど)があるかもしれません。 図3-1に示されるように、パケットのコンテンツの注文は以下の通りになるでしょう。 地元の中型のヘッダー、使用されるなら、インターネット・ヘッダー(データグラムヘッダー、TFTPヘッダー)はTFTPパケットの残りで続きました。 (これはTFTPヘッダーの指定されるとしてのパケットのタイプに頼るデータであるかもしれません。) TFTPはインターネット・ヘッダーで値のいずれも指定しません。 他方では、データグラムヘッダー(付録で書式を与える)のソースと仕向港分野はTFTPが使用されます、そして、長さの分野はTFTPパケットのサイズを反映します。 (TIDのもの)がTFTPで使用した転送識別子はポートとして使用されるためにデータグラム層に通過されます。 したがって、それらは、0〜6万5535であるに違いありません。 初期の接続プロトコルのセクションでTIDの初期化について議論します。
The TFTP header consists of a 2 byte opcode field which indicates the packet's type (e.g., DATA, ERROR, etc.) These opcodes and the formats of the various types of packets are discussed further in the section on TFTP packets.
TFTPヘッダーはパケットのタイプ(例えば、DATA、ERRORなど)を示す2バイトのopcode分野から成ります。 TFTPパケットの上のセクションで、より詳しく様々なタイプのパケットのこれらのopcodesと形式について議論します。
Sollins [Page 3] RFC 1350 TFTP Revision 2 July 1992
Sollins[3ページ]RFC1350TFTP改正1992年7月2日
--------------------------------------------------- | Local Medium | Internet | Datagram | TFTP | ---------------------------------------------------
--------------------------------------------------- | ローカルの媒体| インターネット| データグラム| TFTP| ---------------------------------------------------
Figure 3-1: Order of Headers
図3-1: ヘッダーの注文
4. Initial Connection Protocol
4. 初期の接続プロトコル
A transfer is established by sending a request (WRQ to write onto a foreign file system, or RRQ to read from it), and receiving a positive reply, an acknowledgment packet for write, or the first data packet for read. In general an acknowledgment packet will contain the block number of the data packet being acknowledged. Each data packet has associated with it a block number; block numbers are consecutive and begin with one. Since the positive response to a write request is an acknowledgment packet, in this special case the block number will be zero. (Normally, since an acknowledgment packet is acknowledging a data packet, the acknowledgment packet will contain the block number of the data packet being acknowledged.) If the reply is an error packet, then the request has been denied.
転送は設立されます。(外部ファイルシステム、またはそれから読むRRQに書くWRQ)、および積極的な返事を受ける確認応答パケットをaが要求する発信が書く、または、読書のための最初のデータ・パケット。 一般に、承認されていて、確認応答パケットはデータ・パケットの街区番号を含むでしょう。 各データ・パケットは街区番号をそれに関連づけました。 街区番号は、連続して、1で始まります。 aへの積極的な応答が書くので、要求が確認応答パケットである、この特別な場合では、街区番号はゼロになるでしょう。 (承認されていて、確認応答パケットがデータ・パケットを承認しているので、通常、確認応答パケットはデータ・パケットの街区番号を含むでしょう。) 回答が誤りパケットであるなら、要求は否定されました。
In order to create a connection, each end of the connection chooses a TID for itself, to be used for the duration of that connection. The TID's chosen for a connection should be randomly chosen, so that the probability that the same number is chosen twice in immediate succession is very low. Every packet has associated with it the two TID's of the ends of the connection, the source TID and the destination TID. These TID's are handed to the supporting UDP (or other datagram protocol) as the source and destination ports. A requesting host chooses its source TID as described above, and sends its initial request to the known TID 69 decimal (105 octal) on the serving host. The response to the request, under normal operation, uses a TID chosen by the server as its source TID and the TID chosen for the previous message by the requestor as its destination TID. The two chosen TID's are then used for the remainder of the transfer.
接続を創造して、接続の各端は、その接続の持続時間に使用されるためにそれ自体のためのTIDを選びます。 接続に選ばれたTIDのものは手当たりしだいに選ばれるべきです、同じ数が即座の継承で二度選ばれているという確率が非常に低いように。 あらゆるパケットが2TIDの接続、ソースTID、および目的地TIDの端のものをそれに関連づけました。 TIDのこれらのものはソースと仕向港としてサポートUDP(または、他のデータグラムプロトコル)に手渡されます。 要求ホストは給仕のホストの知られているTID69小数(105 8進)に初期の要求を上で説明されて、送るソースTIDを選びます。 通常の操作で、要求への応答はソースTIDとしてサーバによって選ばれたTIDと目的地TIDとして要請者によって前のメッセージに選ばれたTIDを使用します。 そして、選ばれたTIDの2ものは転送の残りに使用されます。
As an example, the following shows the steps used to establish a connection to write a file. Note that WRQ, ACK, and DATA are the names of the write request, acknowledgment, and data types of packets respectively. The appendix contains a similar example for reading a file.
例、ステップが以前はよくそうしていた以下のショーとして、取引関係を築いて、ファイルを書いてください。 WRQ、ACK、およびDATAが名前であることに注意してください、それぞれパケットに関する要求、承認、およびデータ型を書いてください。 付録はファイルを読むための同様の例を含んでいます。
Sollins [Page 4] RFC 1350 TFTP Revision 2 July 1992
Sollins[4ページ]RFC1350TFTP改正1992年7月2日
1. Host A sends a "WRQ" to host B with source= A's TID, destination= 69.
1. ホストAはAのソース=TID、目的地=69のホストBに"WRQ"を送ります。
2. Host B sends a "ACK" (with block number= 0) to host A with source= B's TID, destination= A's TID.
2. ホストBはソース=ビーズTID、Aの目的地=TIDのホストAに"ACK"(街区番号=0がある)を送ります。
At this point the connection has been established and the first data packet can be sent by Host A with a sequence number of 1. In the next step, and in all succeeding steps, the hosts should make sure that the source TID matches the value that was agreed on in steps 1 and 2. If a source TID does not match, the packet should be discarded as erroneously sent from somewhere else. An error packet should be sent to the source of the incorrect packet, while not disturbing the transfer. This can be done only if the TFTP in fact receives a packet with an incorrect TID. If the supporting protocols do not allow it, this particular error condition will not arise.
ここに、接続を確立しました、そして、Host Aは1の一連番号と共に最初のデータ・パケットを送ることができます。 次のステップ、および続くすべてのステップでは、ホストは、ソースTIDがステップ1と2で同意された値に合っているのを確実にするべきです。 ソースTIDが合っていないなら、パケットは他のどこかから誤って送るように捨てられるべきです。 転送を擾乱していない間、不正確なパケットの源に誤りパケットを送るべきです。 TFTPが不正確なTIDと共にパケットを事実上受ける場合にだけ、これができます。 サポートプロトコルがそれを許容しないと、この特定のエラー条件は起こらないでしょう。
The following example demonstrates a correct operation of the protocol in which the above situation can occur. Host A sends a request to host B. Somewhere in the network, the request packet is duplicated, and as a result two acknowledgments are returned to host A, with different TID's chosen on host B in response to the two requests. When the first response arrives, host A continues the connection. When the second response to the request arrives, it should be rejected, but there is no reason to terminate the first connection. Therefore, if different TID's are chosen for the two connections on host B and host A checks the source TID's of the messages it receives, the first connection can be maintained while the second is rejected by returning an error packet.
以下の例は上の状況が起こることができるプロトコルの正しい操作を示します。 ホストAはネットワークのホストB.Somewhereに要求を送ります、そして、リクエスト・パケットをコピーします、そして、その結果、2つの承認をホストAに返します、異なったTIDのものがホストBの上で2つの要求に対応して選ばれている状態で。 最初の応答が到着するとき、ホストAは接続を続けています。 要求への2番目の応答が到着すると、それは拒絶されるべきですが、最初の接続を終える理由が全くありません。 したがって、異なったTIDのものがホストBにおける2つの接続に選ばれていて、ホストAがソースTIDのそれが受け取るメッセージのものをチェックするなら、2番目が誤りパケットを返すことによって拒絶されている間、最初の接続を維持できます。
5. TFTP Packets
5. TFTPパケット
TFTP supports five types of packets, all of which have been mentioned above:
TFTPは5つのタイプのパケットをサポートします。そのすべてが以下の上で言及されました。
opcode operation 1 Read request (RRQ) 2 Write request (WRQ) 3 Data (DATA) 4 Acknowledgment (ACK) 5 Error (ERROR)
opcode操作1Readは、(RRQ)2Writeが(WRQ)3Data(DATA)4Acknowledgment(ACK)5Errorを要求するよう要求します。(誤り)
The TFTP header of a packet contains the opcode associated with that packet.
パケットのTFTPヘッダーはそのパケットに関連しているopcodeを含んでいます。
Sollins [Page 5] RFC 1350 TFTP Revision 2 July 1992
Sollins[5ページ]RFC1350TFTP改正1992年7月2日
2 bytes string 1 byte string 1 byte ------------------------------------------------ | Opcode | Filename | 0 | Mode | 0 | ------------------------------------------------
2バイトは1バイトのストリングを1バイト結びます。------------------------------------------------ | Opcode| ファイル名| 0 | モード| 0 | ------------------------------------------------
Figure 5-1: RRQ/WRQ packet
図5-1: RRQ/WRQパケット
RRQ and WRQ packets (opcodes 1 and 2 respectively) have the format shown in Figure 5-1. The file name is a sequence of bytes in netascii terminated by a zero byte. The mode field contains the string "netascii", "octet", or "mail" (or any combination of upper and lower case, such as "NETASCII", NetAscii", etc.) in netascii indicating the three modes defined in the protocol. A host which receives netascii mode data must translate the data to its own format. Octet mode is used to transfer a file that is in the 8-bit format of the machine from which the file is being transferred. It is assumed that each type of machine has a single 8-bit format that is more common, and that that format is chosen. For example, on a DEC-20, a 36 bit machine, this is four 8-bit bytes to a word with four bits of breakage. If a host receives a octet file and then returns it, the returned file must be identical to the original. Mail mode uses the name of a mail recipient in place of a file and must begin with a WRQ. Otherwise it is identical to netascii mode. The mail recipient string should be of the form "username" or "username@hostname". If the second form is used, it allows the option of mail forwarding by a relay computer.
RRQとWRQパケット(それぞれ1と2をopcodesする)には、図5-1に示された書式があります。 ファイル名はnetasciiのバイトの系列がバイトをゼロで終えたということです。 「モード分野がストリング"netascii"、「八重奏」、または「メール」を含んでいる、("NETASCII"、NetAsciiなどの大文字と小文字のどんな組み合わせ、も」、など) プロトコルで定義された3つのモードを示すnetasciiで。 netasciiモードデータを受け取るホストはそれ自身の形式にデータを翻訳しなければなりません。 八重奏モードは、ファイルが移されているマシンの8ビットの形式にはあるファイルを移すのに使用されます。 それぞれのタイプのマシンには、より一般的な8ビットのただ一つの形式があって、その形式が選ばれていると思われます。 例えば、12月-20、36ビットのマシンでは、これは折損の4ビットがある単語への8ビットの4バイトです。 ホストが八重奏ファイルを受け取って、次に、それを返すなら、返されたファイルはオリジナルと同じであるに違いありません。 メールモードは、ファイルに代わってメール受取人の名前を使用して、WRQと共に始まらなければなりません。 さもなければ、それはnetasciiモードと同じです。 メール受取人ストリングはフォームの「ユーザ名」か" username@hostname "のものであるはずです。 2番目のフォームが使用されているなら、それはリレーコンピュータでメール転送のオプションを許容します。
The discussion above assumes that both the sender and recipient are operating in the same mode, but there is no reason that this has to be the case. For example, one might build a storage server. There is no reason that such a machine needs to translate netascii into its own form of text. Rather, the sender might send files in netascii, but the storage server might simply store them without translation in 8-bit format. Another such situation is a problem that currently exists on DEC-20 systems. Neither netascii nor octet accesses all the bits in a word. One might create a special mode for such a machine which read all the bits in a word, but in which the receiver stored the information in 8-bit format. When such a file is retrieved from the storage site, it must be restored to its original form to be useful, so the reverse mode must also be implemented. The user site will have to remember some information to achieve this. In both of these examples, the request packets would specify octet mode to the foreign host, but the local host would be in some other mode. No such machine or application specific modes have been specified in TFTP, but one would be compatible with this specification.
上の議論は、送付者と受取人の両方が同じモードで働いていますが、これがそうでなければならない理由が全くないと仮定します。 例えば、1つはストレージサーバを組立てるかもしれません。そのようなマシンが、それ自身のテキストのフォームにnetasciiを翻訳する必要がある理由が全くありません。 むしろ、送付者はnetasciiのファイルを送るかもしれませんが、ストレージサーバは翻訳なしで8ビットの形式でそれらを単に保存するかもしれません。 別のそのような状況は現在12月-20台のシステムの上に存在する問題です。netasciiも八重奏も一言で言えばすべてのビットにアクセスするというわけではありません。 1つは一言で言えばすべてのビットを読みましたが、受信機が8ビットの形式で情報を保存したそのようなマシンのために特別なモードを作成するかもしれません。 そのようなファイルが置き場から取られるとき、役に立つようにそれを原型に回復しなければならないので、また、逆のモードを実装しなければなりません。 ユーザの現場は、これを達成するために何らかの情報を覚えていなければならないでしょう。 これらの例の両方では、リクエスト・パケットは八重奏モードを異種宿主に指定するでしょうが、ローカル・ホストはある他のモードでいるでしょう。 そのようなどんなマシンもアプリケーションの特定のモードもTFTPで指定されていませんが、1つはこの仕様と互換性があるでしょう。
It is also possible to define other modes for cooperating pairs of
また、それも他の協力組モードを定義するのにおいて可能です。
Sollins [Page 6] RFC 1350 TFTP Revision 2 July 1992
Sollins[6ページ]RFC1350TFTP改正1992年7月2日
hosts, although this must be done with care. There is no requirement that any other hosts implement these. There is no central authority that will define these modes or assign them names.
これは慎重に完了していなければなりませんが、接待します。 いかなる他のホストもこれらを実装するという要件が全くありません。 これらのモードを定義するか、または名前をそれらに割り当てるどんな主要な権威もありません。
2 bytes 2 bytes n bytes ---------------------------------- | Opcode | Block # | Data | ----------------------------------
n2バイト2バイトバイト---------------------------------- | Opcode| ブロック#| データ| ----------------------------------
Figure 5-2: DATA packet
図5-2: DATAパケット
Data is actually transferred in DATA packets depicted in Figure 5-2. DATA packets (opcode = 3) have a block number and data field. The block numbers on data packets begin with one and increase by one for each new block of data. This restriction allows the program to use a single number to discriminate between new packets and duplicates. The data field is from zero to 512 bytes long. If it is 512 bytes long, the block is not the last block of data; if it is from zero to 511 bytes long, it signals the end of the transfer. (See the section on Normal Termination for details.)
実際に図5-2に表現されたDATAパケットでデータを移します。 DATAパケット(opcode=3)には、街区番号とデータ・フィールドがあります。 データ・パケットの街区番号は、それぞれの新しいデータのために1で始まって、1つ増加します。 この制限で、プログラムは、新しいパケットと写しを区別するのに1つの数を使用できます。 データ・フィールドがゼロ〜512バイト長からあります。 それが512バイト長であるなら、ブロックはデータの最後のブロックではありません。 ゼロ〜511バイト長から来ているなら、それは転送の終わりに合図します。 (詳細に関してNormal Terminationの上のセクションを見てください。)
All packets other than duplicate ACK's and those used for termination are acknowledged unless a timeout occurs [4]. Sending a DATA packet is an acknowledgment for the first ACK packet of the previous DATA packet. The WRQ and DATA packets are acknowledged by ACK or ERROR packets, while RRQ
タイムアウトが起こらない場合、写しACKのもの以外のすべてのパケットと終了に使用されるものは承認されます。[4]。 DATAパケットを送るのは、前のDATAパケットの最初のACKパケットのための承認です。 WRQとDATAパケットはRRQである間、ACKかERRORパケットによって承認されます。
2 bytes 2 bytes --------------------- | Opcode | Block # | ---------------------
2バイト2バイト--------------------- | Opcode| ブロック#| ---------------------
Figure 5-3: ACK packet
図5-3: ACKパケット
and ACK packets are acknowledged by DATA or ERROR packets. Figure 5-3 depicts an ACK packet; the opcode is 4. The block number in an ACK echoes the block number of the DATA packet being acknowledged. A WRQ is acknowledged with an ACK packet having a block number of zero.
そして、ACKパケットはDATAかERRORパケットによって承認されます。 図5-3はACKパケットについて表現します。 opcodeは4です。 承認されていて、ACKの街区番号はDATAパケットの街区番号を反響します。 WRQはゼロの街区番号を持っているACKパケットで承認されます。
Sollins [Page 7] RFC 1350 TFTP Revision 2 July 1992
Sollins[7ページ]RFC1350TFTP改正1992年7月2日
2 bytes 2 bytes string 1 byte ----------------------------------------- | Opcode | ErrorCode | ErrMsg | 0 | -----------------------------------------
2バイト2バイトは1バイトを結びます。----------------------------------------- | Opcode| ErrorCode| ErrMsg| 0 | -----------------------------------------
Figure 5-4: ERROR packet
図5-4: ERRORパケット
An ERROR packet (opcode 5) takes the form depicted in Figure 5-4. An ERROR packet can be the acknowledgment of any other type of packet. The error code is an integer indicating the nature of the error. A table of values and meanings is given in the appendix. (Note that several error codes have been added to this version of this document.) The error message is intended for human consumption, and should be in netascii. Like all other strings, it is terminated with a zero byte.
ERRORパケット(opcode5)は図5-4に表現された形を取ります。 ERRORパケットはいかなる他のタイプのパケットの承認であるかもしれません。 エラーコードは誤りの本質を示す整数です。 付録で値と意味のテーブルを与えます。 (このドキュメントのこのバージョンにいくつかのエラーコードを追加してあることに注意してください。) エラーメッセージは、人間の消費で意図して、netasciiにあるべきです。 他のすべてのストリングのように、それはゼロで終えられます。バイト。
6. Normal Termination
6. 正常終了
The end of a transfer is marked by a DATA packet that contains between 0 and 511 bytes of data (i.e., Datagram length < 516). This packet is acknowledged by an ACK packet like all other DATA packets. The host acknowledging the final DATA packet may terminate its side of the connection on sending the final ACK. On the other hand, dallying is encouraged. This means that the host sending the final ACK will wait for a while before terminating in order to retransmit the final ACK if it has been lost. The acknowledger will know that the ACK has been lost if it receives the final DATA packet again. The host sending the last DATA must retransmit it until the packet is acknowledged or the sending host times out. If the response is an ACK, the transmission was completed successfully. If the sender of the data times out and is not prepared to retransmit any more, the transfer may still have been completed successfully, after which the acknowledger or network may have experienced a problem. It is also possible in this case that the transfer was unsuccessful. In any case, the connection has been closed.
転送の終わりは0〜511バイトのデータ(すなわち、データグラム長さ<516)を含むDATAパケットによって示されます。 このパケットは他のすべてのDATAパケットのようにACKパケットによって承認されます。 最終的なDATAパケットを承認するホストは最終的なACKを送るときの接続の側面を終えるかもしれません。 他方では、ふざけることは奨励されます。 これは、最終的なACKを送るホストがそれが失われたなら最終的なACKを再送するために終わる前にしばらく待つことを意味します。 acknowledgerは、再び最終的なDATAパケットを受けるならACKがなくされたのを知るでしょう。 パケットが承認されているか、または送付ホスト回数が出かけるまで、最後のDATAを送るホストはそれを再送しなければなりません。 応答がACKであるなら、トランスミッションは首尾よく終了しました。 データ回のアウトの送付者である、それ以上再送するように準備されない場合、転送はまだ首尾よく終了していたかもしれません、acknowledgerかネットワークにはあるかもしれないものが問題を経験した後にことです。 また、この場合、転送が失敗していたのも、可能です。 どのような場合でも、接続は閉店しました。
7. Premature Termination
7. 未完熟終了
If a request can not be granted, or some error occurs during the transfer, then an ERROR packet (opcode 5) is sent. This is only a courtesy since it will not be retransmitted or acknowledged, so it may never be received. Timeouts must also be used to detect errors.
要求を承諾できないか、または何らかの誤りが転送の間、発生するなら、ERRORパケット(opcode5)を送ります。 それが再送もされませんし、承認もされないのでこれが礼儀にすぎないので、それを決して受け取らないかもしれません。 また、誤りを検出するのにタイムアウトを使用しなければなりません。
Sollins [Page 8] RFC 1350 TFTP Revision 2 July 1992
Sollins[8ページ]RFC1350TFTP改正1992年7月2日
I. Appendix
I. 付録
Order of Headers
ヘッダーの注文
2 bytes ---------------------------------------------------------- | Local Medium | Internet | Datagram | TFTP Opcode | ----------------------------------------------------------
2バイト---------------------------------------------------------- | ローカルの媒体| インターネット| データグラム| TFTP Opcode| ----------------------------------------------------------
TFTP Formats
TFTP形式
Type Op # Format without header
ヘッダーなしでOp#Formatをタイプしてください。
2 bytes string 1 byte string 1 byte ----------------------------------------------- RRQ/ | 01/02 | Filename | 0 | Mode | 0 | WRQ ----------------------------------------------- 2 bytes 2 bytes n bytes --------------------------------- DATA | 03 | Block # | Data | --------------------------------- 2 bytes 2 bytes ------------------- ACK | 04 | Block # | -------------------- 2 bytes 2 bytes string 1 byte ---------------------------------------- ERROR | 05 | ErrorCode | ErrMsg | 0 | ----------------------------------------
2バイトは1バイトのストリングを1バイト結びます。----------------------------------------------- RRQ/| 01/02 | ファイル名| 0 | モード| 0 | WRQ----------------------------------------------- n2バイト2バイトバイト--------------------------------- データ| 03 | ブロック#| データ| --------------------------------- 2バイト2バイト------------------- ACK| 04 | ブロック#| -------------------- 2バイト2バイトは1バイトを結びます。---------------------------------------- 誤り| 05 | ErrorCode| ErrMsg| 0 | ----------------------------------------
Initial Connection Protocol for reading a file
ファイルを読むための初期のConnectionプロトコル
1. Host A sends a "RRQ" to host B with source= A's TID, destination= 69.
1. ホストAはAのソース=TID、目的地=69のホストBに"RRQ"を送ります。
2. Host B sends a "DATA" (with block number= 1) to host A with source= B's TID, destination= A's TID.
2. ホストBはa「データ」(街区番号=1がある)をソース=ビーズTID、Aの目的地=TIDのホストAに送ります。
Sollins [Page 9] RFC 1350 TFTP Revision 2 July 1992
Sollins[9ページ]RFC1350TFTP改正1992年7月2日
Error Codes
エラーコード
Value Meaning
値の意味
0 Not defined, see error message (if any). 1 File not found. 2 Access violation. 3 Disk full or allocation exceeded. 4 Illegal TFTP operation. 5 Unknown transfer ID. 6 File already exists. 7 No such user.
0が定義されないで、(もしあれば)のエラーメッセージを見てください。 1 ファイルが見つからない。 2は違反にアクセスします。 完全か配分が超えていた3ディスク。 4 不法なTFTP操作。 未知の5はIDを移します。 6ファイルは既に存在しています。 そのような7人のユーザでない。
Internet User Datagram Header [2]
インターネットユーザデータグラムヘッダー[2]
(This has been included only for convenience. TFTP need not be implemented on top of the Internet User Datagram Protocol.)
(これは便宜のためだけに含まれています。 TFTPはインターネットユーザー・データグラム・プロトコルの上で実装される必要はありません。)
Format
形式
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースポート| 仕向港| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Values of Fields
分野の値
Source Port Picked by originator of packet.
パケットの生成元によるソースPort Picked。
Dest. Port Picked by destination machine (69 for RRQ or WRQ).
Dest。 目的地マシン(RRQかWRQのための69)でPickedを移植してください。
Length Number of bytes in UDP packet, including UDP header.
UDPヘッダーを含むUDPパケットのバイトの長さのNumber。
Checksum Reference 2 describes rules for computing checksum. (The implementor of this should be sure that the correct algorithm is used here.) Field contains zero if unused.
Reference2が説明するチェックサムは、チェックサムを計算するために統治されます。 (この作成者は正しいアルゴリズムがここで使用されるのを確信しているべきです。) 未使用であるなら、分野はゼロを含んでいます。
Note: TFTP passes transfer identifiers (TID's) to the Internet User Datagram protocol to be used as the source and destination ports.
以下に注意してください。 TFTPは、ソースと仕向港として使用されるために、転送識別子(TIDのもの)をインターネットUserデータグラムプロトコルに通過します。
Sollins [Page 10] RFC 1350 TFTP Revision 2 July 1992
Sollins[10ページ]RFC1350TFTP改正1992年7月2日
References
参照
[1] USA Standard Code for Information Interchange, USASI X3.4-1968.
[1] 米国の標準の情報交換用符号、USASI X3.4-1968。
[2] Postel, J., "User Datagram Protocol," RFC 768, USC/Information Sciences Institute, 28 August 1980.
[2] ポステル、J.、「ユーザー・データグラム・プロトコル」、RFC768、科学が設けるUSC/情報、1980年8月28日。
[3] Postel, J., "Telnet Protocol Specification," RFC 764, USC/Information Sciences Institute, June, 1980.
[3] ポステル、J.、「telnetプロトコル仕様」、RFC764、科学が1980年6月に設けるUSC/情報。
[4] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", RFC 1123, USC/Information Sciences Institute, October 1989.
[4] ブレーデン、R.、エディタ、「インターネットホストのための要件--、アプリケーションとサポート、」、RFC1123、科学が設けるUSC/情報、10月1989日
Security Considerations
セキュリティ問題
Since TFTP includes no login or access control mechanisms, care must be taken in the rights granted to a TFTP server process so as not to violate the security of the server hosts file system. TFTP is often installed with controls such that only files that have public read access are available via TFTP and writing files via TFTP is disallowed.
TFTPがどんなログインもアクセス管理機構も含んでいないので、サーバー・ホストファイルシステムのセキュリティに違反しないようにTFTPサーバプロセスに与えられた権利で注意しなければなりません。 TFTPがしばしばコントロールでインストールされるので、公衆がアクセスを読むファイルだけがTFTPを通して利用可能です、そして、TFTPを通してファイルを書くのは禁じられます。
Author's Address
作者のアドレス
Karen R. Sollins Massachusetts Institute of Technology Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139-1986
技術の正方形のケンブリッジ、カレンR.Sollinsマサチューセッツ工科大学コンピュータ科学研究所545MA02139-1986
Phone: (617) 253-6006
以下に電話をしてください。 (617) 253-6006
EMail: SOLLINS@LCS.MIT.EDU
メール: SOLLINS@LCS.MIT.EDU
Sollins [Page 11]
Sollins[11ページ]
一覧
スポンサーリンク