`endpoint` type is defined above (See "Endpoint format").
`endpoint` type is defined above (See "Endpoint format").
The document is represented by an array of bytes containing (peer_card_size + 2) bytes.
The document is represented by an array of bytes containing (peer_card_size + 2) bytes.
...
@@ -355,10 +367,10 @@ for each connection attempt, the process is as follows:
...
@@ -355,10 +367,10 @@ for each connection attempt, the process is as follows:
### CONNECT message
### CONNECT message
| data name | size in bytes | data type |
| data name | size in bytes | data type |
|:-------------:|---------------|-----------|
|:-------------:|---------------|--------------|
| challenge | 32 | [u8; 32] |
| challenge | 32 | [u8; 32] |
| api_features | 2 | u16 |
| api_features | 2/+ | WS2PFeatures |
| flags_queries | 1 | u8 |
| flags_queries | 1/+ | WS2PFlags |
| peer_card | ? | Peer card |
| peer_card | ? | Peer card |
| chunk_id* | 4 | u32 |
| chunk_id* | 4 | u32 |
| chunk_hash* | 32 | [u8; 32] |
| chunk_hash* | 32 | [u8; 32] |
...
@@ -367,7 +379,7 @@ challenge := random hash generated by the sending node of the CONNECT message, t
...
@@ -367,7 +379,7 @@ challenge := random hash generated by the sending node of the CONNECT message, t
api_features := This is exactly the same type as the field of the same name in the endpoints. But private WS2P nodes do not declare endpoints, so they must be able to indicate in the CONNECT message which features they support. Public WS2P nodes also fill this field, so any changes in the configuration of a public node will be applied on the 1st new connection. (If this was not the case, we would have to wait for the update of the peer record).
api_features := This is exactly the same type as the field of the same name in the endpoints. But private WS2P nodes do not declare endpoints, so they must be able to indicate in the CONNECT message which features they support. Public WS2P nodes also fill this field, so any changes in the configuration of a public node will be applied on the 1st new connection. (If this was not the case, we would have to wait for the update of the peer record).
flags_queries := See "flags_queries interpretations" below.
flags_queries := See "WS2PFlags type definition" below.
peer_card := This field is optional, if it's not present it must be replaced by 2 bytes filled with zeros. Why two bytes ? Because the first field of any peer card, `peer_card_size`, is 2 bytes long.
peer_card := This field is optional, if it's not present it must be replaced by 2 bytes filled with zeros. Why two bytes ? Because the first field of any peer card, `peer_card_size`, is 2 bytes long.
...
@@ -376,13 +388,15 @@ _*Fiels `chunk_id` and `chunk_hash` are present only if flag `ASK_SYNC_CHUNK` is
...
@@ -376,13 +388,15 @@ _*Fiels `chunk_id` and `chunk_hash` are present only if flag `ASK_SYNC_CHUNK` is
chunk_id := Last block number of the chunk.
chunk_id := Last block number of the chunk.
chunk_hash := Last block hash of the chunk.
chunk_hash := Last block hash of the chunk.
#### flags_queries interpretations
#### WS2PFlags type definition
| bit | flag |
| bit | flag |
|:---------:|-----------------|
|:---------:|-----------------|
| 0000_0001 | SYNC |
| 0000_0001 | SYNC |
| 0000_0010 | ASK_SYNC_CHUNK |
| 0000_0010 | ASK_SYNC_CHUNK |
| 0000_0100 | RES_SYNC_CHUNK |
| 0000_0100 | RES_SYNC_CHUNK |
| ... | ... |
| 1000_0000 | EXTENDED |
SYNC := Boolean indicating whether the connection corresponds to a synchronization request or not. In case of a synchronization request, the connection will necessarily be accepted but temporary. Whereas in the normal case the connection may or may not be accepted according to classic ws2p rules, but it will be permanent.
SYNC := Boolean indicating whether the connection corresponds to a synchronization request or not. In case of a synchronization request, the connection will necessarily be accepted but temporary. Whereas in the normal case the connection may or may not be accepted according to classic ws2p rules, but it will be permanent.
...
@@ -390,6 +404,8 @@ ASK_SYNC_CHUNK := So that the synchronization is not too slow, the nodes to whic
...
@@ -390,6 +404,8 @@ ASK_SYNC_CHUNK := So that the synchronization is not too slow, the nodes to whic
RES_SYNC_CHUNK := A WS2P Public node that asks to synchronize sends its PeerCard to the network, which can then contact it spontaneously to send chunk, the node in synchronization will accept in priority this type of connections.
RES_SYNC_CHUNK := A WS2P Public node that asks to synchronize sends its PeerCard to the network, which can then contact it spontaneously to send chunk, the node in synchronization will accept in priority this type of connections.
EXTENDED := Indicates that the field contain one additional byte to store 8 more features.
### ACK message
### ACK message
| data name | size in bytes | data type |
| data name | size in bytes | data type |
...
@@ -402,18 +418,20 @@ challenge_sig := Signature of the challenge given by the other node.
...
@@ -402,18 +418,20 @@ challenge_sig := Signature of the challenge given by the other node.
LOW_FLOW_DEMAND := The sender node of this message indicates that it's behind a low speed connection and therefore care must be taken to transmit low volumes of data to it.
LOW_FLOW_DEMAND := The sender node of this message indicates that it's behind a low speed connection and therefore care must be taken to transmit low volumes of data to it.
...
@@ -422,6 +440,8 @@ MEMBER_PUBKEY: Indicates whether or not the member_pubkey field is present in th
...
@@ -422,6 +440,8 @@ MEMBER_PUBKEY: Indicates whether or not the member_pubkey field is present in th
MEMBER_PROOF := Indicates that the message contains proof that the sender node is a member. If this boolean is false, then the member_proof field must not be present.
MEMBER_PROOF := Indicates that the message contains proof that the sender node is a member. If this boolean is false, then the member_proof field must not be present.
If this boolean is true, the "member_proof" must contain a signature must sign the following datas :
If this boolean is true, the "member_proof" must contain a signature must sign the following datas :
EXTENDED := Indicates that the field contain one additional byte to store 8 more features.