[dcc2] Other comments

[Trent Lloyd]

Greetings,

> > 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.
> 
> Well, it's not essential to you. To someone who relies on this feature, and 
> has done so for several years, they may very well think differently. If the 
> purpose of DCC2 is to break existing clients, then expect it to fail. Users 
> who are accustomed to these features are not going to want to give them up 
> because some other people decided it was "not essential." 
For such a client that implements this option (I don't know of any), it
could easily be an option with a nice explanation "This will allow more
sends to work, but you won't be able to preview files as they arrive"

> You are right, if you turned of UDP for the send, it would solve the problem. 
> But I don't see that as a very good thing. I can see the support questions 
> now. "I just sent file.txt to a user, and it sent fine, now I try to send 
> pic.jpg and it says it can't connect, why?" User's will not understand that 
> the client uses UDP for regular connections and TCP for display-as-you-go. 
> Plus, if a NAT is present, then we're back to the same initial problem.
> 
> > 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.
> 
> I'm not sure I understand here. I have a Linksys router, it has all UDP and 
> TCP ports closed by default. Yes, I can send a UDP packet, but I can also 
> send a TCP packet. But, if someone tries to address a UDP packet to me, it 
> will fail. How is this better than just using a passive TCP connection? 
> Meaning, I connect to the IP:port of the other user, and the connection is 
> done like that. I don't know of any NAT that would prevent that. The only 
> instance where passive TCP wouldn't work is if *both* users are behind an 
> NAT, and as I mentioned, I really don't see how UDP solves that since if the 
> user tries to UDP to me, he's going to get the same error as if he used TCP. 
> Or am I completely missing something? 

UDP is more better for firewall travelsal where you can receive a UDP
packet (like in most cases) but listening on TCP ports areblocked.

You are correct if both users are behind a NAT then it is not usefull.

> > 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.
> 
> You say store the stuff in the file as it is received, and then store a map 
> in memory which can later be used to reorganize it. That's exactly what I 
> said as alternative #3. And, I said, having to move stuff around in a 4GB 
> file is not going to be fast. Imagine if every single packet is out of order 
> and needs to be moved by 512 bytes. For a 4GB file, that's a lot of movement. 
> You are absolutely correct, that is how P2P allows multiple sources. But, the 
> speed loss of moving stuff around is unimportant there. The multiple sources 
> makes up for it. Meaning, it takes (made up numbers) 10s to move the parts 
> around, and the multiple sources would have made the whole thing take 30s 
> less, so in all, the process made the download 20s faster. However, with DCC, 
> it would be 10s slower since there is no 30s speedup from multiple sources. 

The data does not need to be reoranised at all, you simply write the
data into the file at the right spot, and leave the rest blank (with NUL
characters or whatever) and then you keep a map of which parts are
filled and which arent -- The only time this becomes a slight problem is
if you want to resume a send, in the case that figuring out which part
you want to request would result in wastage of sending some stuff you
don't want, but you can easily just resend part of it, which is better
than it not working at all.

The other thing is you could in theory buffer some in memory because, in
theory, the packets will arrive soon after each other, if they aren't
then the entire connection is broken in the first place.

Cheers,
Trent
Bur.st

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