[dcc2] Other comments

[myndzi]

> Well that depends on what you're doing. For example, say I'm transfering a
> picture. In a web browser, the picture is displayed as it is downloaded (e.g
> png files in IE). Well, if the packets are sent out of order, you can't do
> that. However, if the packets are sent in order, having the image displayed
> while it downloads would work just fine. And, based on some things I've
> read, there are IRC clients that display images as they are downloaded
> (though I've never found one that actually does it).

But we aren't talking about web browsers here. And in addition to
that, pictures are NOT necessarily displayed partially as they
download...

> Additionally, this makes it inefficient. Since the packets are stored out of
> order, this means you need to do one of three things. Either store the
> unordered contents in memory,  store the unordered contents in a temporary
> file, or treat the file as memory and reorder within the file. Then, when
> the file is done, you can arrange it all, and in cases 1 and 2, either copy
> from memory, or from the tmp file, to the actual file. Now for a 1KB file,
> no big deal. But, what if I'm d/ling a 4GB file? Well, I don't have 4GB of
> RAM for the program to store the unordered packets in memory. I don't want
> to dedicate 8GB of disk space to receive a 4GB file, and I don't want the
> tremendous speed decrease that reordering the packets within a 4GB file
> would cause (Imagine the unlikely scenario where packet 45782 goes in
> location 2). If the packets did not coincide with sector sizes, reordering
> within the existing file could cause a great deal of overhead.

There are a number of file transfer clients these days that have no
problem with out of order packets -- in fact, they thrive on them.
There's no reason (especially since it's not arbitrary throughout the
file, just maybe a packet or two reversed) that you shouldn't be able
to store say, the 3rd chunk before storing the 2nd -- just be sure to
write it to the correct place in file (given by the packet's headers
anyway). No reordering is required -- just proper ordering in the
first place.

> I agree, for some applications, UDP is useful. But, the way the draft is set
> up, it can be used for ANY application. It doesn't mention anywhere in the
> file send draft that "this Application requires TCP." So I don't think
> saying other applications might need UDP is valid. That explains why UDP
> should be supported by certain applications, not by all of them.

Nobody really said any choice in the draft should be supported by all
available applications -- we are just providing for negotiating which
to use. Obviously if a certain application can't use UDP, it will
reject the connection request or simply select TCP if offered.