Refactoring ADC and Versioning support

[darkKlor]

The ideas in this document came from a couple discussions I had with Dj_Offset and Pretorian. This is not to say they're in full support, but they influenced my thoughts The combined changes here would be major, so would likely form the basis of an ADC/2.0.

Basically there's two core ideas:
1) The BASE protocol is too big. Not all types of clients need or want all of it. A client on a mobile phone probably won't want file transfers or searching. Some bots could get along quite happily without chat support e.g. one that just scan's the file list of other users.
2) Versioning is not rich enough at present. The actual version of the protocol is only given in GET/SND, not SUP. Also, feature names will change over time because the last character is a version number, so I propose a TIGR/1.0 style of feature naming. I think I forgot to detail it in the PDF, but there's a condendsed form for listing multiple feature versions: <feature1-name>/<version1>|<version2>|...|<versionN> <feature2-name/<version>

[arnetheduck]

1) Indeed - but perhaps it would be possible to solve it withing the 1.0 framework - I don't remember the details right now but an appropriate error message or something...worth examining at least

2) We discussed this during the 1.0 process, and I somewhat regret that we did the connect string as it is (there was some thinking of making it look a little like the http string to possibly replace it with a http (or other) conversation instead, interesting but hasn't happened until now at least) - it would be more consistent to make it a fourcc too. Honestly - how many versions of a feature do you need / want / do? http is at 1.1 after x years which afaict is incompatible with 1.0 (since there's a manual option to choose 1.0 compatibility mode in many apps), so they might as well have named it 2.0...doing point releases for protocols doesn't seem to make very much sense as you'd need to have very clear rules that define what's allowed in a point and what causes a major number increase...intuitively, the rules would be something like "point release: extra features with backward compatibility, major release: same feature, but incompatibly extended / improved". The first case is covered by simply adding a new fourcc (we have lots of fourcc's and the day we run out, it's time to design a new protocol) while the second is best addressed with the method described in the spec...

That said, the editing of your proposal is much better than the current spec - that alone would be a nice contribution =)

[darkKlor]

1) My problem with sending error messages (STAs) is that afeatures are opt-out so: a) there must be pointless lines of code just to say 'we know these features are in the protocol, but we don't support them' and, b) clients and hubs need to respect the error messages e.g. a recent version of DC++ (maybe even the current version) didn't respect an error message from my bot when a user tried to connect to it, it just kept trying to connect, despite the protocol indicating that I was sending the appropriate error message.

The issue of respect is crucial in low-bandwidth situations e.g. mobile devices, where bandwidth is expensive. If protocol features are opt-in then these devices are much better catered for.

A limitation to this approach may arise in the case of 10k user hubs, where filtering messages based on supported features may take too much time where the hub filters by iterating all users and examining their feature support. The obvious enhancement to this is, when the hub is in a high-volume situation, create lists per-feature containing the users which support them, and then iterate through the list for that feature. This increases memory usage, but should reduce processor load.

2) Yes we have 33,696 fourcc's (26*36*36), but the readability and relevance to functionality will increase if we actually use them as fourcc's + version number, rather than integrating the version number (useless benefit, we'd have 1.2 million fourcc's). For example, what will ADCS be at version 2? ADC2 by convention, so you just lost the key descriptive word in the feature name because you needed to put the version number there, and now it looks like it could be confused with the core protocol by an observer who isn't paying attention. Alos, the ZLIB feature has ZLIF and ZLIG as the two 'supports' fourcc's, but how do you create a new version of them? In both cases it will be ZLI2, so you need a new first three characters for one of them, at least.

The expansive versioning is designed to let ADC live forever One possible use of major/minor versioning that I did mention was that you could use that x.0 version for core functionality, and x.1 for optional functionality, and then just keep the same pattern as you increase the version number in regards to odd/even. This could be useful for clients rapidly adding support for the core of a new feature, and then taking a bit more time to work through the more challenging/time-consuming elements. For example, in the MSTR extension I proposed (and still need to produce a revised draft because it's too complex), the BAN command has an option for the parameters to be treated as regular expressions if you pass the flag RX. MSTR/1.0 could include the simpler version of BAN, and MSTR/1.1 could add regular expression support to BAN.

[Pretorian]

What about adding an unlimited VE field that would specify which version of features are being used? I.e.,

HSUP ADBASE ADTIGR VEADC/1.0 VETIGR/1.2

etc. If no VE is specified, imply version 1.0 of ALL features. VE for ADC 1.0 may be omitted. Multiple versions of the same feature may be specified.

[darkKlor]

Pretty much does what I was after on versioning. There will be some duplication in the names I guess, but at least it's backwards compatible.

One thing this doesn't allow is to easily fall back to an older version of a spec... you have to remove the entire feature still.

I did also have some comments in the attached PDF about the ADC version. I wanted to specify the ADC version at the start of the SUP, as a positional parameter, because it isn't a FOURCC.This may not be back-compat though, and I have misgivings about the use of positional parameters in general.. I think they should be ditched.

[Pretorian]

Discussing further with drakKlor, we suggest the following as an addendum to what I had written above;

Code: Select all

Flag FV in INF should signal which versions the features in SU have. 

[Quicksilver]

What hinders us to specify some feature called FILTER may be FILT as fourcc that can be used to give the hub some sort of filter on what BASE messages are supported? i.e. what base messages should not be forwarded..

What do you want to filter out? INF messages possibly? though this would fobird showing nicks in main for chatmessages...
SCH could be filtered out very well if the hub supported bloom / or is intelligent enough to send no searches to people without share. (Which Ynhub in NMDC already did)

CTM / RCM ... clients should not really connect to people without share don't see this as much of a problem.


alas my Point is it seems you are trying to solve a non issue with this feature versioning. I would prefer to wait with such a VE2.0 like with NMDC EXTENDEDPROTOCOL as long as possible before doing it...

I also don't see much code needed... unsupported commands then could just cause a standard STA message ... not much more to do than ignoring unknown commands... this is 10 lines of code extra... if thats too much you mobile phone can't run DC anyway.

So my recommendation: don't change the protocol for a few years where mobile phones computation power and cost for the line are relevant. We need simplicity! And ADC should target shareing files! I know for most of the people here over the years the chatting ahs become more important though there still are people out there that really are not interested in users not shareing... this protocol is done for filesharing.. don't forget that.


hmm and on the HTTP stuff arne mentioned.. never understood why files were not transferred via http ... which would spare us at least the client-client protocol as it is ... (and no I would not want to change the state as it is...)

[Pretorian]

Well, AW in the INF is used to filter out some MSG messages. AW or some other flag (preferably) could be used instead to filter out different types of messages.

[pR0Ps]

So what's the general opinion on this ADC 2.0 proposal? Is it going anywhere?