gionnico wrote: > Christian Biere ha scritto: > > gionnico wrote: > >> Christian Biere ha scritto: > >>> gionnico wrote: > >>>> Why , when I'm an ultranode, about for the first 24h LimeWire leaves > >>>> don't want to connect to me? > >>>> Can I change it in gnet_properties or in the debug window someway? > >>>> What's the name of the information I send them that they don't judge > >>>> "good enough" for a ultranode? > >>> What version of gtk-gnutella do you use? I guess, your ultrapeer isn't > >>> considered good enough because it doesn't send the infamous "X-Requeries" > >>> header.
> >> I'm using a SVN snapshot, with modified common.h to seem "stable". > >> How can I know what headers is my client sending, and how can I change it? > I answer in this old thread because it was OT. > I had previously noticed this problem. Updated to SVN when you told me > it, but there's still the same problem. > 1) My leaves are almost all giFT-Gnutella, Morpheus and Shareaza. giFT and Shareaza are not ultrapeer-capable, so all of them will be leaves. LimeWire only accepts a certain amount of foreign leaves and reserves most slots to LimeWire peers. This makes sense because the others (even gtk-gnutella) are not fully up-to-date. There'd be no progress at all if these dominated the network. Probably because of this, many leaves end up at gtk-gnutella ultrapeers as these are more tolerant. > Doesn't BearShare use the ultrapeer/leaf system? I've never ever seen a > BearShare as a leaf. Apparently BearShare peers don't accept any non-BearShare ultrapeers. Some older versions (and fakes) may accept others. > What can be wrong in the configuration? Does LimeWire filter by useragent? LimeWire only bans BearShare 5.2.x. They do however have several implicit preferences which result in some tendencies. > 2) It takes very very much time: more than 48h to have more than a > hundred leaves. Why is this? Can I accelerate the process? If your IP address is static or at least semi-static for long durations, it should become increasingly well-known and peers will arrive at your ultrapeer in no time. Otherwise, it may take much longer. You can increase the "quick connect pool" size and set the vendor limit to 40% or so. That will increase the number of peers you'll have contact with and thus spread your address more quickly. You should not modify the ultrapeer limits (min/max) too much from the defaults because they may fall out of the acceptable range, so that especially LimeWire peers may reject your ultrapeer. If you don't see any LimeWire peers of version 4.14.x or above, your IP address range might actually be banned by LimeWire. Their banning does not really have as much surgical precision as - let's say - a cruise missile. -- 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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
