FYI I've checked the load of 3.8.7 on gwebcaches at http://gcachescan.jonatkins.com and it seems VERY high on some even compared to 3.6.15. The 3.8.x series was great for the caches, but the new code in 3.8.7 could be buggy.

merci

__________________
Liens d'intérêt /Links of interest:
Gnutellaforums en français /The House's rules you have to respect / First search the forum, then create a thread / Free software alternatives! - Logiciels alternatifs gratuits!/

That is the exact opposite effect of what we were looking for.

Thanks
-greg

I suspect that the change in the pong caching strategy has influenced this behavior, now the this cache is divided into separate slots dedicated per Hops value, instead of globally on the total number of cached pongs.

This is not strictly a "hammering behavior" but the current values of the maximum number of cached pongs per hop may not be correct, so that the pong cache gets now exhausted more often than before and Limewire needs more accesses to Gwebcaches.

I think we should monitor the pong cache state with statistics on it to see how they are really filled. In the past the pong cache was feeded in a serial way whatever their hops. But I suspect that most pongs are received now with hops=1 so this cache clot gets recycled very often.

May be this is a bug in some other (non-Limewire) servents that constantly send pongs from their cache with Hops=1, instead of the original hops value they received and that they should increment before storing it in their local pong cache.

I also suspect that the pong cache slots for Hops=5 or higher are almost always unused. From what I know, the cache slot size for Hops=1 is only 1 pong, and this may be too small for the actual pong traffic where most pongs are with TTL=1 and are recycled and exhausted too fast, so the pong cache may not contain enough alternate pongs for higher hops.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml