$ClientVersion <version>|

Technical discussion about the NMDC and <a href="http://dcpp.net/ADC.html">ADC</A> protocol. The NMDC protocol is documented in the <a href="http://dcpp.net/wiki/">Wiki</a>, so feel free to refer to it.

Moderator: Moderators

Sedulus
Forum Moderator
Posts: 687
Joined: 2003-01-04 09:32
Contact:

Post by Sedulus » 2003-07-11 09:28

cyberal wrote: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?
are you contradicting yourself now? using $ClientVersion would eliminate the tag in the MyINFO (see: hijacking), hence it would not be seen / advertised.

cyberal wrote:Like dcgui that implemented the dc++ tag but with <DCGUI instead, THATS smart. Hiding your client certainly won't help more user find it!
you're missing the point. no one cares about 0.1% of the market, hubowners won't know they're blocking a decent client. there are plenty of hubs that don't allow dcgui.
quickdc has a <QuickDC tag, so hiding identity would normally only be used for hubs with ignorant owners (plenty).

cyberal wrote:cologic:
yeah, real mature
hmyea.. maybe not, but this:
I belive you're sad beacause nowone knows about your client etc. And I think I can imagin that frustration.
is preposterous. the emulation was for obvious reasons (look up how long it took for the Opera browser to be accepted by dhtml pages), and Yoshi goes and invents some personal "issue"
http://dc.selwerd.nl/hublist.xml.bz2
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)

[ASH]Yoshi
Programmer
Posts: 21
Joined: 2003-07-07 08:09
Location: Sweden, Linköping

Post by [ASH]Yoshi » 2003-07-11 10:15

To cologic:
Having a hard time comming up with new stuff to write huh? :D

Well I'll tell you a few things about ASH. I think I've got one person each day begging me to be able to try out ASH.. And as for me I don't care.. I don't even want to decide how's getting it... it's up to the operators of Ancient Spirit as the hub is made for them. Not that any of these should matter nor be a part of this discussion..

To Dj Offset:
It's all up to you.. just trying to help where possible.

[ASH]Yoshi
Programmer
Posts: 21
Joined: 2003-07-07 08:09
Location: Sweden, Linköping

Gahh..

Post by [ASH]Yoshi » 2003-07-11 10:24

To Sedulus:
Whatever.. Dj Offset isn't really topic.. It was under the feeling of that he'd consistently will try to ruin this just because.. I simply tried to be nice as I honestly know what it feels like.. AND NO cologic I'm NOT talking about ASH :D

Couldn't we stick to topic.. non of the post this day has contained any good arguments.. just stuff about I will ruin this just beacause I don't like it etc. And I agree.. mine havent been any good either but I'm rather compelled to answer all your replys since if I don't you'll just say I'm not .... All the points ptaczek made etc remains.. why can't you guys see this?

About tags.
If there's no other way Sedulus how do you think you should display your info?? Send it as a PM to cyberal.. I don't wanna here it.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

as tempting as it is to keep flaming...

Post by GargoyleMT » 2003-07-11 11:09

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


Well, actually:

GargoyleMT wrote: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?


Arguing over whether or not faking this tag is an important solution to its long-term viability is obviously going nowhere. So let's begin again.

Yoshi, Ptaczek, please state the problem that caused you to come up with $ClientVersion as a solution. If you'd like real solutions, mention what has been tried in the past, and what was wrong with it.

This is, of course, based on elementary Software Engineering principles. If you want an alternate solution, you've got to give us your Requirements.

For instance, you should probably elaborate on your CPU usage issues, instead of hinting at them.

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2003-07-11 11:28

Having a hard time comming up with new stuff to write huh?

No, but posts such as that one are so much more fun, and someone else eventually brings up what I was going to post anyway.

Broken_Haiku
Posts: 4
Joined: 2003-07-11 05:53
Contact:

Post by Broken_Haiku » 2003-07-11 11:52

Let's sum things up:

- This thread is about the suggested protocol extension 'ClientVersion <version>', so lets for now, forget any proprietary totally new protocol.

- The why of the extension has been stated, as I understand it:
1) To avoid easy cheating.
2) Lessen the load on the hub
3) Make the 'raping' of the comment field superfluos.

- We've also stated that cheating will always be possible, and if we'd give up based on that, we could just forget DC in whole.

- Now in detail, what negative sides can you see to this extension and if so, what alternative solutions do you suggest?

- If you find this a GOOD idea, let's go into implementation details. Syntax, variable type et.c Go ahead, the floor is yours.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-07-11 13:09

Broken, you either get to mediate, or post your point of view. Not both. Please pick one.

Broken_Haiku wrote:- The why of the extension has been stated, as I understand it:
1) To avoid easy cheating.
2) Lessen the load on the hub
3) Make the 'raping' of the comment field superfluos.


You're mixing up things here. $ClientVersion does not imply any change to the way client configuration status - mode, hub, slots, are conveyed. That should be another thread (because it's far less controvertial, I would agree for separation of ++ tag information into $NetInfo and out of the description/$MyInfo - that will save bandwith, as share updates and changes in slots/hosts/mode naturally happen at different times).

(Cologic's stats on distribution of protocol commands - in the "Distributed hub" thread is useful for command distribution, at least for his hub.)

Broken_Haiku wrote:- We've also stated that cheating will always be possible, and if we'd give up based on that, we could just forget DC in whole.


Well, the reason I brought it up is that any feature needs to be thought through fully. $ClientVersion is trivally fakable to anyone posting here, and to everyone with the help of just one "rogue" programmer. So far, the plusses for $ClientVersion have been scant... and the problem is that it can be so easily undermined by faking. I'm personally worried about when $ClientVersion is so widespread that it can no-longer be either trusted, or used to filter out bad clients. We will be back in this situation again... or rather, hub writers will be back in this situation again. This is, fundamentally, a short term-patch. Does everyone agree on that, at least?

Broken_Haiku wrote:- Now in detail, what negative sides can you see to this extension and if so, what alternative solutions do you suggest?

- If you find this a GOOD idea, let's go into implementation details. Syntax, variable type et.c Go ahead, the floor is yours.


The problem is that we haven't really seen what the problem is, not stated oturight in unambiguous language by Yoshi or Ptaczek (or anyone else who might be lurking). I think there might be better solutions.

Nev
Programmer
Posts: 40
Joined: 2003-01-03 13:29

Post by Nev » 2003-07-11 13:43

When one want clarity, one crave for a broken haiku. =)

Great summary!

As NMDCHub, ash, pto, dch++ and most other hubsofts totally ignore messages it does not understand, sending $ClientVersion <...>| can in no way have a negative effect. Any extention that serves a purpose and is in no way in conflict with running hubs and have support from running hubs, should be supported!

Do the math; compute incoming tcp traffic of singles of ClientVersion and compare to a mere 1000-nicklist-stream, 1000 Hello broadcast (sigh), 1000 MyINFO's broadcast, and then a 1000 MyINFO-stream to a user who'll get kicked by a bot. That's 1000 $Quit by the way. Tjeesus. We want to save ourself from every O(N) we can.

If a hubsoft stall, on receiving a ClientVersion, the author of that hubsoft made a poor reverse-engineering (and should be shot on sight, IMHO =).

However, a ClientVersion would really make a great contribution to us hubsoft-developers, and in the end, us hubusers. Really!

I think this is getting silly. When several hubsoftdevs and several hubowners think this is one of the greatest inventions since $Supports, in order to serve better hubs; Why argue?

Be Nike; - Just do it!

sarf
Posts: 382
Joined: 2003-01-24 05:43
Location: Sweden
Contact:

Post by sarf » 2003-07-12 07:13

All right, say "we" (e.g. someone codes a patch and sends it to arne, Opera and other client coders) do it.

Let's say that developers of Hub Soft XYZ and ABC (along with hubowners) wants a few (mandatory) commands sent to the hub :
$DownloadInformation <user> <filename> <size>
and
$UploadInformation <user> <filename> <size>

Should "we" do this as well since "several hubsoftdevs and several hubowners" would want it?

Should "we" add the $Smiley command because some hubsoft developers and their testers (hub owners) want that?

Just because hub soft developers and hub owners think that something is one of the greatest inventions since $Supports, it does not necessarily follow that they are right, nor that client users would think so.

Hub soft developers develop for their users - hub owners.
Client developers develop for client users (which may include OPs, hub owners, Joe and Jane Leecher as well as Mr. Jack Average Sharer).
This leads to differing opinions what clients should and should not do.

We seem to be stuck on why $ClientVersion won't work. It will probably work - as some have said, no one can stop you from implementing it. Not many will be able to stop clients faking it either.

The main reasons $ClientVersion was suggested was (I believe) to decrease the bandwidth and CPU usage by undesirable clients (defined by the hub). Your examples seem to imply that it is mainly NM DC which is the undesirable client - NM DC can be blocked using already existing scripts (and be sent a PM with the reason why it was blocked). It was also meant to be a standardised way for clients willing to report what "model" they were.
Once again, I will say that this will not happen as you only need one "rogue" coder to make a "stealthed" version of a client or somesuch, and once that is done the savings you got in CPU/bandwidth starts to be eaten up by the fakers - then the whole "checking for faking clients"-carousel starts again.
I've said it before, I'll say it again - there exists clients today that can fakeshare and slotstop (everything except the filelist and small files, and since they can choose their filelist to be one that does not include small files it's not a problem). They are - for all intents and purposes except downloading shared files - a normal DC++ client. The patch needed to remake DC++ to this evil client is MUCH smaller than DC++k (which I dread porting the next time arnetheduck releases a new version), and can be meshed quickly with new versions. Clients such as these are the real problem, not "old" or "undesirable" clients. I have no solution, however, and must leave my comfy home for a day, so this post has to end on this rather down note.

Why argue?
Because Man is a cranky animal, as well as a lazy one.

Sarf
---
All men are created unequal.

Broken_Haiku
Posts: 4
Joined: 2003-07-11 05:53
Contact:

Post by Broken_Haiku » 2003-07-12 07:31

There has always been a ping-pong game between security and it being hacked, it's _still_ no meaning to give up.

Here's two bits of opinion anyhow, and it's a quote from an online friend actually:

"To implement this little silly $ClientID is a matter of 5 lines of code. And it will save traffic and will unify the clients. For now there is a jungle."

oh and Sarf? Kicking NMDC by scripting will still generate much more traffic/load, JUST as Nev stated. So even if we don't get rid of all the fakers (we never will.) It will provide a fair bit of streamlining efficiency.

Back again to if(Argument_A!=true);Suggest(B);

/Broken Haiku
-----
"Get a point of view, but always analyze, always be ready to re-evaluate it or you will get stuck with the foot of your own ego in your mouth."

[ASH]Yoshi
Programmer
Posts: 21
Joined: 2003-07-07 08:09
Location: Sweden, Linköping

Post by [ASH]Yoshi » 2003-07-12 08:25

*sigh* I won be long.. I'm too d*mn tired..

1 comment.. since I didn't read any longer

To sarf:
Implementing clientversion is far different to implement something that some hubowners want. so don't be silly...

sandos
Posts: 186
Joined: 2003-01-05 10:16
Contact:

My own little summary

Post by sandos » 2003-07-13 01:00

My first post to this thread (I think). This is mostly meant for me to understand what this discussion is about:

Some people want to implement this $ClientVersion command. The reasons stated varies, but the prominent ones seems to be

1) keeping old clients out of hubs/helping users to upgrade
2) lessening the cpu-load on big hubs

Pros:

1) Its a fast way to get rid of misbehaving/old/ignorant clients/users.
2) Provides a forced upgrade of clients.

Cons:

1) Only requires abuse from one op of one big/otherwise atttractive hub to dramatically lessen the usability of this command. This will make people use a client which can easily edit their $ClientVersion string. Cologic thinks, if Im not mistaken, that hub ops get too much power with this command. The only power they get, imo, is to make another command useless, and even if no single op ever abused this command (highly unlikely?) the power will never apply to me, or anyone who doesnt want to be controlled in this way.
2) No single old client will be able to join the hub. I call this forced client evolution. Every client who wants to join a CV-hub needs to update its protocol. Still, the protocol is exactly the same, besides some lamer-protection $ClientVersion command.
3) What if a user has problems, for whatever reason, to run certain versions and those versions are the only ones allowed? This will also make people use a faking client.

Both cons #1 and #3 are related, and makes it likely that the command will only be temporarily effective. Con #2 may not be a problem to most people, but I feel pretty strongly about it. Pro #2 isnt even used by the proposal.

I do think that this change is very minor, and there is really nothing to it. But that _is_ the problem: It wont do much good now, and probably will do _nothing_ in a few months. This will end up being old, unnecessary protocol garbage that no-one will use correctly. I dont think the little good it does outweighs even the extremely easy implementation-burden and protocol-polluting.

sarf
Posts: 382
Joined: 2003-01-24 05:43
Location: Sweden
Contact:

Post by sarf » 2003-07-13 06:16

Thank you, sandos, for the concise explanation I've been meaning to write (but my ego got in the way). :)

Broken_Haiku wrote:There has always been a ping-pong game between security and it being hacked, it's _still_ no meaning to give up.
Perhaps not, but there is no reason to suggest things that will be counterproductive - after all, we have to factor in the amount of bandwidth $ClientVersion will consume (even after it has become useless).

Broken_Haiku wrote:[snip]
"To implement this little silly $ClientID is a matter of 5 lines of code. And it will save traffic and will unify the clients. For now there is a jungle."
Unify the clients? Ehm... no, not in my opinion. No standards has been suggested for the $ClientVersion command, nor would any be effective (IMHO) - a plethora of different client version strings would be the result.

Broken_Haiku wrote:oh and Sarf? Kicking NMDC by scripting will still generate much more traffic/load, JUST as Nev stated. So even if we don't get rid of all the fakers (we never will.) It will provide a fair bit of streamlining efficiency.
Ahhh... but you can check the lock of the client BEFORE it is allowed in the hub (using delayed entry and other tricks), and not allowing it in unless it has EXTENDEDPROTOCOL in its lock - but I digress.

In any case, I am now at an impasse - I won't support this command as it stands.

Sarf
---
The concept is simply staggering. Pointless, but staggering.

Broken_Haiku
Posts: 4
Joined: 2003-07-11 05:53
Contact:

Post by Broken_Haiku » 2003-07-13 06:28

Thank you Sandos, a very good reply! More of this kind of input, please!

sarf: Oh yes, bandwidth. I forgot how MUCH bandwidth a clientversion would take ;o). And as for just checking the extendedprotocol that does not provide enough info.

As for the usability of this protocol it seems the debate has mostly been hung up on if it can be faked or not. We _know_ that it can be faked, but this could in any case, provide us with a new information field and again leaving the description field alone as should be. Should the proposed $ClientVersion contain:

- Client
- Version
- All the info that now resides in the description tab
?

If it is to contain the latter the string must also be automatically resent to the hub when a user refreshes.

Do we have any suggestions of Syntax/structure?

xayide
Posts: 21
Joined: 2003-06-12 09:38

Post by xayide » 2003-07-13 08:13

Donnu if I'm all wrong here, BUT:

If you set the hub to do a connect to the client when it arrives. The client will respond with Lock/Pk which can tell:
EXTENDEPROTOCOLABCABCABC / DCPLUSPLUS0.251ABCABC

Clientversion, i.e 0.251
ClientType, i.e DCPLUSPLUS


And it will also tell what it supports / Nick of user / real IP (could sort out tunnelers). And with that information u can filter on whatever client u like.
Version / type or whatever.

I guess I made a stupid reply here. :-)
You can always reach me nowhere!

sarf
Posts: 382
Joined: 2003-01-24 05:43
Location: Sweden
Contact:

Post by sarf » 2003-07-13 11:17

Broken_Haiku wrote:[snip]
sarf: Oh yes, bandwidth. I forgot how MUCH bandwidth a clientversion would take ;o). And as for just checking the extendedprotocol that does not provide enough info.

Well, it would take care of the NMDC clients. Oh well.

Broken_Haiku wrote:[snip]Should the proposed $ClientVersion contain:

- Client
- Version
- All the info that now resides in the description tab
?

I'd suggest that it should contain : client "model" (DC++, DCGUI, et cetera) and client version (which would be whatever the author(s) of the client would want, e.g. no standard on the version numbers). A recommendation would be to seperate model and version with a space character (or perhaps 0xFF, since it would allow nifty model descriptions).

I'd also recommend adding a new command, $ConnectionInfo or whatnot, which would return : number of slots currently open for downloading, current number of downloading slots used, number of hubs connected to (as a user, as a registered user and as an OP), as well as active, passive or socks5 mode (well, I guess any mode should be possible to have) and "extra" info (such as the speed below which new slots are opened et cetera and bandwidth limiting, if the client reports that).
To make it easy to interpret and extend, I'd suggest using XML - this way it would be easy to add other things later on (but yes, it would be a bit bandwidth intensive).
Whenever something is changed in the info, a $ConnectionInfoChanged should be sent to the hub, which may choose whether or not to get the updated data (this would prevent "legal" DoSing of a hub by sending lots of $ClientVersion/$ConnectionInfo:s).

Hope this helps!

Sarf
---
"HERBS: medicine for cavemen" - Daniel Rutter

[ASH]Yoshi
Programmer
Posts: 21
Joined: 2003-07-07 08:09
Location: Sweden, Linköping

Off for a while

Post by [ASH]Yoshi » 2003-07-14 17:14

Sorry.. been away for a while..

Anyway.. this discussion is going nowere.. I'm going away for a week now.. however I'll try to resume it on my return.. I have some new thoughs etc. and I will make a new thred on this later.. thus you'll be able to flame that one instead :D

I haven't read the last posts as I'm too tired :D I've considered this topic dead for a while now and won't spend more effort on it..

I'll be back the 22:nd .. so around the 23:rd expect a new topic to flame/think about :D

// Yoshi

TheNOP
Posts: 275
Joined: 2003-07-07 21:41
Location: Quebec

Post by TheNOP » 2003-07-17 10:47

hi
i might be crazy but.....

my :idea: is base on the assomption that md5 result of a program cant be easyly be reproduce...

find a way to send that result to Hub (tru $lock ?) in conjonction with $version/tag and hub owner will be able to block any client they seem fit.

i think hub could be made to expect it in tag or description easyly.
but it would be better sooner then later to save resources

could it be done ? without change in protocol ?
or is it just a plain mad :idea: ?
TheNOP

Have you read the FAQ?
Or the sticky ? It might give you idea.

Sedulus
Forum Moderator
Posts: 687
Joined: 2003-01-04 09:32
Contact:

Post by Sedulus » 2003-07-17 11:20

TheNOP wrote:or is it just a plain mad :idea: ?

yes..
this has been suggested numerous times

what they/you fail to understand is that you cannot trust the client to send a "correct" hash,
why would a cheater confess to cheating instead of sending a normal dc++'s MD5sum?
http://dc.selwerd.nl/hublist.xml.bz2
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)

TheNOP
Posts: 275
Joined: 2003-07-07 21:41
Location: Quebec

Post by TheNOP » 2003-07-17 12:11

to Sedulus

as you can see i am fairly new to dc protocol and still studying it... :)

i know no client can be trust and will ever be trustable....
but $clientversion was not only propose for anticheating purpose but also a way to block most of the unwanted clients earlyer as i understand it.

you did not answer my question.

could something like that be done early in the protocol ? without adding to the protocol ?
TheNOP

Have you read the FAQ?
Or the sticky ? It might give you idea.

TheNOP
Posts: 275
Joined: 2003-07-07 21:41
Location: Quebec

Post by TheNOP » 2003-07-18 13:13

to Sedulus

after reading and thinking all night.... outch my head

i finaly see why $clientversion is not a good idea even in lock/pk(witch is doable)
it's not most unwhanted clients (like i tough first) but all actual clients that would cease to work.
well kind of in a few months after implimantation :)

i came to the conclusion that a more secure protocol is needed and would be fare more usefull.

base on public key to encript and master key to decript
client maker summit master key to hub maker.
hub maker set some rules for client feature that could be concider as leeching tools base on hubs owners/ops/users demands to add or refuse this client summition.

the only ways for cheater would be a master key/public key leakage so those keys would have to be hide in the compiled programs.

but this is a subject for an other tread as it is almost off topic in here

regards
TheNOP

Have you read the FAQ?
Or the sticky ? It might give you idea.

Locked