Do you mean that the final filesize is a multiple of 500 bytes?  If so, is
that before or after gunzipping?  (I do not see this behavior, myself.  
1.5's xmisc.tgz, for example, FTP'ed as 12321 bytes, and gunzipped to
51200 bytes.)


Or do you mean that the TCP connection is sending/receiving blocks of no
more than 500 bytes at a time?  I haven't attempted to sort out how large
of a block is used when I FTP files, but (at the risk of insulting your
intelligence), you ARE aware that every system between you and
ftp.netbsd.org (inclusive) imposes an MTU---the smallest of which is going
to determine how big of a block can be received in one chunk by you from
ftp.netbsd.org---right?

I _think_ that NetBSD has support for discovering the largest MTU between
two points.  (``Path MTU discovery.'')

The idea, as I understand it, is to avoid having a large outbound block
repeatedly fractured en route.  (Suppose A->B has an MTU of 1500; B->C has
MUT of 1024, and C->D has MTU of 1000.  Ignore headers for the sake of
simplicity, and remember that, in general, the blocks cannot be
reassembled en route---only at their destination can they be
recombined.  Imagine how the sender might naively send 3000 bytes (2
1500-byte blocks), and contrast to the case where the sender realizes that
the path has an MTU of 1000 bytes.)

With or without path MTU discovery, the largest block in this example will
be 1000 bytes.  With MTU discovery, the sender can pick a smaller
block-size that optimizes the network usage (given the MTU to the target).

In this light, that your files are always multiples of 500 bytes (until
the last, necessarily short, packet is received) means that someone's MTU
along the route is just big enough for 500 data bytes + headers.

If I'm hosed on this, of course, or if NetBSD doesn't actually support
path MTU discovery, I'm sure that someone will correct me.  (^&

As for why different MTU's may be used...one link may want the largest MTU
that the hardware supports.  Another may want one that results in nice
(2^N) buffer sizes.  Yet another may want data blocks (before appending
header info) to be nice (2^N) sizes.  Then again, some may choose sizes
based on interactive requirements (NetBSD's SLIP MTU is an example of this
last---though it actually causes severe performance degradation when
connecting to an Amiga, at least when the Amiga is using AmiTCP/IP).

The short answer, then, may simply be: You receive files in blocks of 500
bytes because blocks of 500 bytes is the most efficient way for you to
download from ftp.netbsd.org.


Or did you mean some 3rd alternative, which I haven't even considered?


  "I probably don't know what I'm talking about." --rauch@eecs.ukans.edu