@@ -568,20 +568,27 @@ In case of equality, the order in which the endpoints will be contacted will dep
...
@@ -568,20 +568,27 @@ In case of equality, the order in which the endpoints will be contacted will dep
After sorting all WS2P endpoints according to the criteria described in the previous section,
After sorting all WS2P endpoints according to the criteria described in the previous section,
Duniter tries to connect to the other nodes.
Duniter tries to connect to the other nodes.
for each connection attempt, the process is as follows for initiator :
**normal connection**
1. Opening a websocket pointing to the remote endpoint. If the websocket has been successfully opened before the timeout*, send a CONNECT message. Otherwise, log the error and close the websocket.
1. Opening a websocket pointing to the remote endpoint. If the websocket has been successfully opened before the timeout\*, send a CONNECT message. Otherwise, log the error and close the websocket.
2. Wait to receive a CONNECT message from the remote node, checking the validity. If the CONNECT message is valid, then sending an ACK message. Otherwise, log the error and close the websocket.
2. Wait to receive a CONNECT message from the remote node, checking the validity. If the CONNECT message is valid, then sending an ACK message. Otherwise, log the error and close the websocket.
3. Wait to receive an ACK message from the remote node, checking the validity. If the ACK message is valid, then sending a SECRET_FLAGS/OK message. Otherwise, log the error and close the websocket.
3. Wait to receive an ACK message from the remote node, checking the validity. If the ACK message is valid, then sending a SECRET_FLAGS/OK message. Otherwise, log the error and close the websocket.
4. Wait to receive a SECRET_FLAGS/OK message from the remote node, checking the validity. If the message is valid, then sending a SECRET_FLAGS/OK message. Otherwise, log the error and close the websocket. If the receiving message is OK and sending OK message too, skip step 4 and consider the ws2p connection completely established.
4. Wait to receive a SECRET_FLAGS/OK message from the remote node, checking the validity. If the message is valid, then sending a SECRET_FLAGS/OK message. Otherwise, log the error and close the websocket. If the receiving message is OK and sending OK message too, skip step 4 and consider the ws2p connection completely established.
5. Wait to receive an OK message from the remote node, checking the validity. If the OK message is valid, then sending an OK message and consider the ws2p connection completely established. Otherwise, log the error and close the websocket.
5. Wait to receive an OK message from the remote node, checking the validity. If the OK message is valid, then sending an OK message and consider the ws2p connection completely established. Otherwise, log the error and close the websocket.
*timeout : 15 seconds for connection to a conventional endpoint. 30 seconds for connection to a hidden tor service.
\*timeout : 15 seconds for connection to a conventional endpoint. 30 seconds for connection to a hidden tor service.
For the remote node, only the first step change :
For the remote node, only the first step change :
1. Sudden receipt of a CONNECT message. If the CONNECT message is valid, then sending my own CONNECT message and an ACK message at the same time. Otherwise, log the error and close the websocket.
1. Sudden receipt of a CONNECT message. If the CONNECT message is valid, then sending my own CONNECT message and an ACK message at the same time. Otherwise, log the error and close the websocket.
**sync connection**
The connection steps are the same for a sync connection excepts :
1. The CONNECT message contains a chunkstamp telling from which chunk the asking node wants to synchronize from
2. After having sent it's ACK message, the responding node also sends a SYNC_INFO message described below
WARNING: independently of all these rules, each implementation must integrate its own anti-spam protections. Any connection can be rejected if the situation requires it (attack by denial of service for example).
WARNING: independently of all these rules, each implementation must integrate its own anti-spam protections. Any connection can be rejected if the situation requires it (attack by denial of service for example).
### CONNECT message
### CONNECT message
...
@@ -594,7 +601,7 @@ WARNING: independently of all these rules, each implementation must integrate it
...
@@ -594,7 +601,7 @@ WARNING: independently of all these rules, each implementation must integrate it
| flags_size | 1 | u8 |
| flags_size | 1 | u8 |
| flags_queries | flags_size | WS2PFlags |
| flags_queries | flags_size | WS2PFlags |
| peer_card | ? | Peer card |
| peer_card | ? | Peer card |
| chunkstamp | 4 | Opt(Blockstamp) |
| chunkstamp | 37 | Opt(Blockstamp) |
challenge := random hash generated by the sending node of the CONNECT message, the receiving node will then have to sign this challenge and then send this signature in its ACK message to prove that it has the corresponding private key to the public key it indicates.
challenge := random hash generated by the sending node of the CONNECT message, the receiving node will then have to sign this challenge and then send this signature in its ACK message to prove that it has the corresponding private key to the public key it indicates.
...
@@ -670,22 +677,28 @@ But sometimes the OK message can also transmit additional informations :
...
@@ -670,22 +677,28 @@ But sometimes the OK message can also transmit additional informations :
prefix := In ws2p v2, member nodes have the option of not publicly communicating their prefix. It will only reveal their prefix to the node of their choice among those with which they establish a connection. For example, a member node may decide to share its prefix only with other member nodes of the same key.
prefix := In ws2p v2, member nodes have the option of not publicly communicating their prefix. It will only reveal their prefix to the node of their choice among those with which they establish a connection. For example, a member node may decide to share its prefix only with other member nodes of the same key.
If this field is zero, it means that the remote node does not want to reveal its prefix (the prefix being necessarily greater than or equal to 1).
If this field is zero, it means that the remote node does not want to reveal its prefix (the prefix being necessarily greater than or equal to 1).
chunk_size := defines the size of the block used in milestones. A 1000-block chunk is a good compromise between efficiency of compression and duration of transfer
target_blockstamp := Indicates the current blockstamp of the message sender node. This blockstamp will be the target to reach for the node being synchronized.
target_blockstamp := Indicates the current blockstamp of the message sender node. This blockstamp will be the target to reach for the node being synchronized.
chunks_hashs := Hash table of the last block of each chunk. We do not need the block numbers, we know them. Here the remote node sends the hashs of all these chunk, which correspond to the current hashs of all the blocks having a number in 250 module 249, in ascending order.
milestones := Hash table of the last block of each chunk. We do not need the block numbers, we know them. Here the remote node sends the hashs of all these chunk, which correspond to the current hashs of all the blocks having a number in 250 module 249, in ascending order.
peer_cards := see [definition of binary peer card](#peer-card-binary-format)
