As per Relevance of the word specified, we have this rfc below:
Network Working Group G.
Request for Comments: 1783 Xylogics, Inc
Updates: 1350 A.
Category: Standards Track Hewlett Packard Co
March 1995
TFTP Blocksize
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
The Trivial File Transfer Protocol [1] is a simple, lock-step,
transfer protocol which allows a client to get or put a file onto
remote host. One of its primary uses is the booting of
nodes on a Local Area Network. TFTP is used because it is
simple to implement in a small node's limited ROM space. However
the choice of a 512-byte blocksize is not the most efficient for
on a LAN whose MTU may 1500 bytes or greater
This document describes a TFTP option which allows the client
server to negotiate a blocksize more applicable to the
medium. The TFTP Option Extension mechanism is described in [2].
Blocksize Option
The TFTP Read Request or Write Request packet is modified to
the blocksize option as follows
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
| opc |filename| 0 | mode | 0 | blksize| 0 | #octets| 0 |
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
The opcode field contains either a 1, for Read Requests, or 2,
for Write Requests, as defined in [1].
The name of the file to be read or written, as defined in [1].
This is a NULL-terminated field
Malkin & Harkin [Page 1]
RFC 1783 TFTP Blocksize Option March 1995
The mode of the file transfer: "netascii", "octet", or "mail",
as defined in [1]. This is a NULL-terminated field
The Blocksize option, "blksize" (case insensitive). This is
NULL-terminated field
#
The number of octets in a block, specified in ASCII.
values range between "8" and "65464" octets, inclusive.
is a NULL-terminated field
For example
+-------+--------+---+--------+---+--------+---+--------+---+
| 1 | foobar | 0 | binary | 0 | blksize| 0 | 1432 | 0 |
+-------+--------+---+--------+---+--------+---+--------+---+
is a Read Request, for the file named "foobar", in binary
mode, with a block size of 1432 bytes (Ethernet MTU, less the UDP
IP header lengths).
If the server is willing to accept the blocksize option, it sends
Option Acknowledgment (OACK) to the client. The specified value
be less than or equal to the value specified by the client.
client must then either use the size specified in the OACK, or
an ERROR packet, with error code 8, to terminate the transfer
The rules for determining the final packet are unchanged from [1].
The reception of a data packet with a data length less than
negotiated blocksize is the final packet. If the blocksize
greater than the size of the packet, the first packet is the
packet. If amount of data to be transfered is an integral
of the blocksize, an extra data packet containing no data is sent
end the transfer
Malkin & Harkin [Page 2]
RFC 1783 TFTP Blocksize Option March 1995
Proof of
Performance tests were run on the prototype implementation using
variety of block sizes. The tests were run on a lightly
Ethernet, between two HP-UX 9000, in "octet" mode, on 2.25MB files
The average (5x) transfer times for paths with (g-time) and
(n-time) a intermediate gateway are graphed as follows
|
37 +
|
35 +
|
33 +
|
31 +
|
29 +
|
27 +
| g blocksize n-time g-
25 + --------- ------ ------
s | n 512 23.85 37.05
e 23 + g 1024 16.15 25.65
c | 1432 13.70 23.10
o 21 + 2048 10.90 16.90
n | 4096 6.85 9.65
d 19 + 8192 4.90 6.15
s |
17 +
|
15 +
|
13 +
|
11 +
|
9 +
|
7 +
|
5 +
"
0 +------+------+--+---+------+------+---
512 1K | 2K 4K 8
1432
blocksize (bytes
Malkin & Harkin [Page 3]
RFC 1783 TFTP Blocksize Option March 1995
The comparisons between transfer times (without a gateway)
the standard 512-byte blocksize and the negotiated blocksizes are
1024 2x -32%
1432 2.8x -42%
2048 4x -54%
4096 8x -71%
8192 16x -80%
As was anticipated, the transfer time decreases with an increase
blocksize. The reason for the reduction in time is the reduction
the number of packets sent. For example, by increasing the
from 512 bytes to 1024 bytes, not only are the number of data
halved, but the number of acknowledgement packets is also
(along with the number of times the data transmitter must wait for
ACK). A secondary effect is the efficiency gained by reducing
per-packet framing and processing overhead
Of course, if the blocksize exceeds the path MTU, IP
and reassembly will begin to add more overhead. This will be
noticable the greater the number of gateways in the path
Security
Security issues are not discussed in this memo
[1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350,
MIT, July 1992.
[2] Malkin, G., and A. Harkin, "TFTP Option Extension", RFC 1782,
Xylogics, Inc., Hewlett Packard Co., March 1995.
Malkin & Harkin [Page 4]
RFC 1783 TFTP Blocksize Option March 1995
Authors'
Gary Scott
Xylogics, Inc
53 Third
Burlington, MA 01803
Phone: (617) 272-8140
EMail: gmalkin@xylogics.
Art
Internet Services
Information Networks
19420 Homestead Road MS 43
Cupertino, CA 95014
Phone: (408) 447-3755
EMail: ash@cup.hp.
Malkin & Harkin [Page 5]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
