The op token is renewed regularly (around every 30 minutes),
so SHA256 provides enough security for this non-sensitive token.
SHA256 takes 32 bytes instead of 64 bytes for SHA512,
and the token is included in every listen requests,
renewed every 30 seconds, and every answer to get.
In the context of limited bandwith usage, using SHA256 seems more appropriate.
This change is backward and forward compatible.
After a connectivity change, the DHT would enter the "connecting" state in order
to try to resolve good nodes. However, the previous algorithm would
probabilistically increase time for completion each time a node would fail to
resolve. We now avoid this by prioritizing non-expired nodes in the process.
Also, a subtle error would sensibly stop the process for 30 minutes due to using
the Node::NODE_EXPIRE_TIME constant instead of Node::MAX_RESPONSE_TIME.
We used to send values once to a given node,
however the receiving node may have canceled
or dropped the request since then,
so we now send the values for every socket and
the optimization will happen on the sending side.
Since the initial implementation of listen operation, multiple listen requests
from a single node on a same hash was not possible without singular
inconsistencies. The flaw was coming from the fact that nodes receiving listen
request could not differentiate between listen refresh request and a new
independent listen request.
This patch introduces the new net::Socket structure which in time will enable
remote nodes to send update for a storage while differentiating between
concurrent listen requests. A socket has a unique identifier which consists of a
transaction id as defined in the OpenDHT protocol.
Historically, the next announce timing was based on the last acknowledgement
received from a SearchNode. This behavior was invalid since the 'refresh'
operation. In fact, for a given value that was "refreshed", its creation time
would differ from the announcer's info. Therefor, all search node's
reannouncing timings would differ, hence causing inconsistency on the network.
This operation requests a node to refresh a value's time_point information of
its lifetime begining. This is intended to fix the *permanent put* operation
which has been having syncing issues since the introduction of an enhanced and
lighter put operation.
The number of bad nodes is limited in order to help determine presence of
connectivity changes. See https://github.com/savoirfairelinux/opendht/issues/137
for details.
According to the tables, 25 is a good average value for big networks. If the
network is small, normal search expiration process will handle the situation.
Simon Désaulniers
Adrien Béraud
atraczyk