On Tuesday 18 March 2008, Christian Biere wrote: > > BTW, the "healthy" connection profile I wrote about seems to be not > > very stable. Now that the BearShare monopoly is circumvented, it is > > quite hard for me to avoid a LimeWire monopoly, and this bias seems > > to get stronger every day, possibly due to my ultrapeer cache > > slowly converging to reflect that monopoly. Perhaps one of the two > > recent measures to keep BearShare out of our cache was one too much > > in the long run? > > I relaxed the constraint regarding historic ports, so that the > addresses of these BearShare peers are still accepted with low > probability. You could look for BearShare peers in your results and > try to connect to them to accelerate discovery of them.
That didn't seem to do the trick for me. Keeping the number of hosts with historic ports in the cache low may work well if you don't use the anti-monopoly feature. It will then lead to a better connection profile on _average_, considering all GTKG peers in the network as a whole. But the anti-monopoly feature enforces a certain connection profile on every _particular_ instance of GTKG (that has this feature enabled). I have this feature enabled, because I am not only interested in the health of the network as a whole, but of course also in the health of my very particular connection profile, because I want to receive good (read: diverse) search results and also want to share my files to as many network islands as possible. To make this work smoothly, one should not only control which hosts are put _into_ the cache, but also make a selection decision when hosts are read _out_ of the cache. Like the one I proposed 2008-01-10. BTW, since GTKG no longer puts pong results into the cache, the number of historic hosts has already decreased a lot, so perhaps the test in hcache_add_internal() is no longer needed at all? bye, Hauke ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
