[dcc2] Other comments

[myndzi]

STOP ARGUING LIKE PEOPLE ARE TRYING TO REPLACE TCP TRANSFERS WITH UDP
ONES, THANKS.

Yes, UDP packets can arrive out of order. No, you will NOT receive the
'last' packet first, unless you write it that way. Yes, some existing
transfer clients DO preallocate files. No, it doesn't really take that
long. Yes, some client out there "somewhere" might display pictures as
they arrive. No, supporting UDP negotiation will not cause the two
people out there who use that client any grief. This whole argument
has devolved into something very pointless.

To address the POSSIBILITY of HOW a UDP file transfer would be done:

Decide on a chunk size. Transmit packets in order, interspersing a
checksum every chunksize bytes. Number the packets with a sequence
number.

When the receiving client receives a chunk header it sends back a
request for any packets that didn't show up yet. Duplicate packets are
ok in the event that one of the 'missing' ones arrives after the hash.
Keep a separate file (a bitmap) that stores which chunks have been
completely received (and match checksum). Re-request an entire chunk
that doesn't match.

Resumes: start the resume after the last received chunk in the file.
Send request packets for any bits and pieces before then that are
absent.

Granted, that's *so complicated* and difficult that I wouldn't *dream*
of implementing it if there was any reason to do so.

Where have you been this last year or so? Ever hear of BitTorrent?
eMule? Both of these use file transfer methods that 1) deliberately
receive packets out of order and 2) WORK JUST FINE. And the packets
can be in ANY order, not a pretty-close-to-sequential order. Guess
what, they can also resume files! Fancy, that new-fangled technology.

And now, I would greatly appreciate it if we got this back on topic.
That being DCC2 connection negotiations. Which have no good reason not
to include UDP as a possibility. You say it is useful for streams? How
about an application that uses DCC2 to negotiatie a voice chat
session? There's a perfect use for it.

-myndzi


On Mon, 28 Jun 2004 16:13:13 -0000, codemstr at ptdprolog.net
<codemstr at ptdprolog.net> wrote:
> 
> > 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
> _______________________________________________
> dcc2 mailing list
> dcc2 at dcc2.org
> http://six.pairlist.net/mailman/listinfo/dcc2
>