Bah. I just found out that Limewire got 32% of a file and then choked.

The file is 12K (yes, you read that right, 12K) long.

Why the foo didn't the remote host send the whole damn thing in one chunk? The maximum size of a network packet is 64K, easily big enough to hold the whole thing plus overhead, for god's sake. I can think of no rational reason for this, save someone wasn't thinking of anything but mp3s when they optimized this sucker. Except I am unsure that qualifies as a rational reason.

On a side note, I see a lot of downloads broken off at suspiciously round numbers. 32 and 33 and 67 and 25 and 50 and 75%, for instance. I can't see why random network outages or people just happening to go offline would disporportionately often happen when a transfer's fraction completed could be expressed in small integers. But human beings have such preferences. Is there a client out there that deliberately serves a fixed, small integer fraction of a file (e.g. a third or a quarter) and then boots a host to the end of the queue, and then forgets them so they end up with "Blah blah ... 32% complete ... Awaiting Sources"? If so, can it be detected and banned with some undocumented config option? (Filtering by vendor/version regex matching seems to be a curiously lacking but desirable feature, given that all client programs are emphatically NOT created equal!) Especially as it obviously cluelessly applies this policy to files large and small, and even small enough that the whole remainder of the file could have been sent in place of the damned busy signal used to terminate the download!

If the intent is to let people requesting small files get them quickly without being stuck interminably behind several multi-meg uploaders, isn't an express lane a superior solution? Especially as interrupting a transfer, in my experience, carries a measurable risk of damaging the file not incurred if it's continued to completion. Also, IMO when an upload fails, for some time the uploader should hold the slot open for resuming the same file. There should be a good faith effort to follow through and complete the transfer "through rain or snow or sleet or gloom of night" -- or routing glitches or one host's dynamic IP changing or one's dialup connection dying and needing redialing. As it stands, it's common for a download to fail partway through and uncommon to ever resume it successfully, at least not without extensive searching and requerying. And limewire makes you restart the client to requery a file again if it doesn't find it the first time...