[dcc2] Other comments

Mon Jun 28 18:28:00 EDT 2004

OK, thanks for pointing that out. I don't believe that changes my
conclusions in the subsequent three paragraphs, however. 

Cheers,

Jeremy

-----Original Message-----
From: dcc2-bounces at dcc2.org [mailto:dcc2-bounces at dcc2.org] On Behalf
Of peter green
Sent: Monday, June 28, 2004 4:57 PM
To: DCC2 Working Group List
Subject: RE: [dcc2] Other comments

sorry but you are just plain
there are some situations in which udp packets can be exchanged
between hosts when tcp connections are impossible between those hosts

with tcp one side has to be able to listen with udp this is not
nessacerally the case read http://www.faqs.org/rfcs/rfc3489.html if
you want it in detail

-----Original Message-----
From: dcc2-bounces at dcc2.org [mailto:dcc2-bounces at dcc2.org]On Behalf Of
Jeremy Iverson
Sent: 28 June 2004 22:32
To: 'DCC2 Working Group List'
Subject: RE: [dcc2] Other comments

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

If they can't maintain a TCP connection, how would they stay on IRC?
Or do much of anything on the Internet, really.

I think the best way to approach this issue is to allow UDP and TCP in
the connection negotiation draft. I would think there is consensus on
this idea (keep in mind that we are working on 3+ drafts: connection
negotiation, file transfers, chats, additional "application" protocols
to follow).

That way, people can create UDP applications that use DCC2 negotiation
to initialize. However, each DCC2 application protocol should pick
either TCP or UDP; only one. File transfers and chats protocols, the
two biggest, would be over TCP. If somebody wanted to develop
additional application protocols over UDP, they could (Trivial DCC
file transfers?)

In short, I still don't believe in re-inventing a transmission control
protocol over UDP just to get around routers and firewalls. This is a
very application-specific group (DCC2); we shouldn't be dealing with
general Internet Protocol issues, but using existing solutions
developed by the appropriate groups.

Cheers,

Jeremy

-----Original Message-----
From: dcc2-bounces at dcc2.org [mailto:dcc2-bounces at dcc2.org] On Behalf
Of Trent Lloyd
Sent: Sunday, June 27, 2004 8:59 PM
To: DCC2 Working Group List
Subject: Re: [dcc2] Other comments

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.
_______________________________________________
dcc2 mailing list
dcc2 at dcc2.org
http://six.pairlist.net/mailman/listinfo/dcc2

_______________________________________________
dcc2 mailing list
dcc2 at dcc2.org
http://six.pairlist.net/mailman/listinfo/dcc2
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004

_______________________________________________
dcc2 mailing list
dcc2 at dcc2.org
http://six.pairlist.net/mailman/listinfo/dcc2