tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: tftp protocol

>>      Files larger than 33488896 octets (65535 blocks) cannot be
>>      transferred without client and server supporting blocksize
>>      negotiation (RFCs 2347 and 2348).
> Actually...  I suspect that the BUGS statement is in actual fact
> wrong, if it implies that the protocol spec makes it impossible to
> transfer files larger than 32MiB using tftp with the default block
> size of 512 bytes.

I don't suppose you considered actually checking whether this was true
or not?

My reading is that there is a limit, of approximately 32 megs, but not
quite any of the above figures.  DATA and ACK packets have only two
octets of block number, but block numbers begin with 1, not 0 (block
number 0 is used for acking write requests); also, the final data
packet must have <512 octets, so the limit is actually 33553919 octets.

The number in the quoted manpage excerpt is wrong.  33488896 is
512*(65536-128), which seems weird, until you notice it is also
511*65536; I suspect someone just got careless about which number 1
needed to be subtracted from.

In principle there is no reason the block-number field in the protocol
couldn't be the file block number modulo 65536.  But that's not how I
read RFC1350; it is silent on the subject, saying only that the block
numbers "begin with one and increase by one for each new block of
data".  Since a two-octet field cannot increase past 65535, this means,
logically speaking, that there cannot be a next block after block

> The "block numbers" in the tftp protocol are actually not designed to
> do "random access" in the server-side file, it's designed to
> distinguish between duplicate blocks and new blocks at the client.

What's your basis for this statement?  I don't see anything in 1350
even hinting at the intent behind the block-number field, and I'm
wondering what I've missed.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML      
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Home | Main Index | Thread Index | Old Index