Finish even at an exact block boundary
04The final DATA packet has fewer than 512 data bytes. A file whose size is an exact multiple of 512 therefore needs an extra empty DATA block.
In this encouraged dallying example, repeated empty DATA 3 causes another ACK 3. It arrives and the sender finishes; the file remains exactly 1024 bytes.
Source for this drawing: RFC 1350 · Read RFC section 6 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A short data field ends the file; acknowledge it too.
- A full 512-byte data field is nonterminal. Zero through 511 data bytes mark the final DATA packet, which is acknowledged normally.
- For a 1024-byte octet file, blocks 1 and 2 each contain 512 data bytes. Block 3 has zero data bytes, yet still has the four-byte TFTP DATA header. An empty file starts with zero-data block 1.
- The final acknowledger may terminate immediately; dallying is encouraged so it can re-ACK a repeated final DATA. The final DATA sender must retransmit until acknowledged or it gives up on timeout.
Lengths are separated: TFTP DATA length = 4 + data length; UDP length = 8 + TFTP length. A zero-data final packet is TFTP 4 / UDP 12 bytes. A full block is TFTP 516 / UDP 524. Verified errata 4971 and 7167 conflict on the §6 parenthesis; the unambiguous 0–511 data rule and UDP header arithmetic are shown instead of copying the ambiguous phrase. If the sender finally gives up, receiver completion can be uncertain.
Read the RFC section ↗