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.
gtk-gnutella-devel mailing list

Reply via email to