Client identification vs. DC tag in description
 

News:

29 December 2022 - PtokaX 0.5.3.0 (20th anniversary edition) released...
11 April 2017 - PtokaX 0.5.2.2 released...
8 April 2015 Anti child and anti pedo pr0n scripts are not allowed anymore on this board!
28 September 2015 - PtokaX 0.5.2.1 for Windows 10 IoT released...
3 September 2015 - PtokaX 0.5.2.1 released...
16 August 2015 - PtokaX 0.5.2.0 released...
1 August 2015 - Crowdfunding for ADC protocol support in PtokaX ended. Clearly nobody want ADC support...
30 June 2015 - PtokaX 0.5.1.0 released...
30 April 2015 Crowdfunding for ADC protocol support in PtokaX
26 April 2015 New support hub!
20 February 2015 - PtokaX 0.5.0.3 released...
13 April 2014 - PtokaX 0.5.0.2 released...
23 March 2014 - PtokaX testing version 0.5.0.1 build 454 is available.
04 March 2014 - PtokaX.org sites were temporary down because of DDOS attacks and issues with hosting service provider.

Main Menu

Client identification vs. DC tag in description

Started by ptaczek, 16 October, 2003, 01:57:41

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ptaczek

Hi,
in next release of ptokax Im planning to implement extension to the DC protocol.
I have tried discuss the extension with other client/hub developers but I have received no positive responses.

What is it about:
Today's most used clients sends their identification in so called tag in the description field. This way the hub will get all BASIC information about the client after the initial login sequence in the $MyINFO command.
The same $MyINFO data extended by this tag is then dispatched to all clients on the hub and is also re-send to all users on hub when certain user changes his slots/share settings or when he joins/parts another hub. On big hubs there is a lot of bandwidth being wasted by this MyINFO ping-pong game.

The solution invented by me and Yoshi is to send a new command $ClientID right after the $Key command and before the $ValidateNick cmd. Therefore the hub can decide right after receiving the client id (or in case of profile-based access restriction after the nick validation) if the user will be accepted or rejected and no further data exchange is needed. Moreover, the MyINFO data is shortened by the length of DC tag and also there is no need to re-send it when certain user changes his slots settings or when he joins another hub.
$ClientID is also send by client after every change of settings of slots or share or after join/part of another hub to reflect necessary changes but is not dispatched to other users - the information is useles for others.
All this will lead in lower data throughput and DC network will get simple, generic client identification mechanism.

The $ClientID format:
$ClientID $$$$$$|

The command parameters are extendable by adding fields after the basic set and the hub should be able to parse all fields in the set and ignore unknown parts, if they are appended.

Meaning of every field is determined by the order, so no preceeding M:, V:, S: etc. is needed.

Every new field added by clients MUST be discussed and documented to assure proper order of new fields.



Even if 'leading' client/hub developers do not agree with this DC protocol extension, there is a lot of ppl finding this solution more intuitive than the DC tag mangling of description field.
Moreover in case of immense necessity the hub can always re-construct the DC++ tag and add it to the MyINFO before dispatching to others.
-ptaczek-

This whole physical universe is a hologram.
[Cosmosis - Contact: The First Step]

PPK

I like this idea. I hate tag from time of first release of dc++ with this shit (0.16)
I all the time do modified clients without this and all the time want to same bandwidth (and in first releases to hide dc++ because is banned on more hubs :D and maybe for stupid x slots per hub rule :]). Now is time to replace tag with anything inteligent and this is the good thing. If any other client/hub developers want to stop this...why don't stop dc++ creator before TAG is released ? :))
I wait to next ptokax release with $ClientID and i delete tag from my "hacked" client forever :] Maybe be my client banned from more hubs...but on hubs where is my home is this accepted 8)
"Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris." - Larry Wall

[ES]latinmusic

Supporting this at all!!!!

Sedulus

ptaczek,
I recall the $ClientVersion discussion on the dc++ board and in the dev hubs.

this $ClientID has not been discussed, as far as I know.
please stop by the public or private dev hub if you want a real discussion.

some arguments about $ClientID:
- it's not very extensible/optional. using V: H: etc.. in there would be a lot nicer. this would also make it more bandwidth friendly, like this: user has only changed amount of slots -> only update the S: variable.
- share size in the $ClientID? would that mean that the users in the hub will not see the info? (this also applies to the rest of the info, but you and yoshi seem to think that users should not be bothered with that information, correct me if I'm wrong)
- if the info was to be forwarded to users (OPs for instance), wouldn't it be ugly to stick a regular/old-dc++-style myinfo update to them? that sounds like an half-assed solution. in that case a nick prefix would be better imo (like all commands in DC, so they do not have to be modified before sending them out), and forward the ClientID to those who 'need' it.
- the name ClientID is not appropriate if slots/share/hubs/mode are in it, I think

uhmz.. that was the short version.. :)
I haven't discussed it thoroughly with the others in dcdev, so the long version is not available yet ;)

GargoyleMT

I think Sedulus is being excellent... if you want dialog with people surrounding DC++, start a thread on the forum, or come in the private or public DC development hubs.

A practical note: didn't Bkg2k implement the $ClientId at the point in the handshake that you recommended, and then  discovered that NMDCH has problems with it?  If so, implementing this would really hurt any client that enables it.  Regardless of its merit, NMDCH is still in wide usage, and users will change clients if one prevents them from getting into their favorite hubs.  (Hence, bad idea for any client, no?)

pHaTTy

It's an ugly fosil...
Resistance is futile!

fusbar

there is other questions.. first, some hubsofts disconnects users who send unknown data, so this means that you need to add some magic to the $Lock string so that clients can recognice that it should send a clientID.

I have to agree with sedulus, why force ordering on the arguments, thats not extandable at all. Specialy if there is optional data as download_limit, upload_limit, open_slots_below and other information.

And this is not backward-compatible for older clients. This can never be used by nmdc-clients.

I can agree that the dc++ high-jacking of the description-field for its tag is ugly, but i can't see a better solution. Regarding the bandwidth, i would be interested in the numbers. Has someone calculated how much will be saved? ,))

PPK

#7
Quotethis $ClientID has not been discussed, as far as I know.
And where arne discuss before start spamming all users on dc network with search spams and unusefull tags ? :D
If i be normal user is for me usefull only one thig from tag...its mode :]
Quotewould that mean that the users in the hub will not see the info?
No, all users normal receive myinfos.
QuoteA practical note: didn't Bkg2k implement the $ClientId at the point in the handshake that you recommended, and then discovered that NMDCH has problems with it?
Yes first problem is here.... :(
Quotethere is other questions.. first, some hubsofts disconnects users who send unknown data, so this means that you need to add some magic to the $Lock string so that clients can recognice that it should send a clientID
$Supports is good solution 8)
QuoteRegarding the bandwidth, i would be interested in the numbers. Has someone calculated how much will be saved? ,))
Yes it's time to get numbers :))
"Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris." - Larry Wall

Sedulus

QuoteOriginally posted by PPK
And where arne discuss before start spamming all users on dc network with search spams and unusefull tags ? :D
If i be normal user is for me usefull only one thig from tag...its mode :]
1. you're disregarding the OPs which I clearly mentioned
2. the 'unuseful' tag was created when hubowners were banning DC++ because it was multihub. don't blame arne for that.
3. search spams? hubs need to implement flood protection, whether this is caused by normal clients or malicious users. if hubs start kicking/banning users for spam, dc++ will be modified, I assure you.

QuoteNo, all users normal receive myinfos.
ah..? that means that clients should send _both_ clientid and myinfo on changng sharesize?? that smells like bandwidth wastage to me....

[ES]latinmusic

Nice to see you around sedulus
My thoughts, if this one is implemented, this could be a new standar, so the really question could be:
The thing posted by ptacek is better than the current way or not?.  The new way could generate in next future more subfeatures, way of control or whatever in the clients or not?.
If the feature is interesting for the reasons commented or others must be implemented to have a better future into dc community, althougth always compatibility to old modes must be maintained.
What about?.

OpiumVolage

This thread seem to become familiar to me, look like the really old discutions between HELO and extention that became EHLO on smtp protocol :))

And these have never been solved before real protocol discutions on half-private mailling list.

Please, try to find something matching everyone neds before doing any implementations.

I's just my humble opinion, shared at least with myself :))

PPK

Quote1. you're disregarding the OPs which I clearly mentioned
OP's are lazy :D (I mus't know a am op 2 years :]) ... hub must disconnect "bad" users immedialy after receive info on hubs/slots/upload limit, i don't want to kick few hundred users and flooding chat with kick messages :D But find upload limit it's too hard if there is L:  B:  U: :-(
Quote2. the 'unuseful' tag was created when hubowners were banning DC++ because it was multihub. don't blame arne for that.
Yes i know why is the reason for TAG. I see mass kicking of users with dc++ X( Btw tag make this kicking easy :D But tag not the right way....first version send myinfo with tag, new version resend myinfo sometimes (sometimes send same myinfo), version 24 and newest resend myinfo on any tag change, thats not the right way for me ;(
Quote3. search spams? hubs need to implement flood protection, whether this is caused by normal clients or malicious users. if hubs start kicking/banning users for spam, dc++ will be modified, I assure you.
Yes good hubs have flood protection, but there always is ugly implemetation of search for alternates in dc++  X(
Quoteah..? that means that clients should send _both_ clientid and myinfo on changng sharesize?? that smells like bandwidth wastage to me....
you're right here....
"Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris." - Larry Wall

ptaczek

Sed, you're right in important points.

1. let me excuse for my agressive begining, but it seems that slow discussions lead to nowhere.

2. the ClientID (or whatever we've called it) has been discussed on DC++ forum but was rejected with question: "What improvement to DC protocol is that?"


Today I had a short chat with Opera. We have sorted things this way:

a) Client must not send $ClientInfo (or $ClientID or $CNFO or anything else - no final form is invented, but rather short than long) until he get positive response to $Supports ClientInfo| from the hub.
Hub must not close connection for clients sending $Supports.

b) $ClientInfo should be sent right after $Key and before $ValidateNick in basic form
[size=2]$ClientInfo M:x,H:a/b/c,S:x[,L:x]|[/size]

Where order of segments can be variable but M,H and S must be included at the beginning.

c) In the middle of the DC session client sends partial $ClientInfo for updates of one or more values:

Ex.:
[size=2]$ClientInfo M:P|
$ClientInfo H:2/0/1,M:A|
$ClientInfo S:5,L:16384,M:5|[/size]
etc. Any combination is possible

d) the sharesize is updated by sending whole MyINFO :/

e) Version info is omited. Me and Opera agree that there should be no client identification, therefore no version info. Simply because every new client should have the same chance to fuze with DC network without silly banning of new clients just because they are new or because they are not DC++.
All information about client's features or extensions should be negotiated with hub via $Supports.

f) questions are:
1, do clients really need any of the M:H:S:L: information except of the M: ?
2, if( 1, == true) { How to inform other users about the mode?; }

Opera, PPK and me have nothing against to try the scheme above. More than words the real test is always better and we need to start somewhere. In other case the discussion may continue ad infinitum without any practical experimets ;)


That's the short version. There is no long version yet ;)
-ptaczek-

This whole physical universe is a hologram.
[Cosmosis - Contact: The First Step]

fusbar

this version sounds better than the first. ,))

And yes an experiment would be interesting, so why not combine this idea with QuickList? which still hasn't been taken into use by some clients/hubs. ,))

OpiumVolage

I really like this method:
Using $Supports for extentions.
And effective sending of changes on $ClientInfo.

Keep up the good work.

[NL]Pur

Quotee) Version info is omited. Me and Opera agree that there should be no client identification, therefore no version info. Simply because every new client should have the same chance to fuze with DC network without silly banning of new clients just because they are new or because they are not DC++.
All information about client's features or extensions should be negotiated with hub via $Supports.

My suggestion is that a more raw version could be handy. Like a info if it is a Moglo, Hubpinger or Client.

PPK

QuoteOriginally posted by fusbar
And yes an experiment would be interesting, so why not combine this idea with QuickList? which still hasn't been taken into use by some clients/hubs. ,))
I like experiments, but i don't find any Quicklist enabled client or hub :( CZDC++ maybe supports QuickList but i don't find hub where i test it X(
"Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris." - Larry Wall

GargoyleMT

QuoteOriginally posted by PPK
I like experiments, but i don't find any Quicklist enabled client or hub :( CZDC++ maybe supports QuickList but i don't find hub where i test it X(

I was thinking that since you mentioned the bandwidth problem specifically in relation to CZPRO, you could work with Verliba (since you control the .cz client and hub implementations) to produce a version that does support the feature you want... and then give hard data so the rest of the community might change over.

Sidenote, I did I miss the portion where we don't break compatibility with NMDCH?  :(

PPK

Quoteyou could work with Verliba (since you control the .cz client and hub implementations)
Verliba is very busy and have more another work in todo X(
And PtokaX is .cz too :]
QuoteSidenote, I did I miss the portion where we don't break compatibility with NMDCH?
QuicList enabled by $Supports not break NMDCH compatibility or is here any "compatibility break" what i don't see ? :D
"Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris." - Larry Wall

Sedulus

#19
QuoteOriginally posted by ptaczek
a) Client must not send $ClientInfo (or $ClientID or $CNFO or anything else - no final form is invented, but rather short than long) until he get positive response to $Supports ClientInfo| from the hub.
Hub must not close connection for clients sending $Supports.
good, perfectly acceptable. and a good incentive to add $Supports to clients and hubs.
unfortunately there is no agreed Supports standard out there. (this should be discussed in a separate thread)


Quoteb) $ClientInfo should be sent right after $Key and before $ValidateNick in basic form
[size=2]$ClientInfo M:x,H:a/b/c,S:x[,L:x]|[/size]
Where order of segments can be variable but M,H and S must be included at the beginning.
someone mentioned that it's perhaps better to send it after $ValidateNick (or $MyPass in the case of registered users), so that the hub can decide which userlevels need what kind of hub/slot ratio's (etc..)


Quotec) In the middle of the DC session client sends partial $ClientInfo for updates of one or more values:

Ex.:
[size=2]$ClientInfo M:P|
$ClientInfo H:2/0/1,M:A|
$ClientInfo S:5,L:16384,M:5|[/size]
etc. Any combination is possible
excellent


Quoted) the sharesize is updated by sending whole MyINFO :/
now we are still using the an old fossil, not the ++-tag, but the MyINFO... read onwards.


Quotee) Version info is omited. Me and Opera agree that there should be no client identification, therefore no version info. Simply because every new client should have the same chance to fuze with DC network without silly banning of new clients just because they are new or because they are not DC++.
All information about client's features or extensions should be negotiated with hub via $Supports.
yes, I say that this is the way to go. features/behaviour are important, not names or versions.

however, the client should be _allowed_ to send version somewhere (this could be a stripped ++-tag.. again read onwards), I say that there are circumstances in which kicking specific versions of clients is useful (the 80kB/s bug in dc++024x)


Quotef) questions are:
1, do clients really need any of the M:H:S:L: information except of the M: ?
2, if( 1, == true) { How to inform other users about the mode?; }
yes, I think hubowners should be able to specify who should get which information.
the practical, and somewhat protocol compliant way, would be to add %[mynick] as the first argument, like:
$ClientInfo Sedulus H:0/1/1,S:3,M:A
this is only downstream, so the extra bandwidth shouldn't be a problem. and this can be forwarded with only the 'useful' arguments to only those who need it.


now, if we are going to use Supports, we have the option to go all out, and break backwards compatibility in the protocol (however, one will need compatibility in the hubs and clients for the time being.. at least for a couple of versions (or.. that would be nice to users))

I'd suggest to drop the MyINFO, drop the ValidateNick, and use only ClientInfo for the information contained in them.
- Supports decides whether the user logs on as usual or in the new way.
- the first ClientInfo would be the ValidateNick and also contain the above mentioned info (as well as for instance B:xxx for share size, and C:xxx for connection type (if needed..), D:xxx for description (that's where the optional Version could be put) and E:xxx for email (if needed..))
- this would be replied to by a Hello %[yournick] or something (optionally add forced-change-nick.. I know fusbar would like that - that is, the %[yournick] may be modified by the hub, and the client should assume this new nick) or a GetPass if the user is registered.
- now, when the user is accepted, the hub 'knows' which users Support ClientInfo and can send that info on to them. it can construct an old MyINFO to the non-supporting users.

it has been a while since I would support/suggest such a large change. I know that this creates a (quite) bit more work at first. and but it would be better in the long run to get rid of other fossils if you're doing modifications anyway.
(the suggested command order/syntax may need some tweaking)
(oh, and this should be intertwined with the advantages of quicklist, i.e. drop the GetINFO/Hello/MyINFO and send only ClientInfo's and OpList as reply to GetNickList)


in any case.. the first step is to get the Supports up and running.


p.s. if you're going to be bandwidth cheap, I have no problems at all with using $CI for $ClientInfo

[ES]latinmusic

QuoteOriginally posted by Sedulus
(this should be discussed in a separate thread)
Yes if public, i'm going to comunicated this link thread to more clients developers out here at least for them take a look on it. If they post or not dunno, but they have to know it for support in the future.

PPK

Quotegood incentive to add $Supports to clients and hubs. unfortunately there is no agreed Supports standard out there. (this should be discussed in a separate thread)
Maybe is too late to discuss on Supports standart, because yhub, verlihub and CZDC++ already suports arnetheduck $Supports :D

[2003-10-14 19:00:25] *** Connected
[2003-10-14 19:00:25] $Lock EXTENDEDPROTOCOL:SPEEDSHAKE_This_hub_was_written_by_Yoshi_ Pk=None
[2003-10-14 19:00:25] $HubName YHub TestCore
[2003-10-14 19:00:25] <-YHub-> YHub version: Beta 0.383 written by Yoshi.
[2003-10-14 19:00:25] $Supports UserIP BotINFO MCTo

[2003-10-16 18:40:24] *** Connected
[2003-10-16 18:40:25] $Lock EXTENDEDPROTOCOL_verlihub Pk=version0.9.3
[2003-10-16 18:40:25] This Hub is running version 0.9.4 alpha of VerliHub (RunTime:0days 5h 55min).
[2003-10-16 18:40:25] This Hub is running version 0.9.4 alpha of VerliHub (RunTime:0days 5h 55min).
[2003-10-16 18:40:31] $Supports OpPlus

Quotesomeone mentioned that it's perhaps better to send it after $ValidateNick (or $MyPass in the case of registered users)
For future is maybe better if it send before $ValidateNick .... QuickList don't have this command.
"Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris." - Larry Wall

ptaczek

QuoteOriginally posted by Sedulus
someone mentioned that it's perhaps better to send it after $ValidateNick (or $MyPass in the case of registered users), so that the hub can decide which userlevels need what kind of hub/slot ratio's (etc..)
In my opinion it's better before the $ValidateNick (and $MyPass). In case of general hub without any per_user access rights, the only information the hub needs for accept/reject client are those values from $CI. So the connection can be closed before any further authorization - bandwidth again ;)
For hubs with per_user access rights it's then easy as hub must store those $CI values for each client.
So first low-level data, then higher-leve authorization with profiles or whatever ;)

Quote
Quote...All information about client's features or extensions should be negotiated with hub via $Supports.
yes, I say that this is the way to go. features/behaviour are important, not names or versions.
however, the client should be _allowed_ to send version somewhere (this could be a stripped ++-tag.. again read onwards), I say that there are circumstances in which kicking specific versions of clients is useful (the 80kB/s bug in dc++024x)
Well, I agree. As it seems, assembling of complete list of possible segments in the $CI is necessary. Lets start with such simple task. The very basic is clean:

alphabetically:

B: share size
C: conn.type
D: description
E: e-mail
H: hubs *
L: upload limit
M: mode *
S: slots *
V: version

* required for handshake

Append/modify the list according to your idea/opinion, please

Quoteyes, I think hubowners should be able to specify who should get which information.
the practical, and somewhat protocol compliant way, would be to add %[mynick] as the first argument, like:
[size=2]$ClientInfo Sedulus H:0/1/1,S:3,M:A[/size]
this is only downstream, so the extra bandwidth shouldn't be a problem. and this can be forwarded with only the 'useful' arguments to only those who need it.
Sweet. It perfectly fits to the protocol changes you have mentioned about dropping $ValidateNick and $MyINFO out from the protocol! I like the idea very much.
-ptaczek-

This whole physical universe is a hologram.
[Cosmosis - Contact: The First Step]

PPK

QuoteWell, I agree. As it seems, assembling of complete list of possible segments in the $CI is necessary. Lets start with such simple task. The very basic is clean:
Append/modify the list according to your idea/opinion, please
I want F: flag
Last byte from connection in $MyINFO used to specify away/server/fireball status :D I want to see away and fast users :]
"Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris." - Larry Wall

ptaczek

QuoteOriginally posted by PPK
I want F: flag
Last byte from connection in $MyINFO used to specify away/server/fireball status :D I want to see away and fast users :]
Wy not just include the flag into the M: mode?

Format:

M:xy
x - Mode: A,P,5 (single character)
y - Status: 0-A (single hexa character)

     01 = normal
     02 = away
     03 = fileserver
     04 = fileserver away
     05 = speeduser
     06 = speeduser away

The thing I don't know is when user gets the 'fileserver' or 'speeduser' status
-ptaczek-

This whole physical universe is a hologram.
[Cosmosis - Contact: The First Step]

SMF spam blocked by CleanTalk