Confirm a read with ACK block zero
03In a read, the server sends file data to the client. Before that first data block, the client accepts OACK by sending ACK with block number 0.
Client ACK block 1 acknowledges DATA block 1. This completes the chosen short-file exchange; ACK 0 and ACK 1 had different roles.
Source for this drawing: RFC 2347 · Read RFC source: Negotiation Protocol · p.4 ↗
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.
For RRQ with accepted options: client RRQ, server OACK, client ACK block 0, then server DATA block 1. OACK is opcode 6; ACK is opcode 4, with a separate two-octet block field.
- For RRQ with accepted options: client RRQ, server OACK, client ACK block 0, then server DATA block 1. OACK is opcode 6; ACK is opcode 4, with a separate two-octet block field.
- ACK 0 confirms the read request’s OACK; it does not acknowledge a fictitious DATA block 0. Actual file data starts at block 1.
- The example accepts blksize 512 and then receives 300 data octets in DATA block 1. That is a short final block, followed by client ACK 1. Other transfers can require more blocks.
- TFTP uses UDP: an initial request goes to server port 69 and the server selects a transfer port for its reply. Later packets use the selected transfer identifiers. Negotiation adds no authentication, encryption or new packet-loss recovery model.
Fictional picnic.txt in octet mode; chosen sizes and values are examples. Comparisons reset state. This RFC uses lowercase must/should/may; those distinctions are retained. No real files or UDP transfers are used.
Read the RFC section ↗