|
Title: Using the subVer field as a user-agent equivalent Post by: Mike Hearn on March 16, 2011, 10:16:51 AM This is just a heads up that yesterday I checked code into BitCoinJ that sets the subVer in its version message to "BitCoinJ 0.1.99".
The subVer field is a string field in the version message. The official client just sets it to the empty string, and it's only used as a filter on the (never used so far) broadcast alerts. For people who are implementing the BitCoin protocol, let's use this field as an HTTP User-Agent equivalent. Title: Re: Using the subVer field as a user-agent equivalent Post by: theymos on March 16, 2011, 03:34:02 PM Sounds good. Can you give an example hex dump of such a message so I know what the byte ordering looks like? Is it the same as the command?
Title: Re: Using the subVer field as a user-agent equivalent Post by: Mike Hearn on March 16, 2011, 05:07:22 PM It's UTF-8 encoded first character first.
It's not the same as the command string. That is a NULL or length terminated character array. This is regular string encoding, so varint + characters. Title: Re: Using the subVer field as a user-agent equivalent Post by: jgarzik on March 16, 2011, 06:01:07 PM The subVer field is a string field in the version message. The official client just sets it to the empty string, and it's only used as a filter on the (never used so far) broadcast alerts. This is incorrect. The client has used this in the past. To get the history behind a single line of code, use "git blame $file" You can see the official client made full use of this field in a790fa46f40d751307f86c37a709eb119768ce5b, and presumably older clients exist that use this field. Title: Re: Using the subVer field as a user-agent equivalent Post by: Mike Hearn on March 16, 2011, 06:27:47 PM I see that it was set to ".8" but that only seemed to be used in printing out the version number. I didn't see uses of it elsewhere, did I miss one?
Title: Re: Using the subVer field as a user-agent equivalent Post by: jgarzik on March 16, 2011, 06:37:24 PM I see that it was set to ".8" but that only seemed to be used in printing out the version number. I didn't see uses of it elsewhere, did I miss one? That's the purpose of the field. Whenever we have a four-dotted release 0.3.20.1, we set pszSubVer. It is part of the overall program version. It is separate AFAICT because satoshi needed an extra field, and the dotted-triple 0.3.20 is already part of a fixed encoding scheme that sets converts X.Y.Z to a single integer number. Presumably you're aware of the network protocol :) so presumably you can see how it is not feasible to add a fourth qualifier to the encoded version. So, I disagree with your change, it stomps on a field bitcoin has used in the past six months. We can change this if/when the client version becomes separate from the protocol version. cdecker proposed this in https://github.com/bitcoin/bitcoin/pull/63 His implementation was not desirable, but I think the genesis of the idea was sound. Title: Re: Using the subVer field as a user-agent equivalent Post by: Mike Hearn on March 17, 2011, 08:22:39 AM Honestly, I think 3 version numbers is quite enough. There's nothing morally wrong with having the first number be higher than zero :-)
Regardless of how it was used in the past six months, the way it's used now is as an arbitrary string that acts as a filter on broadcast messages. That's a useful thing to have. If we did introduce a separate user-agent field, it'd be exactly the same as subVer, which would be odd. Also, the previous usage of subVer was only used internally. The one sent by a peer has never been used, as far as I can tell, because there's never been an alert broadcast. |