Difference between revisions of "Protocol specification v3"

From Bitmessage Wiki
Jump to navigation Jump to search
(introduction)
(version)
Line 3: Line 3:
 
{{Template:Proposal}}
 
{{Template:Proposal}}
  
=== Introduction ===
+
== 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  [https://bitmessage.org/wiki/Protocol_specification this] as a reference for all formates which are not mentioned in this description.
 
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  [https://bitmessage.org/wiki/Protocol_specification 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 [https://bitmessage.org/wiki/Protocol_specification#version here]
 +
 +
Payload:
 +
 +
{|class="wikitable"
 +
! Field Size !! Description !! Data type !! Comments
 +
|-
 +
| 4 || version || int32_t || Identifies protocol version being used by the node
 +
|-
 +
| 8 || services || uint64_t || bitfield of features to be enabled for this connection
 +
|-
 +
| 8 || timestamp || int64_t || standard UNIX timestamp in seconds
 +
|-
 +
| 26 || addr_recv || net_addr || The network address of the node receiving this message (not including the time or stream number)
 +
|-
 +
| 26 || addr_from || net_addr || The network address of the node emitting this message (not including the time or stream number and the ip itself is ignored by the receiver)
 +
|-
 +
| 8 || nonce || uint64_t || Random nonce used to detect connections to self.
 +
|-
 +
| 1+ || user_agent || [[#Variable length string|var_str]] || [[User Agent]] (0x00 if string is 0 bytes long)
 +
|-
 +
| 1+ || stream numbers || [[#Variable length list of integers|var_int_list]] || The stream numbers that the emitting node is interested in.
 +
|}
 +
 +
A "verack" packet shall be sent if the version packet was accepted. Once you have sent and received a verack messages with the remote node, send an addr message advertising up to 1000 peers of which you are aware, and one or more inv messages advertising all of the valid objects of which you are aware.
 +
 +
The following services are currently assigned:
 +
 +
{|class="wikitable"
 +
! Value !! Name !! Description
 +
|-
 +
| 1 || NODE_NETWORK || This is a normal network node.
 +
|}
 +
 +
=== verack ===
 +
 +
The ''verack'' message is sent in reply to ''version''.  This message consists of only a [[#Message structure|message header]] with the command string "verack". The TCP timeout starts out at 20 seconds; after verack messages are exchanged, the timeout is raised to 10 minutes.
 +
 +
=== addr ===
 +
 +
Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours
 +
 +
Payload:
 +
{|class="wikitable"
 +
! Field Size !! Description !! Data type !! Comments
 +
|-
 +
| 1+ || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of address entries (max: 1000)
 +
|-
 +
| 34x? || addr_list || [[Protocol_specification#Network_address|net_addr]] || Address of other nodes on the network.
 +
|}
 +
 +
=== inv ===
 +
 +
Allows a node to advertise its knowledge of one or more objects.
 +
Payload (maximum payload length: 50000 items):
 +
 +
{|class="wikitable"
 +
! Field Size !! Description !! Data type !! Comments
 +
|-
 +
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries
 +
|-
 +
| 32x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
 +
|}
 +
 +
=== getdata ===
 +
 +
getdata is used in response to an ''inv'' message to retrieve the content of a specific object after filtering known elements.
 +
 +
Payload (maximum payload length: 50000 entries):
 +
 +
{|class="wikitable"
 +
! Field Size !! Description !! Data type !! Comments
 +
|-
 +
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries
 +
|-
 +
| 32x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
 +
|}

Revision as of 06:15, 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

Payload:

Field Size Description Data type Comments
4 version int32_t Identifies protocol version being used by the node
8 services uint64_t bitfield of features to be enabled for this connection
8 timestamp int64_t standard UNIX timestamp in seconds
26 addr_recv net_addr The network address of the node receiving this message (not including the time or stream number)
26 addr_from net_addr The network address of the node emitting this message (not including the time or stream number and the ip itself is ignored by the receiver)
8 nonce uint64_t Random nonce used to detect connections to self.
1+ user_agent var_str User Agent (0x00 if string is 0 bytes long)
1+ stream numbers var_int_list The stream numbers that the emitting node is interested in.

A "verack" packet shall be sent if the version packet was accepted. Once you have sent and received a verack messages with the remote node, send an addr message advertising up to 1000 peers of which you are aware, and one or more inv messages advertising all of the valid objects of which you are aware.

The following services are currently assigned:

Value Name Description
1 NODE_NETWORK This is a normal network node.

verack

The verack message is sent in reply to version. This message consists of only a message header with the command string "verack". The TCP timeout starts out at 20 seconds; after verack messages are exchanged, the timeout is raised to 10 minutes.

addr

Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours

Payload:

Field Size Description Data type Comments
1+ count var_int Number of address entries (max: 1000)
34x? addr_list net_addr Address of other nodes on the network.

inv

Allows a node to advertise its knowledge of one or more objects. Payload (maximum payload length: 50000 items):

Field Size Description Data type Comments
? count var_int Number of inventory entries
32x? inventory inv_vect[] Inventory vectors

getdata

getdata is used in response to an inv message to retrieve the content of a specific object after filtering known elements.

Payload (maximum payload length: 50000 entries):

Field Size Description Data type Comments
? count var_int Number of inventory entries
32x? inventory inv_vect[] Inventory vectors