> Haxe wrote:
>> Even if BearShare ultrapeers are no longer listed in the
>> bootstrapping databases, shouldn't they appear in my cache after
>> some network use?
On 4 Mar 2007, [EMAIL PROTECTED] wrote:
> My guess is that Limewire ultras don't connect to Bearshare so when
> you ping them, they tell you the ultras they're connected to, so you
> don't get to know about any Bearshares
This is quite probable. The modern LimeWire clients won't connect to
Ultras that don't have sufficient out-degree, QRP, low TTL and dynamic
querying.
GOOD_ULTRAPEER = isHighDegreeConnection() &&
isUltrapeerQueryRoutingConnection() &&
(getMaxTTL() < 5) &&
isDynamicQueryConnection();
However, they should still run ping/pongs and fill their host cache
with these. Also, query responses and other items could fill the host
cache. Any of these could be a BearShare node. I guess there could
be less BearShare nodes known to LimeWire ultras. Also, I think most
servent types have far smaller host caches than GTKG.
> However, Bearshares prefer to connect to other Bearshare ultras and
> wouldn't choose to connect to a gtk-gnutella, so I only pick up more
> Bearshares when I drop below my minimum number of peers and start to
> ping for more.
This is interesting. I have seen that when initially connecting to
GnutellaNet I have many outgoing BearShare connections, but they seem
to diminish as time goes on. Nice observation!
There are some papers on the GnutellaNet that seem to say that we have
islands. Look for small world.
"http://mirage.cs.uoregon.edu/pub/sigmet04-extabs.pdf";
"http://www.imconf.net/imc-2005/papers/imc05efiles/stutzbach/stutzbach.pdf";
I don't think that we are totally unconnected from BearShare nodes
when we have dominate LimeWire connections. This can be verified by
looking at the vendor in search responses. There might be some reason
that LimeWire Ultras don't route BearShare queries (for oggs, etc).
I had considered augmenting hosts, ultras to include a vendor name (if
we have discovered the vendor); a blank would be "random". This
*might* allow less connections attempts to fulfill the monopoly
requirements. It could also give a GTKG ultra more diversity on
average.
A "last seen" field in hosts and ultras might also be useful. These
might help to combat systematic biases due to floods of one vendor
filling our host caches. Randomness often performs very well. I
don't know if these changes would make the host cache more or less
random. :(
<aside>
Note this quote in the first paper...
Distinct spikes at a degree of 30, 45 and 75 are visible. The
first two spikes are due to the corresponding parameters used in
LimeWire and BearShare implementations, respectively. The third
spike is due to a less common implementation.
I think gnet_props.ag had max_leaves set to 75/80 at the time these
snapshot were taken.
??? Gtk-gnuetalla, the name academics fear to speak ??? ;-)
</aside>
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
