Difference between revisions of "Protocol specification v3"

From Bitmessage Wiki
Jump to navigation Jump to search
Line 39: Line 39:
 
! Field Size !! Description !! Data type !! Comments
 
! Field Size !! Description !! Data type !! Comments
 
|-
 
|-
| 8||POW nonce||uint64_t||Random nonce used for the [[Proof of work|Proof Of Work]]
+
| 8||POW nonce||uint64_t||
 +
Random nonce used for the [[Proof of work|Proof Of Work]]
 
|-
 
|-
| 8||time||uint32_t||The "end of life" time of this object. Objects shall be broadcast until its end of life time has been reached. The node shall store the inventory vector of that object for at least anouther hour to avoid reloading it from another node with a small time delay.
+
| 8||time||uint32_t||
 +
The "end of life" time of this object (be aware, in version 2 of the protocol this was the generation time). Objects shall be broadcast until its end of life time has been reached. The node shall store the inventory vector of that object for at least anouther hour to avoid reloading it from another node with a small time delay.
 +
The maximum value for the end of life time is 28 days in the future.
 
|-
 
|-
| 4||object type||uint32_t||this field specifies the content of the object.
+
| 4||object type||uint32_t||
 +
This field specifies the content of the object.
 
Valid values are (at the moment) 0-"getpubkey", 1-"pubkey", 2-"msg", 3-"broadcast". all other values are reserved. Nodes shall transport objects with unknown types, too. This will make further protocol changes more easy.
 
Valid values are (at the moment) 0-"getpubkey", 1-"pubkey", 2-"msg", 3-"broadcast". all other values are reserved. Nodes shall transport objects with unknown types, too. This will make further protocol changes more easy.
 
|-
 
|-
 
|-
 
|-
| ?||payload||uchar[]||this field varies depending on the object type. For a detailed description of thair content look [https://bitmessage.org/wiki/Protocol_specification#Object_types here]
+
| ?||payload||uchar[]||
 +
This field varies depending on the object type. For a detailed description of thair content look [https://bitmessage.org/wiki/Protocol_specification#Object_types here]
 
|-
 
|-
 
|}
 
|}

Revision as of 06:48, 5 July 2014

Introduction

This is a DRAFT for the protocol version 3. It describes the changes in protocol version 3 versus version 2. Things which are unchanged from version 2 are not described in detail. So you should use this as a reference for all formates which are not mentioned in this description.

Message types

Most message types are unchanged from version 2 to version 3. Only the four "objecttype" messages are not valid any more. They are summerized into one single message.

version

The version message is identically to protocol version 2. you can lookup details here

verack

The verack message is identically to protocol version 2. you can lookup details here

addr

The addr message is identically to protocol version 2. you can lookup details here

inv

The inv message is identically to protocol version 2. you can lookup details here

getdata

The getdata message is identically to protocol version 2. you can lookup details here

Object type

The four former object types "getpubkey", "pubkey", "msg" and "broadcast" are summarizes into a single Message type "object". The four Messages as they did exist in version 2 protocol are not valid any more.

Objects are shared throughout a stream. A client should advertise objects until thair end of life time is reached. To be a valid object, the Proof Of Work has to be done.

Field Size Description Data type Comments
8 POW nonce uint64_t

Random nonce used for the Proof Of Work

8 time uint32_t

The "end of life" time of this object (be aware, in version 2 of the protocol this was the generation time). Objects shall be broadcast until its end of life time has been reached. The node shall store the inventory vector of that object for at least anouther hour to avoid reloading it from another node with a small time delay. The maximum value for the end of life time is 28 days in the future.

4 object type uint32_t

This field specifies the content of the object. Valid values are (at the moment) 0-"getpubkey", 1-"pubkey", 2-"msg", 3-"broadcast". all other values are reserved. Nodes shall transport objects with unknown types, too. This will make further protocol changes more easy.

? payload uchar[]

This field varies depending on the object type. For a detailed description of thair content look here