[dcc2] Other comments

[myndzi]

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

I'm gonna step in and say something before this goes any further. Once
the debate devolves into the "what about the hypothetical users"
state, nothing useful will get done. You have to make decisions, and
the decisions should not be based on imaginary people that "could" be
"out there" -- they should be based on what makes the most sense.

Allowing the clients to negotiate UDP in lieu of TCP as a means of
communication is in no way harmful to existing clients should they
decide to support DCC2 -- it only provides more flexibility. It does
not make sense to try to say "we should not support UDP negotiation
because it doesn't act like TCP".


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

If the users don't understand the options that are presented to them,
that is their problem, not ours. I don't cater to ignorant people. I
will do my part to make things as straightforward and easy to
understand as possible, but I absolutely do not agree with making
design decisions based solely on the hypothetical situation that "some
people" (caution with the hypothetical people again!) "might not
understand".

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

Covered this in other post. No reason to store the fragments on disk
out of order in the first place.