ADC - BASE

[[NL]Pur]

According to 0.8 draft:

The feature name should use only upper case letters, and possible a number to signal a revised feature. A central register of known features should be kept, to avoid clashes. All ADC clients should support the BASE feature (unless a future revision takes its place), which is this protocol.

So why is DC++ sending : HSUP xxxx BAS0

and not HSUP xxxx BASE0

(xxxx = cid)

And should an client always send an CID?

It is up to the hub developer to decide whether to base hub registration on CID or nickname (during login, the client (usually) provides both), but the latter is probably more convenient for the users.

usually doens't sound very strict. I already know a client send
HSUP +BAS0 at login , without the Cid. That means that a Cid based hub only can decide from there that an user get disconnected.


Though i also think that

SUP <+|-><feature1>...<+|-><featureN>

<+|-> doesn't say <+|-|>
and therefor isn't optional and dc++ should also send an + or - which it doesn't

[arnetheduck]

yes, well, dc++ isn't finished yet =) it sends bas0 so that it won't confuse future hubs with its bad behaviour...the + is not optional, but for the sake of consistency, I'm considering making it ++ and -- instead...hm...

[Sedulus]

According to 0.8 draft:

The feature name should use only upper case letters, and possible a number to signal a revised feature. A central register of known features should be kept, to avoid clashes. All ADC clients should support the BASE feature (unless a future revision takes its place), which is this protocol.

So why is DC++ sending : HSUP xxxx BAS0

and not HSUP xxxx BASE0

(xxxx = cid)

BAS0 is to denote that it's not BASE yet, and it's four letters only to keep it short

And should an client always send an CID?

well yes,
but as far as I understand, the first HSUP is the exception.
if it ever gets decided that the current CID's are too short or whatever, a SUP can be used to specify that a different CID type should be used.

It is up to the hub developer to decide whether to base hub registration on CID or nickname (during login, the client (usually) provides both), but the latter is probably more convenient for the users.

usually doens't sound very strict. I already know a client send
HSUP +BAS0 at login , without the Cid. That means that a Cid based hub only can decide from there that an user get disconnected.

current implementations suggest that the first INF contains the CID and the NIckname, but the NI is optional (the hub decides if it's mandatory); hence the "usual".

Though i also think that

SUP <+|-><feature1>...<+|-><featureN>

<+|-> doesn't say <+|-|>
and therefor isn't optional and dc++ should also send an + or - which it doesn't

correct.. DC++ needs a + there

[[NL]Pur]

current implementations suggest that the first INF contains the CID and the NIckname, but the NI is optional (the hub decides if it's mandatory); hence the "usual".

so the CID in the first HSUP can be ignored, or not sent ?

if you support both with and without CID it really harder to parse,

since in HSUP +BAS0 , is on the place of the CID

[arnetheduck]

uhm, no, there's nothing that says that the first hsup should be without - which means that it has to be there...I don't see any particular reason for making an exception really...if we ever run out of the 64-bit space (which means that we have a collision between 2^64 items), there's something fundamentally wrong anyway...

[[NL]Pur]

the

CID or nickname (during login, the client (usually) provides both),

doesn't tell which isn't supplied

edit: btw CZDC++ 0.4033 has the HSUP +BAS0 behaviour (old version i see now could be cid wasn't implemented yet? )

[arnetheduck]

the cid is always supplied, nick may in some cases be omitted (for example hub pingers etc don't need it really...)
Technically, the first hsup is in no way supposed to be used for authentication, it's the first inf that does that, and a hub app can then mandate from the client to send an inf with nick if it uses nick+password....