It supports both storing immutable items, where the key is the SHA-1 hash of the data itself, and mutable items, where the key is the public key of the key pair used to sign the data.
-There are two new proposed messages, put and get.
+There are two new proposed messages, put and get.
In this document, a storage node refers to the node in the DHT to which @@ -88,24 +88,24 @@ alive.
The proposed new messages get and put are similar to the existing get_peers -and announce_peer.
-Responses to get should always include nodes and nodes6 has the same -semantics as in its get_peers response. It should also include a write token, -token, with the same semantics as get_peers.
-The id field in these messages has the same semantics as the standard DHT messages, +
The proposed new messages get and put are similar to the existing get_peers +and announce_peer.
+Responses to get should always include nodes and nodes6 has the same +semantics as in its get_peers response. It should also include a write token, +token, with the same semantics as get_peers.
+The id field in these messages has the same semantics as the standard DHT messages, i.e. the node ID of the node sending the message, to maintain the structure of the DHT network.
-The token field also has the same semantics as the standard DHT message get_peers -and announce_peer, when requesting an item and to write an item respectively.
+The token field also has the same semantics as the standard DHT message get_peers +and announce_peer, when requesting an item and to write an item respectively.
The distinction between storing mutable and immutable items is the inclusion -of a public key, a sequence number and signature (k, seq and sig). +of a public key, a sequence number and signature (k, seq and sig). The distinction betwewn retrieving a mutable and immutable item is the inclusion of -the public key spill-over (k) in the get request.
-The v key is the value to be stored. It is allowed to be any bencoded type (list, +the public key spill-over (k) in the get request.
+The v key is the value to be stored. It is allowed to be any bencoded type (list, dict, string or integer). When it's being hashed (for verifying its signature or to calculate its key), its flattened, bencoded, form is used.
-Storing nodes are SHOULD reject put requests where the bencoded form of v is longer +
Storing nodes are SHOULD reject put requests where the bencoded form of v is longer than 767 bytes.
In order to avoid a malicious node to overwrite the list head with an old -version, the sequence number seq must be monotonically increasing for each update, +version, the sequence number seq must be monotonically increasing for each update, and a node hosting the list node MUST not downgrade a list head from a higher sequence number to a lower one, only upgrade.
The signature is a 2048 bit RSA signature of the SHA-1 hash of the bencoded sequence -number and v key. e.g. something like this:: 3:seqi4e1:v12:Hello world!.
+number and v key. e.g. something like this:: 3:seqi4e1:v12:Hello world!.Request:
@@ -198,7 +198,7 @@ number and v key. e.g "q": "put" } -Storing nodes receiving a put request where seq is lower than what's already +
Storing nodes receiving a put request where seq is lower than what's already stored on the node, MUST reject the request.
Response:
@@ -214,14 +214,14 @@ stored on the node, MUST reject the request.Request:
{ - "r": + "a": { "id": <20 byte id of sending node (string)>, "target:" <first 20 bytes of public key (string)>, "k": <remaining 248 bytes of public key (string)> }, "t": <transaction-id (string)>, - "y": "r", + "y": "q", "q": "get" }@@ -232,11 +232,12 @@ stored on the node, MUST reject the request. { "id": <20 byte id of sending node (string)>, "k": <RSA-2048 public key (268 bytes string)>, + "nodes": <IPv4 nodes close to 'target'>, + "nodes6": <IPv6 nodes close to 'target'>, "seq": <monotonically increasing sequence number (integer)>, "sig": <RSA-2048 signature (256 bytes string)>, "token": <write-token (string)>, "v": <any bencoded type, whose encoded size < 768> - }, "t": <transaction-id (string)>, "y": "r", @@ -250,7 +251,7 @@ stored on the node, MUST reject the request. value and sequence number should be done as follows:
- encode value and sequence number separately
-- concatenate "3:seqi" seq "e1:v" and the encoded value. +
- concatenate "3:seqi" seq "e1:v" and the encoded value. sequence number 1 of value "Hello World!" would be converted to: 3:seqi1e1:v12:Hello World! In this way it is not possible to convince a node that part of the length is actually part of the sequence number even if the parser contains certain bugs. Furthermore it is not possible to have a diff --git a/docs/dht_store.rst b/docs/dht_store.rst index a256c9722..0d8a017a8 100644 --- a/docs/dht_store.rst +++ b/docs/dht_store.rst @@ -118,7 +118,7 @@ Response: "id": *<20 byte id of sending node (string)>*, "token": *
*, "v": * *, - "nodes": * * + "nodes": * *, "nodes6": * * }, "t": * *, @@ -184,14 +184,14 @@ Request: .. parsed-literal:: { - "r": + "a": { "id": *<20 byte id of sending node (string)>*, "target:" * *, "k": * * }, "t": * *, - "y": "r", + "y": "q", "q": "get" } @@ -204,11 +204,12 @@ Response: { "id": *<20 byte id of sending node (string)>*, "k": * *, + "nodes": * *, + "nodes6": * *, "seq": * *, "sig": * *, "token": * *, "v": * * - }, "t": * *, "y": "r",