1 M24 release. BitTorrent and Mainline DHT protocol extensions.
\r
3 Mainline DHT is used in the Nextshare content delivery platform for the peer discovery process.
\r
4 Currently, the performance of the protocol is very poor, with the median lookup time taking up to 1 minute.
\r
5 We believe this poor performance is due to the bad management of the peer routing tables.
\r
7 Therefore, we propose a modification to the current MDHT protocol with a particular
\r
8 focus on a better routing table management, while maintaining its backward compatibility.
\r
9 Our MDHT protocol extensions are a follow up of our previous experiments on more then 3 million deployed nodes.
\r
11 The extensions in MDHT include (general):
\r
13 - A main routing table and a replacement routing table. The main routing table contains best known nodes;
\r
14 such nodes are considered best nodes when they are reachable from us and when our requests to them
\r
16 - The nodes in the replacement table are nodes with relatively good attributes; for example, they
\r
17 demonstrate a significant number of responses to our requests and they have a relatively low number of
\r
18 timeouts. Such nodes are used (moved to the main routing table) as main nodes, when the current nodes
\r
19 in the main routing table fail to respond to our queries.
\r
21 - A node always starts in quarantine, no matter in which routing table the node is in.
\r
22 A node is in quarantine for as long as there is no response from it, after having sent us a query for about
\r
23 3 minutes ago. The quarantine ends when there is a 3 minutes window between a query from the node and
\r
24 the next response. This quarantine period is designed to detect possible NATed nodes. If a node is in quarantine,
\r
25 we are not sure whether the node is behind a NAT, but if the node is not in the quarantine - then we are
\r
26 pretty confident that the node in not behind the NAT. A node that is not in quarantine never comes back to the
\r
27 quarantine (unless it is completely kicked out from both tables and we loose all rnode information, and therefore starts over).
\r
29 - Nodes in the main table are refreshed every 3 minutes (if nodes are in quarantine), and every 10 minutes
\r
30 (if nodes aren't in quarantine). Nodes in the replacement table are not refreshed (no matter whether they are in
\r
33 - The nodes that are in one of the routing tables (main or replacement) are called rnodes. They store node-specific
\r
34 information such as: the number of queries to the node, the number of responses from the node, the number of timeouts and errors.
\r
36 - Nodes are added to the main routing table only after they have been checked for reachability; nodes are
\r
37 not added to the main routing table if they don't respond to our reachability check queries.
\r
39 - When a node in the main table gets a timeout, it goes to the replacement table. In fact, this node gets replaced with a better
\r
40 node from the replacement table. The following happens inside the replacement table in order to select the best node for the main table:
\r
41 - All the nodes in the correct bucket of the replacement table are pinged - checked for reachability
\r
42 - Pings to the NextShare (NS) nodes are delayed for 200ms (in order to give priority to NS nodes)
\r
43 - The node that replies first (the fastest) to our query is chosen as the best node for the main table
\r
46 More details on the routing table management:
\r
48 - When a query is received from a node which is not in any of the routing tables, then this node is checked for reachability.
\r
49 If there is room in the main table, the node will be added only if it responded to our reachability check (ping query).
\r
50 Otherwise, the worst node in the replacement table will be replaced with this new-coming node.
\r
51 A node in the replacement table is considered the "worst node" when its accummulated number of timeouts exceeds 3.
\r
53 - When a response is received from a node that is already in the main routing table, then it is simply refreshed.
\r
54 Otherwise, if the response comes from a node that is not an rnode and if there is room in the replacement table, then the
\r
55 node is simply replaced with the worst node of the replacement table.
\r
57 - If there is a timeout from a node that is in the main routing table, then it is simply removed from the main table and
\r
58 put into the replacement table. In fact, the node that did timeout is put inside the replacement table in place of the worst node.
\r
60 - Regarding the worst node selection inside the replacement table, we emphasize that the NS nodes are favored to remain inside
\r
61 the table. When the replacement table is refreshed - in order to identify the worst node in the bucket - the first pings (reachability checks)
\r
62 are sent to the NS nodes, and only after a delay, they are sent to the rest of the nodes.
\r
65 Additional Mainline DHT extensions - nodes2 replies:
\r
67 - For IPv4 nodes, we use the standard 'compact node info' encoding, specified in the BitTorrent protocol. However,
\r
68 the protocol specification does not have support for IPv6 nodes. The DHT messages - the 'nodes' replies - don't support IPv6,
\r
69 because all the node contacts are encoded as 6-bytes but IPv6 nodes need 18-bytes. Therefore, in this protocol extension we
\r
70 use libtorrent - which implements a few extensions to MDHT - in order to make use of the 'nodes2' for IPv6 contact encoding.
\r
72 - According to the libtorrent specification, replies with the 'nodes2' key are contacts that are encoded as 20-bytes node ID and
\r
73 then a variable length encoded IP address (6 bytes in IPv4 case and 18 bytes in IPv6 case).
\r
projects / cs-p2p-next.git / blob