Also take a look at Network Address, it's other common one that varies by version and is embedded in version message.
http://code.google.com/p/bitcoinj/source/browse/trunk/src/com/google/bitcoin/core/PeerAddress.java
Topic: Bitcoin messages implementation (Read 1245 times)
Thanks for the help.
Can someone double check this message for correctness:
010000000000000000000000000000000000FFFFFFFFFF008D20 - 255.255.255.0:8333
010000000000000000000000000000000000FFFF7F0000018D20 - 127.0.0.1:8333
010000000000000000000000000000000000FFFFFFFFFF008D20 - 255.255.255.0:8333
010000000000000000000000000000000000FFFF7F0000018D20 - 127.0.0.1:8333
I didn't check everything but I noticed that your port is not in big-endian. It should be 208D
I also agree that protocol version and client version should be separate, and both should be present. For example, the main client could identify itself as "Main Client version 5.1 protocol version 2.5", and someone else's implementation could be still compatible, but distinguish itself as "Billy's Client version 0.3 protocol version 2.5".
subVer was intended to be used for releases like 0.3.19.3.1, but this is unlikely nowadays. The purpose of this field might change to something else later -- maybe it will identify user agents.
A user agent field would be glorious. I found myself changing the protocol version number from something like 32400 to 32407 just to differentiate my experimental program from normal nodes.
A user agent field would also optionally let us go back to actually using the protocol version number as a protocol version number rather than a client version number.
EDIT: Although I'm seeing that that client version number is pretty solidly coded into things like alerting. hmm..
Some day different clients will have to relay each others' alerts and that will be a little hairy.
Can someone double check this message for correctness:
F9BEB4D976657273696F6E00000000005500000086234FCA409C00000100000000000000A135864 E00000000010000000000000000000000000000000000FFFFFFFFFF008D20010000000000000000 000000000000000000FFFF7F0000018D20549774EE243F8BFC0001000000
F9BEB4D9 - magic
76657273696F6E0000000000 - command version
55000000 - length
86234FCA - checksum
409C0000 - version 4.0
0100000000000000 - services
A135864E00000000 - time
010000000000000000000000000000000000FFFFFFFFFF008D20 - 255.255.255.0:8333
010000000000000000000000000000000000FFFF7F0000018D20 - 127.0.0.1:8333
549774EE243F8BFC - random nonce
00 - sub version number
01000000 - start height (1)
F9BEB4D976657273696F6E00000000005500000086234FCA409C00000100000000000000A135864 E00000000010000000000000000000000000000000000FFFFFFFFFF008D20010000000000000000 000000000000000000FFFF7F0000018D20549774EE243F8BFC0001000000
F9BEB4D9 - magic
76657273696F6E0000000000 - command version
55000000 - length
86234FCA - checksum
409C0000 - version 4.0
0100000000000000 - services
A135864E00000000 - time
010000000000000000000000000000000000FFFFFFFFFF008D20 - 255.255.255.0:8333
010000000000000000000000000000000000FFFF7F0000018D20 - 127.0.0.1:8333
549774EE243F8BFC - random nonce
00 - sub version number
01000000 - start height (1)
Most messages have separate version numbers, but for version messages the version is indeed the client version. 0.3.19.3 is 31903. 0.4 (the latest stable version) is 40000.
Services can be 0.
subVer was intended to be used for releases like 0.3.19.3.1, but this is unlikely nowadays. The purpose of this field might change to something else later -- maybe it will identify user agents.
You didn't update the message header length/checksum.
Services can be 0.
subVer was intended to be used for releases like 0.3.19.3.1, but this is unlikely nowadays. The purpose of this field might change to something else later -- maybe it will identify user agents.
But when I changed a single bit in the IP address of the addr message, Bitcoin complained to the debug log that the message length was incorrect.
You didn't update the message header length/checksum.
I had trouble trying the same thing. When I connected to my local bitcoin client, when exchanging simple getaddr and addr messages, Bitcoin spat out errors in the debug log and I could never figure out why. The error messages it printed were definitely not accurate; for example I could get it to accept an addr message if I copied and repeated the exact addr message I received. But when I changed a single bit in the IP address of the addr message, Bitcoin complained to the debug log that the message length was incorrect.
I could never get it to respond to getdata messages
EDIT: I went and ran this part of the program again and it worked just fine. Since I last ran it, I fixed the way I handle TCP streams. I must have fixed it. It was my own fault.
I`m working on implementing different Bitcoin messages. Currently workin on "version" message (https://en.bitcoin.it/wiki/Protocol_specification#version) and I have a couple simple questions:
What is the current protocol version to use in the message? How do different protocol versions differ? From what I can see I assume they correlate to main blient release version, but I'd rather make sure.
Services part - it can be set to 1 if node has full blocks, but can it also be set to 0? (a bit of a trivial question, but there might be something I don't know)
What is the secondary version for (if anything at the moment)?
Any other advice or resources you can give for developing the communication between the Bitcoin clients? For now I`m following the wiki on Protocol Specification and Network pages, but they are a bit hard to read at times.
What is the current protocol version to use in the message? How do different protocol versions differ? From what I can see I assume they correlate to main blient release version, but I'd rather make sure.
Services part - it can be set to 1 if node has full blocks, but can it also be set to 0? (a bit of a trivial question, but there might be something I don't know)
What is the secondary version for (if anything at the moment)?
Any other advice or resources you can give for developing the communication between the Bitcoin clients? For now I`m following the wiki on Protocol Specification and Network pages, but they are a bit hard to read at times.
Jump to: