[Agthorr]

In CSearch::jumpStart(), there's some code that looks like it intends to delete potential contacts that are further away than the best response we've received so far. However, as I read the code it actually deletes all potential contacts that are *closer* than the best response we've received so far, which is counter-productive.

00215         CUInt128 best;
00216         // Remove any obsolete possible contacts
00217         if (!m_responded.empty())
00218         {
00219                 best = m_responded.begin()->first;
00220                 ContactMap::iterator it = m_possible.begin();
00221                 while (it != m_possible.end())
00222                 {
00223                         if (it->first < best)
00224                                 it = m_possible.erase(it);
00225                         else
00226                                 it++;
00227                 }
00228         }

The '<' on line 223 should be a '>', shouldn't it?

[Unknown1]

I'm going to be brutaly honest.. I have NO idea what the previous dev was thinking here.. I can't find any hidden benefit here.

Yes, it clips anything better then the top responder here off of the possible list.. No idea what was the purpose here.. It normall only removes a couple contacts which doesn't bother much, but still..

Switching to > would bascially just kill the search all together as it will remove all possible contacts..

The "possible" list is a backup to keep the search from stalling.. It's sorted from best to worst.. So who cares if there are extra contacts here, so using up cpu cycles to remove them is pointless..

[Agthorr]

Unknown1, on Jun 13 2005, 09:30 PM, said:

Switching to > would bascially just kill the search all together as it will remove all possible contacts..

True, but that's because m_possible is never added to, and it's sorted the wrong way. See the other bugs I logged.

I think the way it was *supposed* to work was that this would be a way to force the search terminate if we've already heard back from the closest node to the target. If we've heard of some nodes that might be closer, then we don't want to delete those without trying them, but everything else is junk and we should terminate the search if there aren't any better nodes.

[Unknown1]

I already corrected that bug on a internal build.. So the sorting is now correct.. And yes new contacts are added to the possible list during the search..

You can't terminate just because you found the target node. Terminating at this point is good on paper; but in pratice, is bad for our purpose.. That target node may be new in the system and not have the information you are looking for.. There are other conditions that are used to determine if the search should terminate..

[spanish man]

Can we see the fix ?

[tHeWiZaRdOfDoS]

In v0.46b I suppose... ARGH I'd really wish there was a CVS access...

[spanish man]

Yes will be on 0.46b I think, but it was a try to have a fix *gg*