RFC783 日本語訳
0783 TFTP Protocol (revision 2). K.R. Sollins. June 1981. (Format: TXT=23522 bytes) (Obsoletes IEN 133) (Obsoleted by RFC1350) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. R. Sollins
Request for Comments: 783 MIT
June, 1981
Updates: IEN 133
R.Sollinsがコメントのために要求するワーキンググループK.をネットワークでつないでください: 783 MIT1981年6月は以下をアップデートします。 IEN133
THE TFTP PROTOCOL (REVISION 2)
TFTPプロトコル(改正2)
Summary
概要
TFTP is a very simple protocol used to transfer files. It is from
TFTPはファイルを移すのに使用される非常に簡単なプロトコルです。 それはあります。
this that its name comes, Trivial File Transfer Protocol or TFTP. Each
名前が来させるこれ、トリビアル・ファイル転送プロトコルまたはTFTP。 それぞれ
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.
デザイン決定のいくつか後ろの理由。
ACKNOWLEDGEMENTS
承認
The protocol was originally designed by Noel Chiappa, and was
プロトコルは、元々クリスマスChiappaによって設計されて、ありました。
redesigned by him, Bob Baldwin and Dave Clark, with comments from Steve
コメントで彼、ボブ・ボールドウィン、およびデーブ・クラークによってスティーブから再設計されます。
Szymanski. The current revision of the document includes modifications
Szymanski。 ドキュメントの現在の改正は変更を含んでいます。
stemming from discussions with and suggestions from Larry Allen, Noel
ラリー・アレン、クリスマスからの議論と提案から、由来します。
Chiappa, Dave Clark, Geoff Cooper, Mike Greenwald, Liza Martin, David
Chiappa、デーブ・クラーク、ジェフ・クーパー、マイク・グリーンワルド、ライザ・マーチン、デヴィッド
Reed, Craig Milo Rogers (of UCS-ISI), Kathy Yellick, and the author.
リード、クレイグ・ミロ・ロジャース(UCS-ISIの)、キャシーYellick、および作者。
The acknowledgement and retransmission scheme was inspired by TCP, and
そして承認と「再-トランスミッション」体系がTCPによって奮い立たせられた。
the error mechanism was suggested by PARC's EFTP abort message.
誤りメカニズムはPARCのEFTPアボートメッセージによって示されました。
This research was supported by the Advanced Research Projects Agency of
この研究はAdvanced Research Projects Agencyによってサポートされました。
the Department of Defense and was monitored by the Office of Naval
国防総省、Navalのオフィスによってモニターされました。
Research under contract number N00014-75-C-0661.
契約番号の下でN00014 75C0661について研究してください。
2
2
1. Purpose
1. 目的
TFTP is a simple protocol to transfer files, and therefore was named
TFTPはファイルを移すのが簡単であるプロトコルであり、したがって、命名されました。
the Trivial File Transfer Protocol or TFTP. It has been implemented on
トリビアル・ファイル転送プロトコルかTFTP。 それは実装されました。
top of the Internet User Datagram protocol (UDP or Datagram) [2] so it
[2] したがって、インターネットUserデータグラムの先端はそれについて議定書の中で述べます(UDPかデータグラム)。
may be used to move files between machines on different networks
異なったネットワークでファイルをマシンの間に動かすのに使用されるかもしれません。
implementing UDP. (This should not exlude the possibility of
UDPを実装します。 (これは可能性をexludeするべきではありません。
implementing TFTP on top of other datagram protocols.) It is designed
他のデータグラムプロトコルの上でTFTPを実装します。) それは設計されています。
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
通常のFTPの特徴。 それができる唯一のことが読んで、書くことです。
files (or mail) from/to a remote server. It cannot list directories,
/からリモート. それがそうすることができないサーバまでのファイル(または、メール)はディレクトリをリストアップします。
and currently has no provisions for user authentication. In common with
そして、現在、ユーザー認証のための条項を全く持っていません。 in common with
other Internet protocols, it passes 8 bit bytes of data.
他のインターネットプロトコルであり、それは8ビットのバイトのデータを通過します。
1 2
Three modes of transfer are currently supported: netascii ; octet ,
転送の3つの方法が現在サポートされる1 2: netascii。 八重奏
raw 8 bit bytes; mail, netascii characters sent to a user rather than a
生の8はバイトに噛み付きました。 メール、キャラクタがaよりむしろユーザに送ったnetascii
file. Additional modes can be defined by pairs of cooperating hosts.
ファイルしてください。 協力関係を持っているホストの組は追加モードを定義できます。
_______________ 1 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. 2 This replaces the "binary" mode of previous versions of this
_______________ 1 これは変更が「テルネット・プロトコル仕様」[3]で指定されている状態で「米国の標準の情報交換用符号」[1]で定義されるようにASCIIです。 それが8ビットのASCIIであることに注意してください。 "netascii"という用語は、ASCIIのこの特定のバージョンを意味するのにこのドキュメント中で使用されるでしょう。 2 これはこの旧バージョンの「2進」のモードを置き換えます。
3
3
2. Overview of the Protocol
2. プロトコルの概要
Any transsfer begins with a request to read or write a file, which also
またどんなtranssferもファイルを読むか、または書くという要求で始まる、どの。
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
接続を開きます、そして、512の固定長ブロックでファイルを送ります。
bytes. Each data packet contains one block of data, and must be
バイト。 各データ・パケットは、1ブロックのデータを含んでいて、あるに違いありません。
acknowledged by an acknowledgment packet before the next packet can be
次のパケットが承認できる前に確認応答パケットによって承認されます。
sent. A data packet of less than 512 bytes signals termination of a
送る。 aの512バイト未満の信号終了のデータ・パケット
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
その無くなっているパケットを再送してください。 送付者はちょうど1つのパケットをオンに保たなければなりません。
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
転送にかかわっているのは、考えられた送付者と受信機です。 1つは発信します。
data and receives acknowledgments, the other sends acknowledgments and
そしてデータ、受信する、承認であり、もう片方が承認を送る。
receives data.
データを受け取ります。
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
再送されない、(すなわち、a TFTPサーバかユーザが終わるかもしれません。
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 caused by three types of
誤りパケットは失われました。 誤りは3つのタイプによって引き起こされます。
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
ネットワークで遅れか複製で説明される、(例えば、不当
4
4
formed packet), and losing access to a necessary resource (e.g., disk
形成パケット)、必要なリソースへの損をしているアクセス、(例えば、ディスク
full or access denied during a transfer).
転送の間の完全かアクセス拒否)
TFTP recognizes only one error condition that does not cause
TFTPはそれが引き起こさない1つのエラー条件だけを認識します。
termination, the source port of a received packet being incorrect. In
終了、不正確な容認されたパケットのソースポート。 コネ
this case, an error packet is sent to the originating host.
このケースであり、誤りパケットを送信元ホストに送ります。
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
言及されたTFTPがデータグラムの上で実装されるように設計されているので
protocol. Since Datagram is implemented on the Internet protocol,
議定書を作ってください。 以来、データグラムはインターネットプロトコルで実装されます。
packets will have an Internet header, a Datagram header, and a TFTP
パケットには、インターネット・ヘッダー、データグラムヘッダー、およびTFTPがあるでしょう。
header. Additionally, the packets may have a header (LNI, ARPA header,
ヘッダー。 さらに、パケットにはヘッダーがあるかもしれない、(LNI、ARPAヘッダー
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
図3-1 パケットのコンテンツの注文は以下の通りになるでしょう。 ローカルの媒体
header, if used, Internet header, Datagram header, TFTP header, followed
ヘッダー、使用されるなら、インターネット・ヘッダー(データグラムヘッダー、TFTPヘッダー)は続きました。
by the remainder of the TFTP packet. (This may or may not be data
TFTPパケットの残りで。 (これはデータであるかもしれません。
depending on the type of packet as specified in the TFTP header.) TFTP
TFTPヘッダーの指定されるとしてのパケットのタイプに頼っています。) 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
付録で書式を与える、)、TFTPと長さの分野で、使用されます。
reflects the size of the TFTP packet. The transfer identifiers (TID's)
TFTPパケットのサイズを反映します。 転送識別子(TIDのもの)
5
5
used by TFTP are passed to the Datagram layer to be used as ports;
使用されて、TFTPはポートとして使用されるためにデータグラム層に渡されます。
therefore they must be between 0 and 65,535. The initialization of
したがって、それらは、0〜6万5535であるに違いありません。 初期化
TID's is discussed in the section on initial connection protocol.
初期の接続プロトコルのセクションでTIDのものについて議論します。
The TFTP header consists of a 2 byte opcode field which indicates the
TFTPヘッダーが2バイトのopcode分野から成る、どれ、表示
packet's type (e.g., DATA, ERROR, etc.) These opcodes and the formats
パケットのタイプ(例えば、DATA、ERRORなど) これらのopcodesと形式
of the various types of packets are discussed further in the section on
様々では、セクションで、より詳しくパケットのタイプについて議論する、オン
TFTP packets.
TFTPパケット。
Figure 3-1: Order of Headers
図3-1: ヘッダーの注文
---------------------------------------------------
| Local Medium | Internet | Datagram | TFTP |
---------------------------------------------------
--------------------------------------------------- | ローカルの媒体| インターネット| データグラム| TFTP| ---------------------------------------------------
4. Initial Connection Protocol
4. 初期の接続プロトコル
A transfer is established by sending a request (WRQ to write onto a
転送が要求を送ることによって設立される、(aに書くWRQ
foreign file system, or RRQ to read from it), and receiving a positive
外部ファイルシステム、またはそれから読むRRQ、)、正数を受け取ること。
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
1。 aへの応答があると要求に書く正数
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
承認されるデータ・パケット。) 次に、回答が誤りパケットであるなら
6
6
the request has been denied.
要求は否定されました。
In order to create a connection, each end of the connection chooses a
接続を創造するために、接続の各端はaを選びます。
TID for itself, to be used for the duration of that connection. The
それ自体のためのTID、その接続の持続時間に使用されるために。 The
TID's chosen for a connection should be randomly chosen, so that the
接続に選ばれたTIDのものは手当たりしだいに選ばれるべきであり、そうはそれです。
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
まさしくその安値はそうですか? あらゆるパケットがそれによる2TIDのものを関連づけました。
ends of the connection, the source TID and the destination TID. These
接続、ソースTID、および目的地TIDの端。 これら
TID's are handed to the supporting UDP (or other datagram protocol) as
TIDのものはサポートUDP(または、他のデータグラムプロトコル)に手渡されます。
the source and destination ports. A requesting host chooses its source
ソースと仕向港。 要求ホストはソースを選びます。
TID as described above, and sends its initial request to the known TID
初期の要求を知られているTIDに上で説明されて、送るTID
69 decimal (105 octal) on the serving host. The response to the
69 給仕のホストで10進です(105 8進)。 応答
request, under normal operation, uses a TID chosen by the server as its
要求(下の通常の操作)がサーバによって選ばれたTIDを使用する、それ
source TID and the TID chosen for the previous message by the requestor
要請者によって前のメッセージに選ばれたソースTIDとTID
as its destination TID. The two chosen TID's are then used for the
目的地TIDとして。 そして、2の選ばれたTIDは使用されました。
remainder of the transfer.
転送の残り。
As an example, the following shows the steps used to establish a
例、ステップがaを証明するのに使用した以下のショーとして
connection to write a file. Note that WRQ, ACK, and DATA are the names
ファイルを書く接続。 WRQ、ACK、およびDATAが名前であることに注意してください。
of the write request, acknowledgment, and data types of packets
パケットに関する要求、承認、およびデータ型を書いてください。
respectively. The appendix contains a similar example for reading a
それぞれ。 付録はaを読むための同様の例を含んでいます。
file.
ファイルしてください。
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がある)を送ります。
7
7
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
Host Aは1の一連番号と共にパケットを送ることができます。 次で
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
ソースTIDはステップ1と2で同意された値に合っています。 aです。
source TID does not match, the packet should be discarded as erroneously
ソースTIDは合わないで、パケットとして誤って捨てられるべきです。
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
TFTPが事実上パケットを受ける場合にだけ、これができます。
incorrect TID. If the supporting protocols do not allow it, this
不正確なTID。 サポートプロトコルがそれを許容しないならこれ
particular error condition will not arise.
特定のエラー条件は起こらないでしょう。
The following example demonstrates a correct operation of the protocol
以下の例はプロトコルの正しい操作を示します。
in which the above situation can occur. Host A sends a request to host
上の状況は起こることができます。 ホストAは主催する要求を送ります。
B. Somewhere in the network, the request packet is duplicated, and as a
B。 ネットワークにおけるどこかに、リクエスト・パケットは、コピーされて、aとしてそうします。
result two acknowledgments are returned to host A, with different TID's
2つの承認が異なったTIDのものと共にAを接待するために返される結果
chosen on host B in response to the two requests. When the first
ホストBの上で2つの要求に対応して選ばれています。 時は1日です。
response arrives, host A continues the connection. When the second
応答は到着して、ホストAは接続を続けています。 時は2番目です。
response to the request arrives, it should be rejected, but there is no
要求への応答は到着して、そこで拒絶されているのが、ノーであるということであるべきです。
reason to terminate the first connection. Therefore, if different TID's
推論して、最初の接続を終えてください。 したがって、異なったTIDであることのもの
are chosen for the two connections on host B and host A checks the
ホストBとホストAチェックの2つの接続に選ばれています。
source TID's of the messages it receives, the first connection can be
ソースTIDのそれが受け取るメッセージ、最初の接続のものはそうであることができます。
maintained while the second is rejected by returning an error packet.
2番目は誤りパケットを返すことによって、拒絶されますが、維持されます。
8
8
5. TFTP Packets
5. TFTPパケット
TFTP supports five types of packets, all of which have been mentioned
TFTPは5つのタイプのパケットをサポートします。そのすべてが言及されました。
above:
上:
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
パケットのTFTPヘッダーはそれに関連しているopcodeを含んでいます。
packet.
パケット。
Figure 5-1: RRQ/WRQ packet
図5-1: RRQ/WRQパケット
2 bytes string 1 byte string 1 byte
------------------------------------------------
| Opcode | Filename | 0 | Mode | 0 |
------------------------------------------------
2バイトは1バイトのストリングを1バイト結びます。------------------------------------------------ | Opcode| ファイル名| 0 | モード| 0 | ------------------------------------------------
RRQ and WRQ packets (opcodes 1 and 2 respectively) have the format
RRQとWRQパケット(それぞれ1と2をopcodesする)には、形式があります。
shown in Figure 5-1. The file name is a sequence of bytes in netascii
図5-1では、目立ちます。 ファイル名はnetasciiのバイトの系列です。
terminated by a zero byte. The mode field contains the string
バイトをゼロで終えました。 モード分野はストリングを含んでいます。
"netascii", "octet", or "mail" (or any comibnation of upper and lower
"netascii"、「八重奏」、または「メール」、(上下のどんなcomibnation
case, such as "NETASCII", NetAscii", etc.) in netascii indicating the
netasciiで示している「"NETASCII"、NetAsciiなどのケース」など
three modes defined in the protocol. A host which receives netascii
プロトコルで定義された3つのモード。 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
マシンの8ビットの形式にはあるファイルを移す、どれ
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
形式は、より一般的な8ビットの形式と、それですが、シングルを持っています。
9
9
chosen. For example, on a DEC-20, a 36 bit machine, this is four 8-bit
選ばれる。 例えば、12月-20、36ビットのマシンでは、これは4 8ビットです。
bytes to a word with four bits of breakage. If a host receives a octet
折損の4ビットがある単語へのバイト。 ホストが八重奏を受けるなら
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
オリジナル。 aに代わってメール受取人の名前をモード用途に郵送してください。
file and must begin with a WRQ. Otherwise it is identical to netascii
ファイルして、WRQと共に始まらなければなりません。 さもなければ、それは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
" username@hostname "。 2番目のフォームが使用されているなら、それはオプションを許容します。
of mail forwarding by a relay computer.
リレーコンピュータによるメール転送について。
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
ケース。 例えば、1つはストレージサーバを組立てるかもしれません。いいえがあります。
reason that such a machine needs to translate netascii into its own form
そのようなマシンが、それ自身のフォームにnetasciiを翻訳する必要がある理由
of text. Rather, the sender might send files in netascii, but the
テキストについて。 しかし、むしろ、送付者はnetasciiのファイルを送るかもしれません。
storage server might simply store them without translation in 8-bit
ストレージサーバは8ビットにおける翻訳なしでそれらを単に保存するかもしれません。
format. Another such situation is a problem that currently exists on
形式。 別のそのような状況はそれが現在存在する問題です。
DEC-20 systems. Neither netascii nor octet accesses all the bits in a
12月-20台のシステムnetasciiも八重奏もaですべてのビットにアクセスするというわけではありません。
word. One might create a special mode for such a machine which read all
言い表します。 1つはすべてを読んだそのようなマシンのために特別なモードを作成するかもしれません。
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
8ビットの形式。 そのようなファイルが置き場から取られるときそれ
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
モードはTFTPで指定されましたが、1つはこれと互換性があるでしょう。
10
10
specification.
仕様。
It is also possible to define other modes for cooperating pairs of
また、それも他の協力組モードを定義するのにおいて可能です。
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.
それは、これらのモードを定義するか、または名前をそれらに割り当てるでしょう。
Figure 5-2: DATA packet
図5-2: DATAパケット
2 bytes 2 bytes n bytes
----------------------------------
| Opcode | Block # | Data |
----------------------------------
n2バイト2バイトバイト---------------------------------- | Opcode| ブロック#| データ| ----------------------------------
Data is actually transferred in DATA packets depicted in Figure 5-2.
実際に図5-2に表現されたDATAパケットでデータを移します。
DATA packets (opcode = 3) have a block number and data field. The block
DATAパケット(opcode=3)には、街区番号とデータ・フィールドがあります。 ブロック
numbers on data packets begin with one and increase by one for each new
データ・パケットの数は、1で始まって、それぞれのために新しい状態で1つ増加します。
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
分野がゼロ〜512バイト長からあります。 それが512バイト長であるなら
block is not the last block of data; if it is from zero to 511 bytes
ブロックはデータの最後のブロックではありません。 それがゼロから511バイトに来ているなら
long, it signals the end of the transfer. (See the section on Normal
切望してください、そして、それは転送の終わりに合図します。 (Normalの上のセクションを見てください。
Termination for details.)
詳細のための終了。)
All packets other than those used for termination are acknowledged
終了に使用されるもの以外のすべてのパケットが承認されます。
individually unless a timeout occurs. Sending a DATA packet is an
個別である、タイムアウトが起こらない場合。 DATAパケットを送るのは、そうです。
acknowledgment for the ACK packet of the previous DATA packet. The WRQ
前のDATAパケットのACKパケットのための承認。 WRQ
and DATA packets are acknowledged by ACK or ERROR packets, while RRQ and
そしてそして、DATAパケットがRRQである間、ACKかERRORパケットによって承認される。
11
11
Figure 5-3: ACK packet
図5-3: ACKパケット
2 bytes 2 bytes
---------------------
| Opcode | Block # |
---------------------
2バイト2バイト--------------------- | Opcode| ブロック#| ---------------------
ACK packets are acknowledged by DATA or ERROR packets. Figure 5-3
ACKパケットはDATAかERRORパケットによって承認されます。 図5-3
depicts an ACK packet; the opcode is 4. The block number in an ACK
ACKパケットについて表現します。 opcodeは4です。 ACKの街区番号
echoes the block number of the DATA packet being acknowledged. A WRQ is
承認されていて、DATAパケットの街区番号を反響します。 WRQはそうです。
acknowledged with an ACK packet having a block number of zero.
ゼロの街区番号を持っているACKパケットで、承認されています。
Figure 5-4: ERROR packet
図5-4: ERRORパケット
2 bytes 2 bytes string 1 byte
-----------------------------------------
| Opcode | ErrorCode | ErrMsg | 0 |
-----------------------------------------
2バイト2バイトは1バイトを結びます。----------------------------------------- | Opcode| ErrorCode| ErrMsg| 0 | -----------------------------------------
An ERROR packet (opcode 5) takes the form depicted in Figure 5-4. An
ERRORパケット(opcode5)は図5-4に表現された形を取ります。 1
ERROR packet can be the acknowledgment of any other type of packet. The
ERRORパケットはいかなる他のタイプのパケットの承認であるかもしれません。 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.
メッセージは、人間の消費で意図して、netasciiにあるべきです。
Like all other strings, it is terminated with a zero byte.
他のすべてのストリングのように、それはゼロで終えられます。バイト。
12
12
6. Normal Termination
6. 正常終了
The end of a transfer is marked by a DATA packet that contains between
転送の終わりはそれが間に含むDATAパケットによって示されます。
0 and 511 bytes of data (i.e. Datagram length < 516). This packet is
0と511バイトのデータ(すなわち、データグラム長さ<516)。 このパケットはそうです。
acknowledged by an ACK packet like all other DATA packets. The host
ACKパケットで、他のすべてのDATAパケットのように、承認されています。 ホスト
acknowledging the final DATA packet may terminate its side of the
最終的なDATAパケットを承認すると、側は終えられるかもしれません。
connection on sending the final ACK. On the other hand, dallying is
最終的なACKを送るときの接続。 他方では、ふざけるのはそうです。
encouraged. This means that the host sending the final ACK will wait
奨励にされる。 これは、最終的なACKを送るホストが待つことを意味します。
for a while before terminating in order to retransmit the final ACK if
しばらく、最終的なACKを再送するために終わること。
it has been lost. The acknowledger will know that the ACK has been lost
それは失われました。 acknowledgerは、ACKがなくされたのを知るでしょう。
if it receives the final DATA packet again. The host sending the last
再び最終的なDATAパケットを受けるなら。 最終を送るホスト
DATA must retransmit it until the packet is acknowledged or the sending
DATAはパケットが承認されていて発信になるまでそれを再送しなければなりません。
host times out. If the response is an ACK, the transmission was
外で回を接待してください。 応答がACKであるなら、トランスミッションはACKでした。
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
acknowledgerかネットワークがそうするものが完成された後に首尾よく完成されます。
experienced a problem. It is also possible in this case that the
問題を経験しました。 また、それもこの場合可能である、それ
transfer was unsuccessful. In any case, the connection has been closed.
転送は失敗していました。 どのような場合でも、接続は閉店しました。
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
移してください、そして、次に、ERRORパケット(opcode5)を送ります。 これはaであるだけです。
courtesy since it will not be retransmitted or acknowledged, so it may
そうするかもしれないのはそのように再送されないか、または認められないで以来の礼儀
never be received. Timeouts must also be used to detect errors.
決して受け取らないでください。 また、誤りを検出するのにタイムアウトを使用しなければなりません。
13
13
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
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バイトのストリングなしでOp#Formatを1バイトタイプしてください。----------------------------------------------- RRQ/| 01/02 | ファイル名| 0 | モード| 0 | WRQ----------------------------------------------- n2バイト2バイトバイト--------------------------------- データ| 03 | ブロック#| データ| --------------------------------- 2バイト2バイト------------------- ACK| 04 | ブロック#| -------------------- 2バイト2バイトは1バイトを結びます。---------------------------------------- 誤り| 05 | ErrorCode| ErrMsg| 0 | ----------------------------------------
14
14
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に送ります。
15
15
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.
値のMeaning0Notが定義されて、(もしあれば)のエラーメッセージを見てください。 1 ファイルが見つからない。 2は違反にアクセスします。 完全か配分が超えていた3ディスク。 4 不法なTFTP操作。 未知の5はIDを移します。 6ファイルは既に存在しています。 そのような7人のユーザでない。
16
16
3
Internet User Datagram Header [2]
3インターネットユーザデータグラムヘッダー[2]
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 packet after Datagram header.
データグラムヘッダーの後のパケットのバイトの長さのNumber。
4
Checksum Reference 2 describes rules for computing checksum.
Field contains zero if unused.
4 チェックサムReference2はチェックサムを計算するための規則について説明します。 未使用であるなら、分野はゼロを含んでいます。
Note: TFTP passes transfer identifiers (TID's) to the Internet User
以下に注意してください。 TFTPは転送識別子(TIDのもの)をインターネットUserに通過します。
Datagram protocol to be used as the source and destination ports.
ソースと仕向港として使用されるべきデータグラムプロトコル。
_______________ 3 This has been included only for convenience. TFTP need not be implemented on top of the Internet User Datagram Protocol. 4 The implementor of this should be sure that the correct algorithm is used here.
_______________ 3 これは便宜のためだけに含まれています。 TFTPはインターネットユーザー・データグラム・プロトコルの上で実装される必要はありません。 4 この作成者は正しいアルゴリズムがここで使用されるのを確信しているべきです。
17
17
References
参照
[1] USA Standard Code for Information Interchange, USASI X3.4-
[1] 米国の標準の情報交換用符号、USASI X3.4
1968.
1968.
[2] Postel, Jon., "User Datagram Protocol," RFC768, August 28,
[2] ポステル、ジョン、「ユーザー・データグラム・プロトコル」、RFC768、8月28日
1980.
1980.
[3] "Telnet Protocol Specification," RFC764, June, 1980.
[3] 「telnetプロトコル仕様」、RFC764、1980年6月。
18
18
一覧
スポンサーリンク
