rfc783 (2 of 2)
Ron Natalie <ron>
ron at brl-adm.ARPA
Tue May 13 22:52:58 AEST 1986
11
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
2 bytes 2 bytes n bytes
----------------------------------
| Opcode | Block # | 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.)
All packets other than those used for termination are acknowledged
individually unless a timeout occurs. Sending a DATA packet is an
acknowledgment for the ACK packet of the previous DATA packet. The WRQ
and DATA packets are acknowledged by ACK or ERROR packets, while RRQ and
12
Figure 5-3: ACK packet
2 bytes 2 bytes
---------------------
| Opcode | Block # |
---------------------
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.
Figure 5-4: ERROR packet
2 bytes 2 bytes string 1 byte
-----------------------------------------
| Opcode | ErrorCode | ErrMsg | 0 |
-----------------------------------------
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.
13
6. Normal Termination
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.
7. Premature Termination
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.
14
I. Appendix
Order of Headers
2 bytes
----------------------------------------------------------
| Local Medium | Internet | Datagram | TFTP Opcode |
----------------------------------------------------------
TFTP Formats
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 |
----------------------------------------
15
Initial Connection Protocol for reading a file
1. Host A sends a "RRQ" to host B with source= A's TID,
destination= 69.
2. Host B sends a "DATA" (with block number= 1) to host A with
source= B's TID, destination= A's TID.
16
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.
17
3
Internet User Datagram Header [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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Values of Fields
Source Port Picked by originator of packet.
Dest. Port Picked by destination machine (69 for RRQ or WRQ).
Length Number of bytes in packet after Datagram header.
4
Checksum Reference 2 describes rules for computing checksum.
Field contains zero if unused.
Note: TFTP passes transfer identifiers (TID's) to the Internet 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.
18
References
[1] USA Standard Code for Information Interchange, USASI X3.4-
1968.
[2] Postel, Jon., "User Datagram Protocol," RFC768, August 28,
1980.
[3] "Telnet Protocol Specification," RFC764, June, 1980.
More information about the Mod.sources.doc
mailing list