Re: [gtk-gnutella-devel] Gnutella connections healthy again
On Friday 21 March 2008, Raphael Manfredi wrote: > It does still put pong results into the cache. The only thing it no > longer does is serving pongs out of the "recent pongs" pool: instead > only the long-term host cache is used to serve pongs. Ah, OK. Sorry. h - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ gtk-gnutella-devel mailing list gtk-gnutella-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
Re: [gtk-gnutella-devel] Gnutella connections healthy again
Quoting Hauke Hachmann <[EMAIL PROTECTED]> from ml.softs.gtk-gnutella.devel: :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? It does still put pong results into the cache. The only thing it no longer does is serving pongs out of the "recent pongs" pool: instead only the long-term host cache is used to serve pongs. Raphael - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ gtk-gnutella-devel mailing list gtk-gnutella-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
Re: [gtk-gnutella-devel] Gnutella connections healthy again
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/vse012070mrt/direct/01/ ___ gtk-gnutella-devel mailing list gtk-gnutella-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
Re: [gtk-gnutella-devel] Gnutella connections healthy again
Hauke Hachmann wrote: > On Tuesday 18 March 2008, Christian Biere wrote: > > Hauke Hachmann wrote: > > > My connection profile looks much healthier now. A good mixture of > > > LimeWire/FrostWire, BearShare and gtk-gnutella. > > > > Is that the only improvement you've noticed? Did you notice > > better/more good search results as well? > I don't have much data to compare. I search only occasionally, and > everything I can say about result quality is just rough gut feelings. > But I tend to agree: My received query results are not more useful than > before. Even if it's not much data, user experience the most useful indicator. Nice statistics are useless if the net result is frustrated users. > 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. As mentioned, the amount of spam relayed through these Ultrapeers seems to be much higher than recent LimeWires. -- 1000 octets = 1 ko = 1 kilooctet; 1024 octets = 1 Kio = 1 kibioctet 1000^2 octets = 1 Mo = 1 megaoctet; 1024^2 octets = 1 Mio = 1 mebioctet 1000^3 octets = 1 Go = 1 gigaoctet; 1024^3 octets = 1 Gio = 1 gibioctet - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ gtk-gnutella-devel mailing list gtk-gnutella-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
Re: [gtk-gnutella-devel] Gnutella connections healthy again
On Tuesday 18 March 2008, Christian Biere wrote: > Hauke Hachmann wrote: > > My connection profile looks much healthier now. A good mixture of > > LimeWire/FrostWire, BearShare and gtk-gnutella. > > Is that the only improvement you've noticed? Did you notice > better/more good search results as well? I would have expected that > there's a notable difference between the BearShare cluster and the > rest of Gnutella. There seems to be less spam outside of the > BearShare cluster nowadays but the good results appear to be heavily > reduced too. I don't have much data to compare. I search only occasionally, and everything I can say about result quality is just rough gut feelings. But I tend to agree: My received query results are not more useful than before. 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? h - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ gtk-gnutella-devel mailing list gtk-gnutella-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
Re: [gtk-gnutella-devel] Gnutella connections healthy again
Hauke Hachmann wrote: > My connection profile looks much healthier now. A good mixture of > LimeWire/FrostWire, BearShare and gtk-gnutella. Is that the only improvement you've noticed? Did you notice better/more good search results as well? I would have expected that there's a notable difference between the BearShare cluster and the rest of Gnutella. There seems to be less spam outside of the BearShare cluster nowadays but the good results appear to be heavily reduced too. -- 1000 octets = 1 ko = 1 kilooctet; 1024 octets = 1 Kio = 1 kibioctet 1000^2 octets = 1 Mo = 1 megaoctet; 1024^2 octets = 1 Mio = 1 mebioctet 1000^3 octets = 1 Go = 1 gigaoctet; 1024^3 octets = 1 Gio = 1 gibioctet - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ gtk-gnutella-devel mailing list gtk-gnutella-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
