[dcc2] Other comments

[codemstr at ptdprolog.net]

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

Everyone seems to think that this is a purely hypothetical feature. This was 
not something that I just made up. I mentioned it because I've seen it 
mentioned before. I assume most people here are familiar with the 
old "Valinor IRC client list"? Well if you go to their new address, and go to 
the review a client page ( http://www.ircreviews.org/reviewing-clients.html ) 
you will see a question they want you to answer. "Does it show a JPG image 
while it's arriving, with DCC?" Why would they put that question on there if 
the answer is No for *every* IRC client? I have yet to discover which of the 
clients on the list there support this feature, but I'd bet there is at least 
one that does. I agree, if we make up purely hypothetical scenarios, then 
we're doomed. But that's not what I'm doing. I am talking about a feature 
that I believe to be implemented already.

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

Here is where you lose me. How is it better? I just checked with a couple of 
friends. Linksys, Netgear, and DLink all block incoming UDP in the same way 
that they block TCP. So how is using UDP, which will be MUCH more complex, 
better than simply using a passive TCP connection? In both instances, it 
doesn't work if both users are behind an NAT. In both instances it works fine 
if only 1 user is. So why implement our own passive TCP on top of UDP, when 
we can already do passive TCP? I've never heard *ANY* person complain that 
FTP doesn't work for them because of a firewall. If they have a firewall, 
they simply use PASV. The FTP developers didn't feel it necessary to 
incorporate a TFTP protocol into FTP; they simply used the available 
capabilities of TCP. Why would we chose to do differently? Passive TCP has 
been proven to work.

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

Well, yes, but it's essentially, still not much faster. Why? Well, I'm still 
going to be writing a possible 8GB of data to disk! Say I receive byte 2^32-
1. I set that byte to 11110000. Well, the other 2^32-2 bytes before it have 
all been set to NULL now. That means, even though I've only received 1byte of 
data, I've already written 4GB to disk. Granted, that scenario is unlikely to 
occur, but my point is, there are going to be a lot of NULLs that need to be 
overwritten. So that means, we'll be writing more data to disk than we 
normally would, and hence it would be slower. Not as slow as reorganizing, 
but still slower than only writing the data once.


But anyway, allow me to demonstrate why UDP can't be used for File Sends. DCC 
RESUME. Someone is sending me a file that is 2048 bytes. I have received:

0-400
513-1024
1025-1200

How do I proceed to request a resume? If I request it with an offset of 1201, 
which is how the draft currently works, bytes 401-512 are corrupt. I never 
received them and therefore my client set them to NULL. So we can no longer 
simply specify an offset. So how exactly would DCC RESUME work with UDP? Or 
is it going to be another thing, "Enabling UDP makes more sends work, but if 
they fail, you cannot resume" type of message?

-- codemastr