[ADC-Ext 1.0.7] INF field for detecting Hub/Client versions

I just wanted to post this here, Pretorian had an idea earlier that was in discussion as a way for Hub/Clients to give their Client Name (i.e DC++) and version number through an INF field … discussion ensues…

On a completely different note, which I thought of a couple of days ago (i.e., not related to this), I was thinking of a new INF field, to separate client/hub software and the version.

So, you’d send “APDC++ VE0.7.6.2” (‘AP’ for ‘Application’)

I think this would be a nice way to able to maintain statistics on clients and version numbers (which can be proven to be useful)

In general I say go for it. Cost is 2 bytes per INF.

I’m not sure if people think you’d get further benefit from adding major/minor versioning?
e.g APDC++ VJ0.7.6 VN2 (VJ = Version maJor, VN = Version miNor)
APDC++ VJ0.7 VN6.2

I don’t know how useful this extra step would be… breaking up the version number into something meaningful is probably going to come down to convention again e.g. clients that go for a 1.x, 2.x naming versus 0.1.x, 0.2.x.

But the original proposal is great :smiley:


the wikipedia article is great for this proposal

Implementations should probably not rely on that VE contains only “” (or similar), since there need to be some compatibility between those who support ‘AP’ and those that do not. If a client doesn’t broadcast ‘AP’, then the hub could generate a VE field that contains both AP and VE fields. Not pretty but will provide some better compatibility.

Used by ADCH++ and DC++ (or at least the coming versions), so I’m pushing this to the next ADC-Ext.

Iam a bit against adding more verbosity to the protocol just for something nobody uses… and otherwise anyone can already parse out without problems.

DC in general already adds a lot of extra info liike an Email field which has no value at all for the protocol.

I just want to caution to be not to reluctant in adding junkdata to the protocol.

This is in ADC-Ext 1.0.7, closing.