Confirm a write by sending DATA block one
04In a write, the client sends file data to the server. The first DATA packet, using negotiated values, also confirms the server’s OACK. There is no extra client ACK 0.
Server ACK 1 acknowledges the data. No extra client ACK 0 belongs in this exchange; the chosen short transfer is complete.
Source for this drawing: RFC 2347 · Read RFC source: Negotiation Protocol and Examples · pp.4–5 ↗
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.
The example’s first packet is WRQ, not RRQ. Its opcode 2 and the client-to-server DATA direction already indicate a write.
Read the updated RFC section ↗For WRQ with accepted options: client WRQ, server OACK, client DATA block 1, then server ACK block 1. Do not copy the RRQ confirmation sequence into this write exchange.
- For WRQ with accepted options: client WRQ, server OACK, client DATA block 1, then server ACK block 1. Do not copy the RRQ confirmation sequence into this write exchange.
- The example’s WRQ opcode is 2. Verified erratum 1258 corrects the printed Write Request example’s label from RRQ to WRQ; the opcode stays 2.
- After accepting OACK, the client uses only its returned options and values. Here blksize=512 is accepted and the client sends a chosen 300-octet final DATA block.
- The server’s ACK 1 acknowledges actual DATA block 1. This negotiation extension does not grant file permissions or authenticate either peer; base TFTP constraints still apply.
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 ↗