@@ -11,6 +11,7 @@ This document details the current specifications of WS2P v1 as they are already
*[Getting endpoints from other Duniter nodes](#getting-endpoints-from-other-duniter-nodes)
*[Priority of WS2P outcoming connections](#priority-of-ws2p-outcoming-connections)
*[Establishing a WS2P connection](#establishing-a-ws2p-connection)
*[Rules for accepting an incoming connection](#rules-for-accepting-an-incoming-connection)
*[HEAD messages](#head-messages)
*[Documents messages](#documents-messages)
*[Peer format](#peer-format)
...
...
@@ -83,7 +84,6 @@ If the key is a member: +1
If the key is preferred/privileged: +2
If the key is the same as yourself: +4 (for multi-node)
## Establishing a WS2P connection
After sorting all WS2P endpoints according to the criteria described in the previous section,
...
...
@@ -93,8 +93,8 @@ for each connection attempt, the process is as follows:
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.
3. 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.
4. Wait to receive an ACK message from the remote node, checking the validity. If the CONNECT message is valid, then sending an OK message. Otherwise, log the error and close the websocket.
5. Wait to receive an OK message from the remote node, checking the validity. If the CONNECT message is valid, then consider the ws2p connection completely established. Otherwise, log the error and close the websocket.
4. Wait to receive an ACK message from the remote node, checking the validity. If the ACK message is valid, then sending an OK message. 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 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.
...
...
@@ -145,6 +145,32 @@ raw format : `WS2P:OK:currency_name:pub:challenge`
_**Be careful**, this time the challenge is the one that **the remote node sent us** in **its own CONNECT message**._
## Rules for accepting an incoming connection
When a CONNECT message is received from another node, three decisions are possible :
1. Accept connection
2. Refuse connection
3. not answering
The node will always try to answer when possible, to do so it launches a timeout on its side as soon as it receives the request.
When the timeout is reached, if the request has not been fully processed, it is purely abandoned and the remote node will not receive an answer.
In cases where the request is fully processed before the timeout, the response is determined according to the following algorithm :
If the public key of the remote node is the same as yourself
If the uuid is not the same, accept the connection. Otherwise, refuse connection. (do not accept oneself connetion).
If the pubkey is banned, refuse connection.
If priorityKeysOnly is enable and the pubkey isn't privileged, refuse connection.
If there is already an active ws2p connection with this key (whether incoming or outcoming), refuse connection.
If the incoming quota is not reached, accept the connection.
If there is a strictly lower priority* incoming connection, accept the connection.
Refuse connection.
Following the acceptance of an incoming connection, it may happen that the quota is exceeded,
in this case a low priority* connection is deleted until the quota is respected.
_*The priority score is calculated in the same way as for outcoming connections._
## HEAD messages
Each duniter node informs the network of its current state via a HEAD, which is renewed with each new valid block.
