Bill Pringlemeir wrote: > However, I do notice a distinct preference to either Limewire or > Bearshare ultras. It seems to depend on build/host cache, with either > vendor becoming dominant.
> It might be that they are only recommending hosts from the same vendor? I think that's indeed the case. It might not be fully intented but rather the side-effect of other preferences which cause an island effect. > Another "win" in my opinion would be to store the vendor id in the > host cache. It doesn't seem to make sense to probe hosts that > previously had a vendor id that is over the current limit. We don't know the vendor ID of all cached addresses. Also just because we know it's a LimeWire peer that doesn't mean it will only provide us with addresses of LimeWire peers. Sure, there are probabilities and there could be some weighting like that but it's no so straight-forward. Part of the problem is also that Gtk-Gnutella still does not utilize UHC PINGs and PONGs properly. It should really periodically ping a random peer (a different each time) from its cache to keep it fresh and increase the diversity. Though this might reduce the visibility of some vendors even further. For example, neither BearShare nor Shareaza support the UHC model. -- Christian
pgpM46WdCNG04.pgp
Description: PGP signature
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Gtk-gnutella-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
