$ClientVersion <version>|

[[ASH]Yoshi]

Since trying to identify clientversion for a hub is like finding a needle in a haystack, so NOT funny! There should definitely be a much simpler way to do this for the hub. I know people probably wanna kill me now and I know you all heard it before but couldn't we put a new command into the protocol? If the client were to send a $ClientVersion <version>| line after $Key| this pain in the ass would stop.

I know it will take some time before most clients support this and we all could simply ban clients that don't send this but the sooner we get this the sooner we're able to coop with this shortage.

Most people may think that this solves nothing.. It will be really easy to fake anyway. But actually I don't agree Sure you'll be able to fake it.. it will always be... But at least you will have to do it... and it all helps the hub alot while trying to identify the client version. Why should you try to examine client2client Lock to be able (sometimes) to know what typ of client you're dealing with when the client already know this? isn't it easier to ask?

Anyway I'm guessing most people know that more and more hubowners wanna ban ceritain client etc.. NMDC for ex. .. This is a step on the way to make this simplier and faster. So please consider this change..

Either that the client responds to $GetClientVersion| or sends it's version without been asked directly after $Key. Or 3, sent i like a support.

It's a really easy change to make and it's not a lot of extra trafic since it's once/login. I don't care how.. this is simply a suggestion as long as we're able to do this better than now.. You really shouldn't have to send a client nicklist and all just to be able to find out his client is banned on this hub and kick him.. That if something is a lot of extra trafic!

// Yoshi..

If there's one thing that computers do well, it's to make the same mistake uncountable times at inhuman speed. (Peter Coffee)

[cologic]

Ugh, please not another fucking protocol extension to appease meddling ops.

[[ASH]Yoshi]

Gahh.. this just the kind of reply I don't want.. You never consider the change.. you saw it was a change and then said die please! .. Why is it that the DC devs. are so afraid of changes to the protocol. And this change wouldn't even be noticed by the common user. Of course there been a lot of stupid suggestions to changes and we shouldn't implement them all. that would create chaos. And I'm not saying that you should implement this one if you feel it's not a good change.. But for example consider the DC++ tag om the MyINFO description. I'm not sure but I'm rather confident that Arne at least though about a new protocol command do communicate this info without having to include it as a part of the description of the user. It would meant less trafic and a better looking description. But today I at least think that it would been a lot better that Arne created the NetInfo command (instead of Hess (and a better one than Hesses)) and used that properly. It wouldn't been possible to fake for the NMDC clients and other clients etc. without changing some sourcecode..

Anyway.. I'm guessing that if Arne tried this back than people just told him to go to h*ll thus this never came to be.

Quote: to appease meddling ops.

I not please the onces using my program whom should I please? You? ;D

// Yoshi

[ender]

What would $ClientVersion add to the protocol except for another useless command... (do you know $Version ?)

As for better-looking description, NMDC added a tag to v2.01 because ops demanded it (v2.00 only answered $NetInfo - yet another useless extension)...

[cyberal]

But today I at least think that it would been a lot better that Arne created the NetInfo command (instead of Hess (and a better one than Hesses)) and used that properly.

I agree with Hess, DC++ has hijacked the description field, a NetInfo command should have been implemented from the beginning!

[[ASH]Yoshi]

Gahh.. know what you're talking about please.. The $Version is used for communicating protocol version and can't be changed from 1,0091 for compability reasons (NMDC won't allow you to connect if communicating another version nr). What do you take me for??

As for the demand of a description tag in 2.01 that's in the long run only stupid... It won't change a thing, NMDC 2.01 will be banned by most hubs anyway since Hess didn't make it autoupdate and because of more reasons.. Hess said it's beacause sending a new MyINFO is a lot of extra trafic.. and sure I agree.. sending a much smaller purpose only NetInfo is smarter.. if the NetInfo where to change a bit and would be forwarded to all users by all hubs and picked up by the client it's a lot better choice than a MyINFO tag.. though Hess though by implementing and option to turn on a Description tag some hubs would have more ease to pick up that instead which might be true. But this is a whole other issue that will actually be more easy to deal with as soon as we get a good way to identify client version.

But to the point.. A while ago there one was the NMDC hub.. no options.. Nowadays we have both hubs and clients.. So things have changed. We're able to pick up the NetInfo line etc. And we're able to add long lost things on both sides.. Why then still so afraid? Again you're one of those people who thought what an idiot without thinking/knowing nor reading.

I really think this community of devs need to rethink. If I see/hear of a suggestion I read it and think about it and consider it. As it seems in here most people probably don't even read.. Maybe the topic and then pretty much have their opinion set. I hate this idé.. the end!.

If I were to consider any post here not saying this is a good idé I'd really like some real thoughs/reasons.. not da*n stupid newbies telling me to use $Version instead.

[sarf]

You ask why DC developers do not like change?

Well, it's mainly because almost ALL requests for change in the protocol will mean that a) more power is given to OPs (which sometimes use that power inappropriately) or b) nothing of value will be added.

$NetInfo is useless, since it can be faked. Also, $NetInfo can't be extended (easily) to give the information you want without BREAKING the old scripts.

We would have yet another thing that looked different depending on what client sent it.

You want a good way to identify the client version? Are you serious? Do you think that the clients that emulate DC++ / NMDC will somehow disappear, defeated by a string sent by the client itself?
Seriously.

Most devs do not like change for its own sake - it wastes their limited time as well as that of script coders, hub owners et cetera.

The problem is that (AFAIK) there is no way of knowing if a client will respond to a $GetNetInfo other than sending it.
So how about we add another command - $GetExtendedNetInfo? Of course, we won't make it possible to check if we support it (unless you'd send $DoYouSupportExtendedNetInfo), and it will only return the number of hubs we are currently connected to, as well as the number of download and upload slots we have currently (however, the brand spanking new $GetExtendedExtendedNetInfo would have some more info...).

Yoshi, if you seriously think that supporting $ClientVersion will help EVERYONE using your application, then I do not understand what use I would - as a leechin' user - have of $ClientVersion, except yet another thing I may need to get from another user?

A change should be for the better, not for its own sake.

Also, Yoshi, telling ender and cologic that they are "da*n stupid newbies telling me to use $Version instead" does not make your case stronger.
If you look what ender said, you see that he DID NOT WANT ANOTHER USELESS COMMAND LIKE $Version. He DID NOT want you to use $Version instead, he merely pointed out (as you seem to confirm) that $Version is a useless command.

cyberal:
The reason the description field was "hijacked" was that OPs/hub owners did not want to "waste their time" on DC++ from the beginning, yet still wanted a way to check it.
Implementing a $NetInfo command was quite simply unfeasible since many of the scripts/bots available nowadays was not available back then.

<sigh>

Anyhow, take this rant however the way you want.

Sarf
---
Ignorance can be cured -- but stupid is forever.

[Nev]

I think this is a great idea.

Changes to the protocol, i.e. changing the behavour of the protocol should be avoided or solved by the $Supports command. However, optional extentions are almost free of charge.

We can't use version as it is a decimal number, NMDCH would freak out if it received '$Version dc++ 0.242|'. ASH, and I believe, pto ignores Version utterly, so a new string type named ClientVersion would really solve a problem thats been pending for quite some time now.

I think dc++, as the dominant client backed up with oDC, should implement this, and that Hess also do it in NMDC2. win-win.

- Nev

cologic; Your insights was so lame. The so called meddling OPs is the ones who provides great hubs for us all. The comment was just plain dumb. I know you can do better! =)

[[ASH]Yoshi]

You've just did what I asked in the first place.. gave me a serious reply..

I'm really sorry about the newbie thing.. I was just angry for not getting a serious reply.. So sorry ender.. meant no harm. And I know you all get a lot of stupid requests.. all I ask is that you read and filter.

With that said on to the discussion

About faking:
Since faking will always be possible I think it has nothing to do with this... of cause you'd be able to fake DC++ etc. But what has that to do with this. Making it easier for hubs to know what kinda client it's dealing with? Btw.. faking a NetInfo line gotta be at least a little harder than entering a DC++ tag in your desc in a non DC++ client.

About NetInfo:
Even though this have little to do with clientversion I have to say that if you know what kinda client you're dealing with you also know what kinda NetInfo you're dealing with And why would a good Netinfo made to coop with most things be worse than having to parse through MyINFO looking for it?

About $ClientVersion helping:
Since most hubowners I know of tries to find out clientversion in all the ways possible I think that we've only seen the begining of clientbanning. It will increase whether we help it or not. What I'm trying to do here is simply to try and wase as little resource possible doing this.. Take my dear ASH for example.. While using scrips getting ISP/IP and kicking for the wrong one users will be fully loged in and than kicked .. thus sinding them nicklist and in many cases also all the online users MyINFO:s.. + sending their myinfo and hello nick to all online users. This isn't just A LOT of extra strain for the hub.. It also causes the users online to flicker for the users of the hub which is annoying and a wase of their resources (ASH kickes directly). So what this WILL cause for sure is that I'm able to kick users before sending all this info wasing all this resources and telling them sorry but you're client isn't allowed here.. please use the newest DC++ or whatever..

SO sarf .. I am serious.. I think this would actually help.. making hubs able to have more users online since less resources spent etc. It's a small step I admin but at least I think it's a good suggestion.

I have to admit I'm a newbie here.. but I have programmed almoste a whole hub software (all creds to Nevyn though) and I know what it takes and does. I have talked to some operators and they all seem to want the same things (be able to have an as nice hub as possible and good ways to get rid of fakers etc.). I'm not doing this to wase anyones time.. I'm actually doing this to gain CPU time for eveyone.

// Yoshi

*sorry endor for my outburt.. won't happend again*

[[ASH]Yoshi]

I know that Opera will back us up.. And I know that ptaczek (guy behind ptokax) wants this too... I belive that I and fusbar will easily persuade Hess.. If we get Arne to implement this Hess won't have a choice anyway..

Btw.. talked to Arne about this yesterday and as it seems he's not really against it Actually he who told me to ask this forum about it..

[sarf]

Yes, well, sure, go ahead an implement it. Know, however, that DC Stealth will "fix" this thing pretty immediately.

By the way, "clients will be banned anyhow, so let's help the OPs" does not compute in my world. Neither does "but if we know what version the client is then we can interpret the $NetInfo as we know it should be done". Granted, some clients may have special commands, but if $NetInfo is going to become standard, then standardize the output it gives. Otherwise you might as well call it $ClientString.

Yes, people get knee-jerk reply reflexes after sitting on forums for a while. It is only natural - after all, if you had seen a lot of requests with (for example) "duuhhh... I want a client extension so I can force a download from NM DC clients", you would also consider any thread that mentions changing the protocol "stupid until proven intelligent".

That said, I still think implementing something you know will not do what it is supposed to do is a bad idea, but go ahead. Just don't say "OK, we need a $ClientHash command, too" a month hence.

By the way, the $ClientVersion will make things easier for everyone - OPs to check, and users to fake.

Sarf
---
Let not the sands of time get in your lunch.

[GargoyleMT]

Since faking will always be possible I think it has nothing to do with this... of cause you'd be able to fake DC++ etc. But what has that to do with this. Making it easier for hubs to know what kinda client it's dealing with? Btw.. faking a NetInfo line gotta be at least a little harder than entering a DC++ tag in your desc in a non DC++ client.

Yoshi, you make this assertion, but since you're a programmer, you know how simple this would be. Ask DJ_Offset how much time it would take him to put in a fake $NetInfo into Quick DC. Heck, you can add it into DC++ in 5 minutes simply add something like:

Code: Select all

else if(cmd == "$GetNetInfo") {
      char modeChar;
      if(SETTING(CONNECTION_TYPE) == SettingsManager::CONNECTION_ACTIVE)
            modeChar = 'A';
         else 
            modeChar = 'P';
      send("$NetInfo 3$2" + modeChar + "|");

into the Client::onLine function... It's only slightly more complicated to return non-faked information.

I know that Opera will back us up.. And I know that ptaczek (guy behind ptokax) wants this too... I belive that I and fusbar will easily persuade Hess.. If we get Arne to implement this Hess won't have a choice anyway..

Jon Hess will likely do what he wants anyway. And Opera, whether he likes it or not, fills the role of the DC++ mod author who is playing the metaphorical "Good Cop" to the hub operators.

I'm honestly surprised that none of the ivul mod makers have picked up on this fact and based their mod around oDC.

Btw.. talked to Arne about this yesterday and as it seems he's not really against it Actually he who told me to ask this forum about it..

Maybe Arne just wants you to get a taste of the reaction to this suggestion. A "Trial By Fire" of sorts.

You can't make DC any less leech friendly by instituting this command. All you'll do is weed out the extremely stupid. (Intra/Interbrew does not fit in this category.) (The true solution is more in-depth changes to the protocol, taking and learning from other well designed protocols like BitTorrent.)

[cologic]

cologic; Your insights was so lame. The so called meddling OPs is the ones who provides great hubs for us all. The comment was just plain dumb. I know you can do better! =)

I suppose I carry myself in better on the DC++ dev hub. Well, I'll try to write something more substantive this time.

You never consider the change.. you saw it was a change and then said die please! ..

To the contrary: my response was quite considered.

$Version is used for communicating protocol version and can't be changed from 1,0091 for compability reasons

You're wrong. NMDC 1.0, for example, uses 1.0091. Further, I set my client version to "dc++ 0.242" with no ill effects:

Do you want a packet dump of client-hub traffic too?

(NMDC won't allow you to connect if communicating another version nr).

Wrong.

What do you take me for??

Aggressively ignorant of $Version's freeform nature.

Why then still so afraid?

Yes, I'm afraid of changes in filesharing software. It really scares me. I'm positively quivering from mortal fear as I type this message.

Again you're one of those people who thought what an idiot without thinking/knowing nor reading.

Well, no, I'm one of those people who thought 'what ignorance' after reading your messages and considering them.

Yes, well, sure, go ahead an implement it. Know, however, that DC Stealth will "fix" this thing pretty immediately.

More precisely, I'll fix it. The stealth people will base their updated client on mine, as they've done for the last few versions.

not da*n stupid newbies telling me to use $Version instead

To whom was this directed? (Further, in light of your later comment "I have to admit I'm a newbie here..", this is kind of ironic.)

[cyberal]

I'm not doing this to wase anyones time.. I'm actually doing this to gain CPU time for eveyone

Let's focus more on this and less on the "getting rid of fakers" everyone seemed to have gotten stuck on.... I think it's a good idea.

So what this WILL cause for sure is that I'm able to kick users before sending all this info wasing all this resources and telling them sorry but you're client isn't allowed here.. please use the newest DC++ or whatever..

This is good!

[Sedulus]

So what this WILL cause for sure is that I'm able to kick users before sending all this info wasing all this resources and telling them sorry but you're client isn't allowed here.. please use the newest DC++ or whatever..

This is good!

ehm.. if the hub software is designed right, any client with a dc++-style tag can be identified and kicked before the $NickList/etc is sent

see: http://dcplusplus.sourceforge.net/wiki/ ... ed%20entry

[[ASH]Yoshi]

I have rather limited time but I'll try to explain

To sarf:
My point about the clientversion would tell us how to handle the NetInfo line was somewhat ironic. Of course I think that we should make it right from the start .. and I do really think that we got enough knowledge to do this. What we call it or how we implement it I don't care about.. As I said before.. this is just a suggestion..

To GargoyleMT:
Again there with the faking.. ;D I just think you're battling this backwards. There are many open source clients.. thus I think we've already lost the battle against the ones changing the source to fake it.. But not everyone is able to do this and at least it's harder than entering a description faking a DC++ client. You should instead consider the possibilities of beeing able to change in both clients and hubs.. And as I've said before I'm not claiming you all should think this is a good idea. Just consider it! Change might not always be bad.. or is it? ;D

To cologic:
Does it really work with changing your $Version with NMDC.. I'm rather confident fusbar told me that it wasn't possible. If this is the case I'm voting for the use of this command instead! It would be really great. Thus I think it's not possible. But if it is it's really sweet .. and I'm deeply sorry for my ignorance! Could someone check this out? I'm in a bit of a hurry.


To Sedulus:
Of course I kick DC++ clients before sending them nicklist if slots/hubs etc. missmatch.. Even clientversion.. That's not really the point.. The point is that you shouldn't have to use the description tag for this since it's the easiest thing to fake. I just think that since we all want this info anyway why the h*ll not make room for it in our protocol?? Is that really so evil?


Closing:
I think most of ya should consider why change is so bad.. And again I'm stressing that you shouldn't have this suggestion in mind (that's step 2 ).. Could we just agree on that a change is possible and that it's not to any harm? And what about all this hatred I feel against hubowners? Of course there are jerks everywhere? But there are also good ones as there are good suggestions ;D Anyway.. I think this suggestion is just a way to make what everyone does anyway easier and without spending everyones resources.

Finnaly: I really do respect that you guys don't wont like a million protocol extensions and that's fair.. But I don't think we should allow non just because of that.

I'm rather tired and I don't have time to spellcheck this and I might have missed somthings of what you all wrote but I'm really glad.. We're getting somewhere.. finally we're having a discussion

// Yoshi

[cologic]

[code]$Lock d_*(]A6TXDe8n'dRAY2+RbvWZr>*nL0>6QrQvD3'[email protected]|$HubName •• [eÆ’i] MP3 † HEÃ…VENâ„¢ ••| This hub is running version 1.0.25 of the [efi] Network Hub Software. |||||$Key ³³W WÃ?w&ÀÃ?Õeâ€?4c1?¶‘â€â€

[Sedulus]

I'm not sure but I'm rather confident that Arne at least thought about a new protocol command do communicate this info without having to include it as a part of the description of the user. It would meant less trafic and a better looking description.

well, it is rather nice that the info is propagated. (1) the P is useful, (2) seeing clientversions is good, it's a bit of advertising for different clients

the other info, hubs/slots/bwlimit/O are usually not immediately useful; but there's no harm in showing those as well

I would have liked it to use a nice format (through some extended myinfo for instance), but hiding everything from the users is not good imho.

I agree with Hess, DC++ has hijacked the description field, a NetInfo command should have been implemented from the beginning!

the NetInfo is horrible the way it is implemented now. should one ask the user for new NetInfo every couple of minutes to see if they're joining 100's of hubs?
I think we should stick with the description tag for now.. until DCv2

Btw.. faking a NetInfo line gotta be at least a little harder than entering a DC++ tag in your desc in a non DC++ client.

that is true.. but sometimes this is necessary, when "meddling hubowners" have never heard of a client like DCGUI or QuickDC and auto-kick all non-DC++'s.

Take my dear ASH for example.. While using scrips getting ISP/IP and kicking for the wrong one users will be fully loged in and than kicked ..

Of course I kick DC++ clients before sending them nicklist if slots/hubs etc. missmatch.. Even clientversion.. That's not really the point..

ok.. so you're saying that you _do_ kick immediately for wrong clientversion, but wait until after logon to check the ISP/IP?
then I would've expected a suggestion for $ISPnIPVersion and not $ClientVersion ;)

I think most of ya should consider why change is so bad..

change is bad when it's not useful, and I agree with BC/Sarf/MT that it adds nothing of value.

[15:32] <cologic> It's client capabilities which are important.
[15:32] <cologic> (see the stupid javascript web browser sniffers which break whenever they see a browser they don't recognize for another example)

I also agree with BC that a $Supports would be a lot nicer than a $Version to lookup what clients/hubs can and cannot do.

[GargoyleMT]

Again there with the faking.. ;D I just think you're battling this backwards. There are many open source clients.. thus I think we've already lost the battle against the ones changing the source to fake it.. But not everyone is able to do this and at least it's harder than entering a description faking a DC++ client. You should instead consider the possibilities of beeing able to change in both clients and hubs.. And as I've said before I'm not claiming you all should think this is a good idea. Just consider it! Change might not always be bad.. or is it? ;D

Pointless change is bad, Yoshi. So, until a packaged leech client (Stealth DC) comes along to fake this command, your method will be effective. What are you truly gaining here?

Please take a look at the thread again, although it might seem that we're resistant to change, we're not - take a look at the Ratings System thread, or one of the ones discussing Hashing for proof of that. The comments here are all legitimate concerns that should cause a revision of your idea.

$ClientVersion will be less effective at keeping bad clients out than $Lock/$Key was at keeping DC++ out - there's not even an algorithm to reconstruct!!!

[[ASH]Yoshi]

Sedulus:
1) ASH does kick directly for ISP/IP.. why I brought it up was to stress the bad of having a flickering nicklist as you have when scripting ISP/IP check.

2) I really do agree that the NetInfo is usless as it is.. But I also belive that if someone we have the power to change that..

3) If we were to use NetInfo instead of MyINFO tag the info should of cause be broadcasted for eveyone to see.. and preferably the clients should pick up this and display it to the user in a nice way.


GargoyleMT:
Of course pointless change is bad.. though I don't agree this is pointless.. As I've said before.. I think the description tag is too easy to fake (at least easier than modify any source-code) and since we all want to communicate clientversion and since we're also talking about it slots/hubs etc. why not make it a part of the protocol? I might be wrong.. this might be too much trouble to gain this.. We might just stick with the DC++ tag.. but then again I gotta say that it's a little stupid and very lazy


Why not agree that this info should be be sent to the hub as fast as possible and keept as small as possible. If someone where to achive some order it's Arne and his DC++..

Why should we sit each and every day and curse over the DC protocol when we in fact are able to change it.. I personally think that the idea of using a purpose only line like the NetInfo line is good even though Hess didn't really make a good NetInfo line and don't use it correctly.

client2client detection isn't harder to fake than anything else.. And as I've said the $ClientVersion line or any way of communicating version etc. should come as soon as possible.. preferably after $Key instead of after the login has completed.. We can't get ride of fakers but we can get rid of stupid trafic.

[GargoyleMT]

Yoshi, I'd respond, but you still haven't responded substantively to any of the previous points.

[[ASH]Yoshi]

Hehe.. so many points and so many questions .. I'm sorry if I missed some of them.. (I think you all missing my point so ditto) Anyway.. we're getting nowhere.. 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 to know anyway even though it's fakeable or not (thus no harm in adding it to the protocol). 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.

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

[Sedulus]

The most basic point is that this would help since it will come earlier in the handshake

..an earth shattering whole 2 commands, between which there is no reply (or at least, does not _need_ to be any reply).

and it would once and for all rule out NMDC clients.

hm.. I hope you don't let Hess read this when asking him to implement it ;)

Also we all should agree that this is information that the hub needs to know anyway

well.. I disagree. this information is useful for users; see Advertising above. imo, the hub does not need to know what different clients _are_, it needs to know what different clients _do_; see Discrimination of browsers by crappy javascript/et al.
when I see a $MultiConnectToMe in my hub, when there is absolutely no need for it, and my hub does not support it. then I'll start discriminating.
when I see a tagless client, I'll start discriminating.
same goes for clients being logged in twice from the same IP with a nick that only differs by one digit.

I stand by the opinion that the name is not important, it's the behaviour.

However I do agree now that we might consider making a better all in one NetInfo command instead.

that I would agree with, if it's done right.

Anyway I didn't think you guys would so consistently hate the idea of a new protocol command.

s/new/useless/

sorry :-/

[GargoyleMT]

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.

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

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.

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.

[[ASH]Yoshi]

Gahh... I'm not missing your point.. I think your point is irrelevant. Gargoyle.. you're so hung up on the faking bit.. I almoste didn't even had that in mind.. This change is not about getting rid of fakers (because that is impossible!). It's mostly about easier getting the information the hub needs to have a good banclient feature. It's also about taking a shortcut.. Let's say you where to make a new protcol and knew that ClientVersion should be sent .. wouldn't you rather like to add that to the protocol than sending it in some other less logical way?

To Sedulus:
I do agree that the infomation is mostly usless for the hub (if not using builtin hubs/slots/clientversion change). But if the hub where to support this I'm hoping the programmer is smart enough to show each users info in the userinfo command.. At least that's what ASH is doing.. Of course the operators should be able to see this information. By rules out NMDC I meant NMDC 1.0.. Hess knows this For his own sake I'm hoping he makes NMDC 2.01 good enough to be accepted by the hubowners. I also think you're right about sending usless information.. And that if you're not able to expect the ClientVersion command in reply there's no real gain either.. Though my plan where to implement it now and to demand it later.. If we'd never start we'd never get anywere..

Finally:
I've been talking to Ptaczek and he also feels as me that a new and better NetInfo command should replace the Myinfo DC++ tag.. and that clientversion maybe should be a part of this tag.. though I think it's no harm in separating them since the Netinfo is not the same all the time while clientversion is.

[ptaczek]

Let me add few cents:

Fact I wont talk about: anything can be faked.

I saw some arguments, I saw some good points but mostly just redundant talks...

Well designed client identification at the begining of handshake is useful from various points of view. Anybody with clear mind can see it.

1. it will save traffic - the rest of login sequence in case of 'wrong' client version or wrong number of slots/hubs will not be tranfered.
For those who needs advertising of the client version in description, the hub can append the client version string - no need to send it with MyINFO.
Question: Why we should wait for MyINFO with version/hubs/slots and waste additional traffic?

2. it will save CPU time - no doubts about it. It's in direct connection to the 1st point.

3. personally I like the idea. Many of you are nice examples of neo-phobs enclosed in protocol paradigm, afraid of changes. Everybody involved in DC knows that the protocol isn't designed well. And what we do? We are waiting and waiting. For what? Aha, for DCv2? Don't you think it's time to make the DCv2? Slowly transform the protocol and adapt both clients and servers to not harm the community. What? Sci-fi? I don't think so...

[Dj_Offset]

Ok, now... my turn

Let me add few cents:

Fact I wont talk about: anything can be faked.

Bingo!

Question: Why we should wait for MyINFO with version/hubs/slots and waste additional traffic?

I don't see the difference here betweeen a delayed login where you cannot send a $GetNickList until _after_ the $MyINFO is sent as a response to $Hello (thats how I originaly implemented it, but the ptokax hub implementation forced me to rearrange those two commands).
That being said, there is a differene; the $MyINFO is sent automatically - it doesn't have to be requested.

So if you absolutely have to filter someone, do it this way...
Adding useless commands to the protocol doesn't solve anything, it just adds complexity (read: bloat) to the protocol.

2. it will save CPU time - no doubts about it. It's in direct connection to the 1st point.

No, on the contrary, read above (as you don't have to request the info).

3. personally I like the idea. Many of you are nice examples of neo-phobs enclosed in protocol paradigm, afraid of changes. Everybody involved in DC knows that the protocol isn't designed well. And what we do? We are waiting and waiting. For what? Aha, for DCv2? Don't you think it's time to make the DCv2? Slowly transform the protocol and adapt both clients and servers to not harm the community. What? Sci-fi? I don't think so...

Well actually I've proposed a new protocol from scratch (DCTNG)... it isn't _nearly_ complete, but I hope its a start. Please give some input, there is a thread on this forum about it.

On a personal note, I'd like to say I completely agree with Sedulus. The name is not issue, its the capabilities.

Conclusion: Adding a new command _DOESN'T_ solve anything, however it DOES add bloat to a decaying protocol.

[[ASH]Yoshi]

Hehe.. here we go again What you all doesn't seem to get is that a clientversion command is supposed to be expected and that it's easier to get version out of it than a MyINFO string.. same with NetInfo


First:
Which one do you think Dj_Offset is the easiest string to parse for Version?

$MyINFO $ALL Yoshi1 <o5.11><++ V:0.242,M:P,H:1/0/0,S:3,O:100>$ $LAN(T1)
$$132696561957$|

or

$ClientVersion o5.11|

=> God don't let me hear you saying the first one ClientVersion would be saving CPU time + it's consistent.. I don't have to look in 2 or more places

and as I said before.. same goes for NetInfo

Second:
If ClientVersion were to be sent automaticaly after Key that is less trafic than waiting for the MyINFO later on in the handshake.. please don't argue against that!

Finnaly:
Having a totally new protocol is actually a good idea.. but it's a lot harder to implement than this, you have to agree on that or?.. + The existing protocol is modifiable to be good enough.. Though if you do manage to implement a new protocol be sure that if it's better I'll support you! I've been more or less working on one myself.. It's actually a protocol I've made for another thing but it's close to the DC protocol and it's possible to use it as an foundation for a totally new one..

http://yoshi.shacknet.nu/YCProtokoll.txt

[ptaczek]

Dj_Offset: It seems you haven't got it. Client ID sent on very begining of the handshake will save traffic. Parsing simple ID string is faster. Now count with 2000 users hub where you have new connection almost every second and make simple multiplication.
The client id string will NOT be requestable. It must be send automaticaly right after the key.

Also in my opinion, designing of brand new protocol means creating of brand new p2p community unless you wont assure smooth transition which presumes closer cooperation of developers.

Note: Latest ptokax has no problem with MyINFO before GetNickList.

[cologic]

[quote="cologic"][code]$Lock d_*(]A6TXDe8n'dRAY2+RbvWZr>*nL0>6QrQvD3'[email protected]|$HubName •• [eÆ’i] MP3 † HEÃ…VENâ„¢ ••| This hub is running version 1.0.25 of the [efi] Network Hub Software. |||||$Key ³³W WÃ?w&ÀÃ?Õeâ€?4c1?¶‘â€â€

[Dj_Offset]

Dj_Offset: It seems you haven't got it. Client ID sent on very begining of the handshake will save traffic.

First of all, my client will not send it.

Parsing simple ID string is faster. Now count with 2000 users hub where you have new connection almost every second and make simple multiplication.

Well sure... Lets see one each second is one each second. Now that wasn't too hard to multiply?
Ok, and lets see how hard is it to do locate "V:" doing a backward search? I think a few people in this forum can be helpfull with the boyer-moore substring search algorithm in case you somehow manage to not be able to extract it within a reasonable amount of time (allthough I cant see how this would be the case even on my good ol' 386 DX).

I'll be happy to assist if the parsing gets too tricky, I'll even refresh up on my pascal to help those delphi dudes if necessary.

Sorry about the sarcasm, but seriously, how hard is this really?
Please enlighten me with a profiler if you _really_ want to blame the CPU usage.

The client id string will NOT be requestable. It must be send automaticaly right after the key.

Why not "fsck" the lock key combo then? To at least save something, bandwidth.

Also in my opinion, designing of brand new protocol means creating of brand new p2p community unless you wont assure smooth transition which presumes closer cooperation of developers.

That's correct, the new protocol will be totally incompatible with DC.

Note: Latest ptokax has no problem with MyINFO before GetNickList.

Good, I'll fix my client then.

[[ASH]Yoshi]

I should have tested this myself a long time ago but I've been too lazy.. but as I expected there are problems with hijacking the old $Version.. though it seems like NMDC doesn't care if it starts with a char (non number) it does however care if it doesn't. Thus using $Version for communicating client version is bad because of 2 things..

Mainly: This brings limitations to version number even though I think that it shouldn't start with a number.

But also: The version string is so easy modifable in DC++ it's really easy to fake since you can't stop talk about it


*** Connected
From Hub: $Lock TuaTdI;'0(>Tn8%qEg69Wov1^J(fI]7t.:_*?.'[email protected]()@VlHE<D2=Dr Pk=eUI_1w,G):I%Wo8z|
To Hub: $Key vASÃ’'Ã?q?a¦£eÑEC"ð惑töA&äòA¦4Â¥AVWQ?†2––a£BÃ?â€â€

[cyberal]

Ok, and lets see how hard is it to do locate "V:" doing a backward search?

what about oDC users?

[Dj_Offset]

Ok, and lets see how hard is it to do locate "V:" doing a backward search?

what about oDC users?

Yeah, sure... this just proves why this form of client "checking" is broken.

[[ASH]Yoshi]

To Dj_Offset:
Why do you think that me and ptaczek complains? Because we can't write parsing code??? No.. because we both are making hubs.. that's belive it or not a lot different to making clients.. We hate CPU time.. whether it's far below 1ms or not.. I've know exactly how many CPU ticks it takes to do most of my parsing and I can't imagin anyone writing a code that does what I do as fast as I would do it with a clientversion string and a netinfo instead of the MyINFO line.

Stats from Tropical
ASH information
*************
Version: Beta 1.10
Uptime: 0:02:26:08
Online users: 653 / 830
Currently authorizing: 1
Total accepted: 1201
Total rejected: 3352
Handshake timeouts: 79
Connected timeouts: 87
Exceptions: 0

Note: this is a calm time of the day.. but still 3352 rejects in 2 hrs

ASH on Ancient or Tropical might have up to 10 connections/second though mostly denied.. Thus a lot of rejecting... Even though a standard Pos command only takes about 1000-2000 ticks to complete it's still longer than not have to parse at all..

But to the final point .. enlightened by cyberal.. The tag isn't consistent!! oDC/DC++/DCGUI/NMDC2 all have different tags.. This is the madness we're trying to stop..

You might say: I can write fast code that gets all major clients and put em into nice little variables for you Yoshi.. Then I'd say that this isn't even the point.. The point is it's a pain in the ass maintain sutch code when changes occur etc.

// Yoshi out.. this is making me sink

[ptaczek]

Ok, and lets see how hard is it to do locate "V:" doing a backward search? I think a few people in this forum can be helpfull with the boyer-moore substring search algorithm in case you somehow manage to not be able to extract it within a reasonable amount of time (allthough I cant see how this would be the case even on my good ol' 386 DX).

Don't take me wrong. Im also sarcastic often. As far as I know boyer-moore needs preprocessing and is effective with large text data - but you know it probably as well as I do.
But Im not talking only about the id parsing ;) Look, there is more data in the handshake sequence, all the data must be processed, right? If you avoid the processing at the beginning, you will save. But as I can see the discussion has no value...

Why not "fsck" the lock key combo then? To at least save something, bandwidth.

Better than nothing.

Also in my opinion, designing of brand new protocol means creating of brand new p2p community unless you wont assure smooth transition which presumes closer cooperation of developers.

That's correct, the new protocol will be totally incompatible with DC.

Then it will be not DC. What I (and others) try to do is make first steps in shaping the old DC protocol. You've talked about complexity. I agree for now, but if one wants rebuild something without destroying the current structure built on it, then increased complexity can not be avoided. First rise the complexity for a while, adapt client/servers and then gain even lower complexity than at the begining...

[sarf]

All right, fellas, time to sink this discussion.

Whom does this change benefit?
The answer seems to be hub coders, hub owners and hub OPs, in that they can ban/kick clients based on what $ClientVersion string they send.
What has the users gained? Nothing (or so it seems to me). Why should the users then not fake their $ClientVersion string? Or rather, why should they give a "correct" (e.g. one that represents their actual client) $ClientVersion string instead of a "good" one (one that lets them into the hub) ?
The answer to this last question seems to be "well, most of them are lazy mofo's that won't fake this, besides, you are only against this because you are against change, you lazy/evil old codgers" (dramatized version of the discussion so far).
Right. Good.
Now imagine that a coder of a certain client would want a coder of a certain hub to implement a certain feature that would make something easier for the client. It would not help the hub at all, in fact, it would add bloat to the protocol. Let's call it the "Hub Extension" - $HubModel,$HubVersion and $HubCRC (containing the CRC32 of the hub binary (converted to hex)). Oh, and depending on what the hub returned the client would (automatically, but with pre-set defaults) refuse to connect to the hub (maybe with a "this hub is not using a valid software" or whatever).

What would this add? Nothing for the hub (well, maybe something), and something for the client (e.g. the user).

I must say, as long as I don't see any reason to implement this (other than "oh, it makes things easier for me") I will certainly not implement it - hell, I'll even put up a "how to make DC++ send the $ClientVersion of your choice in eight easy file patches" (eight 'cause I want to make it possible to change it using the commands in DC++) just because it is... stupid.

Whatever you may think, ptaczek and [ASH]Yoshi, if you ban or kick clients depending on what they send as $ClientVersion strings, the users will send other $ClientVersion strings - maybe because they have switched to a client that is accepted, and maybe because they have chosen "emulate client XYZ" in the Settings -> Client Emulation. If you can't use the $ClientVersion for identification (which you have said that you know you won't be able to do as soon as the fakers are done sitting with their fingers up their noses), it becomes useless (except as a first defense against idiots, which can already be done by using delayed entry and good scripts).

So, no, this is not something that I would do, since it is "doomed to failure" even by the innovator of the idea.

About evolution of the protocol : almost all protocol changes so far have been extensions, so that the old clients could still be supported. This was one of the reasons of DC++ being so successful. If you want to change this strategy, then you need numbers that support that the number of users of old clients who will not update/change their client is negligible. While this change does not make DC++ directly incompatible with old clients, it means that DC++ supports hubs that are (or are you going to allow clients that do not send $ClientVersion as well?). This means that DC++ takes a stand indirectly against old clients (in my opinion).

No matter - this post has already rambled for far too long, and will now be cut kinda half-long.

Sarf
---
"Perl has grown from being a very good scripting language into something like a cross between a universal solvent and an open-ended Mandarin where new ideograms are invented hourly." - Jeffrey Davis

[ender]

$ClientVersion reminds me of HTTP User-Agent - most browsers send it, so that the servers could collect statistics, however some servers (*cough*MSN*cough*) discriminate on this information. I remember when I just started using GetRight (long time ago), some servers didn't allow me to download with it - luckily it had a setting which allowed me to fake my browser's User-Agent... At first, this was a registry-only setting, but later versions added a simple combo box for choosing the preferred string. Now, why wouldn't DC client authors do the same?

[[ASH]Yoshi]

To sarf:

Come on!! The same stupid replys all the time.. Get real please. I could say read above and you'll get answers to most of your questions but as it seems it won't help so I might as well explain it all again.. Are you trying to wear me down or what???

Why users benifit from banclient?
Lots of users using NMDC don't even know that DC++ exist. If the login to a hub and it says NMDC isn't allowed here because blabla .. please download DC++ or oDC instead. Or sometimes you'll notice the message this DC++ version isn't allowed due to upload limiter (which gotta be in disfavour for the users) .. download this instead. And so on and so one.. There are like a million reasons why clientbans is good for everyone. Just connect to Ancient spirit in kindly ask any of their ops and they'll lay it all out for ya.

Faking!!?!
Most users have no/little knowlege about programming. Take my word for it. Thus faking a $ClientVersion string is still harder than faking a $Version by changing in your DC++ GUI or faking a DC++ tag by entering on in your description. With that said I'm gonna repeat my previous point since your sight seems rather selective. Faking a Lock string (client2client detection) to look like a DC++ version isn't harder than faking a Clientversion string.. + faking is always possible thus it shouldn't be a part of this discussion.. And there's nothing more stupid than letting a guy login fully just to kick him. And there's the consistent tag issue.. it's so NOT

So again: It's NOT about faking.. it's about less CPU time etc. please read above.

About new protocol extensions:
All you guys seems to say is that this would bring chaos to the protocol.. Why I wonder? Isn't the tag version of communicating Version as confusing it could be? isn't this way a lot better? And for the hub vs. client bit. The clients never has the same cpu load/demand on good programming/good solutions as the hub do. And what does users want? Lag free hubs, hubs with lots of users and good downloading speed (clientbans). Note: haven't made and clinical survey on this area which I'm sure you will demand of me later, lol but I'm rather sure it's about right.

I must say, as long as I don't see any reason to implement this (other than "oh, it makes things easier for me") I will certainly not implement it - hell, I'll even put up a "how to make DC++ send the $ClientVersion of your choice in eight easy file patches" (eight 'cause I want to make it possible to change it using the commands in DC++) just because it is... stupid.

I will hardcode the ban of you client or whatever in ASH and make ASH kick directly for even mentioning something containing the word sarf and blablabla
<-- Is this really mature? Do we need this in this discussion? (No hard feelings)


About evolustion:
Why can't you see mainly that the ClientVersion is a consisten way of communicating version as NetInfo is a consisten way of communicating that info? It's so obvious! And we ARE able to change both in the hubs and clients.. ptokax is taking over the world And the NMDC hubs won't bother if we send the info to them.. and it's possible to get the DC++ to be able to handle both as the GetNetInfo should be a trigger that disables tags and uses NetInfo instead. Thus the obvious conclusion should be that in a short future after making these changes there would probably be some confusion but very short after everyone will have hubs supporting it and the admins of the hubs with a good clientban version ;D will have an effective way of telling people to use the latest DC++ instead and get all new features etc

To ender:
If ptokax and ASH will support $ClientVersion as DC++ it won't be anything like User-Agent. Which btw I don't really get why you're talking about at all

[Broken_Haiku]

I'm...not sure what is really going on here. I've read your bickering back and forth and you're not gaining much headway are you? Here's a few things that I found just utterly stupid:

cologic: "Ugh, please not another fucking protocol extension to appease meddling ops."

Were I an argue-interpretor I'd reply: Syntax error/missing argument, "I do not approve of <x> because <reason>, instead I suggest <y>."

cyberal: "I agree with Hess, DC++ has hijacked the description field, a NetInfo command should have been implemented from the beginning!"

Where's the constructive argument? Hindsight does nothing, where do we go from NOW?

Ender is the first one to ask something that brings the conversation onward, he asks what GOOD this would be, fair enough.

Cyberal says "I agree with Hess, DC++ has hijacked the description field, a NetInfo command should have been implemented from the beginning!"

Another hindsight, ONWARD guys, ONWARD.

Okay I won't quote everything here but you GOT to start looking at what we have here and where to go from now. I'm just a low_bit programmer standing with one foot on the OP-side of this debate. Arguing about how EASY it would be to put in a cheat code to circumvent this is a moot point, so someone here just missed the whole idea. The POINT still is that it will get rid of description field tag cheaters and that IS a big plus, it doesn't take any major effort to add. The clients have evolved and there is no reason the protocol shouldn't as well, as long as it becomes a standard.

I'm known for sticking my chin out from time to time and by all means; those of you who feel offended can throw yourself at me, tearing me to pieces verbally. Those of you who really want to make something happen, go ahead and read eachothers posts and reply in a constructive manner. Kudos to you.

/Broken

[Dj_Offset]

$ClientVersion reminds me of HTTP User-Agent - most browsers send it, so that the servers could collect statistics, however some servers (*cough*MSN*cough*) discriminate on this information. I remember when I just started using GetRight (long time ago), some servers didn't allow me to download with it - luckily it had a setting which allowed me to fake my browser's User-Agent... At first, this was a registry-only setting, but later versions added a simple combo box for choosing the preferred string. Now, why wouldn't DC client authors do the same?

I will, and I've started working on it...

[cyberal]

I will, and I've started working on it...

Why?
Who would benefit out of that?
We know you can do it Dj_Offset, grow up and argue how YOU would like it to be done instead of destoying for others!

[Dj_Offset]

I will, and I've started working on it...

Why?
Who would benefit out of that?
We know you can do it Dj_Offset, grow up and argue how YOU would like it to be done instead of destoying for others!

Why? - Because QuickDC has the same capabilities as DC++, but _some_ scripts discriminate it because it isn't DC++ (and because they have never heard about QuickDC).

Emulation makes me able to join these hubs without wasting $$$s on Bill & co, and no one
notices.

I'm currently looking into three different modes implemented like the "identify as" option in the Opera browser:
- QuickDC mode - all QuickDC extensions work (Upload limit etc),
- DC++ mode (no upload cap at all
- NMDC2 (upload/download speed limit according to Hess' guidelines; 1/8 ratio)

[cyberal]

Why? - Because QuickDC has the same capabilities as DC++, but _some_ scripts discriminate it because it isn't DC++ (and because they have never heard about QuickDC).

And by trying to mask as other clients you think QuickDC will be widely accepted? I think not, rather the opposite.. "why is he masking his true identity? He must have something to hide, CHEATER CLIENT!!"

[Dj_Offset]

Yeah, sure but if my "emulation" works, you will not even know it... so how are you going to lock me out for not doing anything wrong except sitting in a free operating system?

[[ASH]Yoshi]

DJ offset:
We probably won't as you say.. Cheating will always be possible and if you don't screw up and I don't belive you will there won't be a way of telling your client from DC++.

But I think this isn't what you should aim at.. I belive you're sad beacause nowone knows about your client etc. And I think I can imagin that frustration. Anyway you should try and make your client so damn good that no op ever would dream of banning it.. And actually that itn't too hard. Anyway I belive I know how you feel and if you'd like it I'll do everything in my power to help you on this matter..

I'm very very NOT against new clients.. I think it's great.. so...
Feel free to contact me if you'd like to talk about it.

[cologic]

Yoshi:
We probably won't be able to prevent you from instituting $ClientVersion, as you say.. Useless protocol extensions will always be possible and if you don't screw up and I don't belive you will there won't be a way of telling your hub not to this.

But I think this isn't what you should aim at.. I belive you're sad beacause nowone knows about your hub etc. And I think I can imagin that frustration. Anyway you should try and make your hub so damn good that no op ever would dream of using anything else.. And actually that itn't too hard. Anyway I belive I know how you feel and if you'd like it I'll do everything in my power to help you on this matter..

I'm very very NOT against new hubs.. I think it's great.. so...
Feel free to contact me if you'd like to talk about it.

[Dj_Offset]

DJ offset:
We probably won't as you say.. Cheating will always be possible and if you don't screw up and I don't belive you will there won't be a way of telling your client from DC++.

But I think this isn't what you should aim at.. I belive you're sad beacause nowone knows about your client etc. And I think I can imagin that frustration. Anyway you should try and make your client so damn good that no op ever would dream of banning it.. And actually that itn't too hard. Anyway I belive I know how you feel and if you'd like it I'll do everything in my power to help you on this matter..

LOL! Well actually, I just want to be able to download. I don't care what others think of my client. My goal is to provide a working solution on Linux, while 99% of the DC userbase is on windows.

There are alot of hubs requiring you to use DC++.
Client emulation is just a way around the few hubs that actually do this checking.
To be "nice", I will actually provide the same limitations that DC++ have (i.e. no bandwidth limits for upload).

[cyberal]

Dj_Offset:
But seriously, wouldn't it be better to be as open as possible by showing clearly what client you are using and where to find it? Like dcgui that implemented the dc++ tag but with <DCGUI instead, THATS smart. Hiding your client certainly won't help more user find it!

cologic:
yeah, real mature

[cyberal]

btw. Dj_Offset, I read about your client and looked at some screenshots.. must say it looks REALLY good.. many things is much better than in DC++ ... trying it tonight..