Announce a write size and let the receiver decide
04For a write, the sending client already knows the octet count. It places that size in WRQ, and an accepting server echoes it in OACK.
Separate branch from receipt of WRQ: capacity is 600000, so the server chooses ERROR code 3 instead of OACK. No DATA transfer or successful allocation is implied.
Source for this drawing: RFC 2349 · Read RFC source: Transfer Size · p.3 ↗
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 WRQ specifies the file size in octets; an accepting OACK echoes the size.
- A WRQ specifies the file size in octets; an accepting OACK echoes the size.
- If the file is too large for the server to handle, it may abort with ERROR code 3.
- For a write OACK, client DATA 1 confirms and begins transfer (RFC2347); there is no extra client ACK 0.
The file name and capacities are fictional; 673312 is the RFC’s worked example. All file examples use octet mode, so no netascii conversion accounting is inferred. Storage checks are advisory capacity decisions, not authorization.
Read the RFC section ↗