Some people have been suggesting that protocol buffers might be larger than the custom written packet layout. I suspect that actually it would be *smaller* due to some of the clever encoding used in protocol buffers.
I agree that it could be smaller; not necessarily because of clever encoding, but because it would allow us to drop reserved bytes and the like.
That too, although the counter argument people always make to that is that we could do away with reserved bytes anyway. No matter how impractical that would be :/
To resolve this, I think a test is in order, I shall encode a wallet file/network packet using protocol buffers and compare the size the packets in the current scheme. However, I have no idea what's in a packet, what data is stored in a packet, and in what format?
That would be the hard part, of course. If you want to test with the version packet (not really ideal, since it's only sent once per connection), I've decoded that fully:
http://bitcointalk.org/index.php?topic=231.msg6250#msg6250I was hoping for a transaction packet or something, but I'll give it a go with that for now. I could also test with the wallet file if anyone has decoded that?
Addendum:
Ok, Working from this summary of the version packet layout:
version
* {0xf9,0xbe,0xb4,0xd9}
* "version" (0x00 padded)
* 4 byte message size
* 4 byte checksum
* 8 byte nLocalServices (always 1 if !fClient, no idea either what that means)
* 8 byte timestamp (remember to use network byte order)
* Remote address (the address this Node thinks he is):
o nServices - uint64 (8b), still cryptic, don't know the meaning yet
o pchReserved - (12b): some reserved space, apparently for later IPv6
o ip - uint (4b)
o port - unsigned short (2b)
* Local address (the address this Node sees you under):
o nServices - uint64 (8b), still cryptic, don't know the meaning yet
o pchReserved - (12b): some reserved space, apparently for later IPv6
o ip - uint (4b)
o port - unsigned short (2b)
* 8 byte nLocalHostNonce (needed for a handshake, if I'm not mistaken)
* A subversion string ".0" in my case
* nBestHeight - int (4b): appears to be the last block number
I created this protocol buffer definition:
message version
{
message AddressInfo
{
required unint64 nServices;
required fixed32 ip;
required uint32 port;
}
required uint32 magic = 2045; //0xf9 | 0xbe << 1 | 0xb4 << 2 | 0xd9 << 3
required uint32 version;
required int64 checksum;
required uint64 timestamp;
required uint64 nLocalServices;
required AddressInfo Remote; //the address this node thinks he is
required AddressInfo Local; //the address this node sees you under
required fixed64 nLocalHostNonce;
required string SubversionString;
required uint32 nBestHeight;
}
Does that look correct? The only changes I've made are that the indented things in the bullet point list are nested message types, and I've completely dropped the 12 bytes of reserved ipv6 space (since that can easily be added in later, which is the point of protocol buffers). I should point out that I probbaly haven't picked the best encoding types for all these fields, that depends upon the values they're likely to store, so in practice the packet will probably be a little smaller than my tests indicate
