Hi Slavcho,

Sorry for the late comments. As you know I was away for awhile…

So, I did some tests using searches of different popularity and with different number of peer connections. I observed, as we have already discussed, that the popular searches may yield thousand results just in response to the probe query. That is too much provided we want to get about 150 hits, but we can generally do nothing about that. However, I checked some of your defines and I think maybe tuning some of them would be possible.

You have chosen probe TTL of 2 (PROBE_TTL) and number of probe queries equal 3 (NUM_PROBES). Did you choose these values according to the dynamic searching specs? I tried to reduce the probe TTL and for the same popular search I got about 60 hits from the probe queries and then continued to query with ttl of 1 until 200 hits were reached.

Trying a less popular search, I noticed that the search is stopped when about 200 hits were received, but in the next seconds at least that much more hits are received as well, thus making a total of more than 400 hits. Maybe we wait too little before issuing a further query?

Another observation is that if the probe query returns too few results then you directly try a query with the maximum ttl. The former results in more than thousand hits! Maybe we could gradually increase the ttl first to 2 and then to 3?

Can you comment on the above issues (maybe also with regard to the original specs)?

Lastly, I saw that from within PacketProcessor::packetReceived() you call Searcher::queryHitsReceived(). The PacketProcessor does not need to know about the Searcher… maybe you could simply connect the signal receivedQueryHits() with the Searcher’s slot?