Visual RFC.
ALL RFCs / RFC 2348
Read the RFC ↗
RFC 2348 / TFTP BLOCK NEGOTIATION

Finish with a shorter DATA payload

04

The receiver recognizes the final DATA packet when its data length is less than the negotiated block size. A full-sized block does not signal the end, even when it exhausts the file.

RFC 2348 · Final DATA rule · p.2EXAMPLE
4 / 4
Finish with a shorter DATA payloadTFTP Blocksize Option. DATA3 carries no data after the two full blocks, so 0 is less than 1024. It still has a four-octet TFTP header; ACK3 acknowledges the final packet.A shorter payload identifies the endClientServerDATA3 · 0 data octets#3header:4Zero data · header still presentACK30 < 1024: final DATAExact2048-byte file needs this third DATARFC2348 · chapter 4 · state 4 · selected example
04
Send and acknowledge a zero-data packet

DATA3 carries no data after the two full blocks, so 0 is less than 1024. It still has a four-octet TFTP header; ACK3 acknowledges the final packet.

Source for this drawing: RFC 2348 · Read RFC source: Final DATA rule · p.2 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
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.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

The final test compares data length with the negotiated block size, not total TFTP length or total UDP length. Final DATA still needs its ACK; sender success depends on that acknowledgment or the base timeout/retry outcome.

  • The final test compares data length with the negotiated block size, not total TFTP length or total UDP length. Final DATA still needs its ACK; sender success depends on that acknowledgment or the base timeout/retry outcome.
  • For 1536 octets with block size 1024, DATA1 carries 1024 and DATA2 carries 512. The first is full; the second is final because 512 is less than 1024.
  • For an exact multiple such as 2048 at block size 1024, two full DATA packets are followed by an extra zero-data packet. That last packet still has the four-octet TFTP header and its block number.
  • A file smaller than the negotiated size ends in its first DATA; an empty octet-mode file sends zero-data DATA1. Payload counts avoid the conflicting RFC 1350 errata 4971/7167 parenthetical datagram-length thresholds. Block-number rollover and netascii conversion are outside this selected example.
  • If the final ACK is lost, base TFTP can retransmit final DATA and repeat its ACK; a timeout without confirmation can leave the sender uncertain. This option does not define a new retry count or timer.
DETAILS

A selected octet-mode example, not a complete TFTP implementation. One octet is an eight-bit byte. Follow the actual RFC source and its companion option-negotiation rules.

Read the RFC section ↗

All chapters in RFC 2348

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗