[dcc2] Other comments

[codemstr at ptdprolog.net]

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

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? 

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

-- codemastr