[dcc2] Other comments

[Trent Lloyd]

Hi codemastr, others,

> > I don't think UDP is needed but it is available so I use it in
> > examples. It wouldn't be hard to number all the UDP packets, assemble
> > them in the file out-of-order, and check a hash or something I
> > suppose. In a file transfer getting the packets in order is NOT a
> > concern.
> 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).
This is not an essential feature, and (displaying as you download) its just as easy to turn this off, and you would use TCP where possible.

The reason a UDP transport is usefull is because in most NAT situations
you can send a UDP packet, but you can't maintian a TCP connection, and
henceforth sending a file will just work if you use UDP, and then use a
TFTP-like mechanism.

> 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.
This is entirely wrong. All you need to do is write it out to the file
that your receiving in, and keep a map of what you have received (which
wouldn't be that large) so like you are goign to use 4GB of space in the
first place so if you write bits of that file out, its not a problem.
So you basically end up with a file with empty space, this is how P2P
applications work that allow you to download from multiple sources, same
for download managers like getright that let you download in parts.

> 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.

I think it woudl be nice to have as an optional part, so we know we can
standardize on this, it is usefull, and as myndzi said, not necessarily
for file transfers but for many applications.

Cheers,
Trent
Bur.st

-- 
Trent Lloyd <lathiat at bur.st>
Bur.st Networking Inc.