Simon Désaulniers authored 8 years ago and Adrien Béraud committed 8 years ago

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.

dht: appropriate time info in permanent put ops

Simon Désaulniers authored 8 years ago and Adrien Béraud committed 8 years ago

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.

* automatic connection loss recovery
* dhtrunner: asynchronous DNS lookup for bootstrap
* handle values up to 64k
* better support for large values on macOS
* dht: add callback to pingNode
* fix compilation with recent clang versions

search: detect connectivity changes

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.

dhtrunner: recover from network changes

network: transmit large values in multiple packets

Simon Désaulniers authored 8 years ago and Adrien Béraud committed 8 years ago

This is to prevent any thread relying on network_engine's callback to block
forever just like the Dht::sendPing's callback.

Using a list of bootstrap nodes, we recover from network loss by pinging those
nodes continuously until connected.
Written with Simon Désaulniers.

dht: bug fixes, timing computation enhancements

'find_node' requests don't ask for values. Then, the idea of a Query makes less
sense, but since we still need those to map status to network engine requests,
we introduce dummy queries which with the field Query::none. Those queries will
then only serve as key to network engine's requests.