'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.
The code preceding this would just not take multiple concurrent queries for a
same search into account. This is a bug fix for a bad behavior since the
queries.
The criteria has been rewritten (again) exploiting the idea behind the parameter
'update' to take into account the case where we have new distinct requests to
send, then bypass some checks.
Since pagination, a bug was making the listen feature unusable running in
infinite loop. This also makes more sense than sending 'get' since the listen
request is paired with a Query defining the values that have to be fetched.
In SearchNode::canGet, we don't send a 'get' request to a search node if a
satisfying query for the query we want to send is already pending. This patch
honors this behavior.
Instead of literally asking to a node all values for givent `h`, we first ask
for all ids the node has. Then, we concurently and individually ask for each
values that match each id we recovered in our first request.
Since bootstrapSearch was rewritten to use the node cache, it made it clear that
refill should be rewritten as such. However, then bootstrapSearch becomes
irrelevant.
An enhancement to refill is that it will let insertNode review its whole list
of nodes and then let it insert nodes up to SEARCH_NODES nodes. The previous
method would not garantee this behavior since, most of the times, it would pass
less than SEARCH_NODES nodes to insertNode.
The number of currently requested nodes, formerly named currentGetRequests, was
renamed since it was not accurately describing the behavior. The number we are
counting is not the number of 'get' requests, but rather the number of nodes
being requested simultaneously.
When a 'get' request associated with a certain 'query' has been sent, we don't
want to send it again, i.e. we don't care if it's pending or not as soon as it
has been sent.
Each time a 'listen' request is sent to the network engine, we track this
request in the upper layer with a map<shared_ptr<Query>, shared_ptr<Request>>.
At some point, this map has to be maintained or totally cleared. However, it was
done wrong, hence the sendListen loop. Clearing a pair <Query, Request> has to
be done when the API user cancels a 'listen' operation.
Adrien Béraud
Simon Désaulniers
kaldoran
Nicolas