On 30 Jul 2006, [EMAIL PROTECTED] wrote: > I've got my GnutellaNet settings to limit connections of 25% to > anyone vendor (and reserve 50% for GTKG nodes). However I always > seem to end up with all Limewire connections (in bold). > > Is this because satellite nodes (the greyed out ones) count towards > the totals? I don't seem to be seeing any other GTKG nodes.
I don't think that GTKG nodes are that common. Crawler statistics or something else might be useful so that people could gauge whether this is an anomaly or not. When I run as an Utlra with 25-40 nodes, I can get about 3-4 GTKG ultra peers after about three days. 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 do believe that leaf nodes (satellites) count towards GTKG nodes. I wouldn't set the limits as you have. I think that 10-20% for GTKG is sufficient. Also, you might want to increase your vendor limit to at least 33%. I think that 40% might be better as most nodes seem to be LimeWire and BearShare. It takes some time to collect ultras not from these vendors. It was also recently discussed to decrease the connection limit (seen at the bottom of the GNET pane) to a lower value like 10-20. This limits the amount of "guesses/probes" that GTKG makes to find these hosts. These probes take a lot of CPU. It would make some more sense to use some sort of "PID" algorithm to try and target the vendor limits. For example, the minimum ultra is set to 40 and the vendor limit is 50%. If during connect a vendor has 20 connection, all similar vendors are dropped even if there are 20 slots left to fill. It might make more sense to keep half of them (20 left to be filled). As the original 30 ultra nodes are lost they will be filled with a different vendor. So after a long time, GTKG would reach the vendor target but more ultras would be available sooner possibly helping to populate the host cache with more current information. [Actually the algorithm above is just "proportional", with no "integral" or "derivative" portion]. 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. Providing a field for a DNS entry would also be helpful. Of course all this would take extra coding. And perhaps I have a limited understanding of the difficulties and sublties since I have a very immature understanding of GTKG. fwiw, Bill Pringlemeir. ------------------------------------------------------------------------- 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
