[ASH]Yoshi wrote:The most basic point is that this would help since it will come earlier in the handshake and it would once and for all rule out NMDC clients. Also we all should agree that this is information that the hub needs ...
Actually, cologic's point (which happens to match my thoughts on the matter) is that client information should not be important to the hub. It's only important because we rely on knowing the behavior of various clients, since the protocol has no built-in protection from abuse (such as better protocols like BitTorrent do). Only the client's capabilities are important, and ExtendedProtocol hubs/clients can solve this.
[ASH]Yoshi wrote:... to know anyway even though it's fakeable or not (thus no harm in adding it to the protocol).
Well, I cut off this point... it is important. This is so easily fakable that it will only give you a matter of weeks before the DC Stealth programmer adds it to his client. Is a couple of weeks, or months, of no-DC Stealth (or other real fake client) worth a big change to the protocol that will mean DC++, ASH, etc. having to change their code? What measure comes next - how do we "buy" the next couple months? Another protocol change?
If you're trying to block out NMDC earlier in ASH's connecting protocol, I think there are nicer hacks that you can do that affect only your code base. I'm sure you've thought about "eating" the bandwidth cost once, then maintaining a timing-out IP blacklist to stop subsequent connections from the same IP.
Why don't you begin at the beginning, at your requirements, and let the programming minds who read this come up with novel solutions on their own?

I think this potential fix has been ruled out.
[ASH]Yoshi wrote:However I do agree now that we might consider making a better all in one NetInfo command instead. Anyway I didn't think you guys would so consistently hate the idea of a new protocol command. I though you'd have some creative idea instead on how to make it even better (Except for the Version which maybe should be looked more closely upon). As for me I'm simply trying to add something I know people been missing as myself.
You miss the point, the resistance isn't an overall ivul "lazy programmer" one. It's that $ClientVersion is so trivially faked that it will only clutter the protocol and become another useless command - much like you admit $Version to be. You came offering a solution, not asking for creative ideas to solve your original problem... wtf.
[ASH]Yoshi wrote:I'm in the DC Dev forum... if you'd like to discuss it there we're you're able to ask and get answers directly feel free to contact me and I promise I'll answer all you questions.

Mmm, gotta love conflict! Yeah, I'll discuss it with you there too. I like having some of the more useful bits made (initially or afterwards) in public, for those rare cases where someone decides to do some thorough research before posting.
If you want to identify clients in a meaningful way, get the cooperation of xAyiDe and his CDM. This will not save you any CPU or bandwidth, but no protocol command can do that.