![]() |
ultrapeer connects to too many ultrapeers on 2.9.10 I know that more recent versions of limewire accept more ultrapeer connections when running as an ultrapeer. however, 2.9.10 gives me almost three (3) times as many ultrapeer connections. there seem to be a lot of ultrapeers. considering, how badly ultrapeers do in terms of upload performance, i wonder whether this is a good thing. also: doesn't such a high ultrapeer density lead to an overly connected network with lots of redundant connections? lastly: I don't have a single non limewire host. how are we keeping the connection to other vendors? |
LimeWire reduced the outgoing bandwidth limit for ultrapeers in a first step to 8kb/s, so upload performance should not be a major issue. - I think LimeWire could go as low as 5kb/s once traffic compression is activated by default. As a general rule, the more ultrapeers there are, the lower the bandwidth requirement per ultrapeer. More ultrapeer connections do not increase the number of redundant connections if you reduce the TTL at the same time. The number of redundant connection is a function of your theoretical network horizon, not of the number of ultrapeer connections. LimeWire is not very good at keeping connections to other vendors because other vendors do not support this so-called 'high-outdegree network' yet. You can expect that to change with the next BearShare release. The new BearShare betas already connect to LimeWire very well. And you don't really want good connections to lame GnucDNA client, - because they can mess up your searches. If you search for "the song xy" GnucDNA based clients (Morpheus, Gnucleus, Mynapster) seem return all results containing "the", "song" or "xy" - and that can really hurt you when your ultrapeers will return only so many results and all of them are completely unrelated to what you were searching for because you have a couple of GnucDNA clients in your neighbourhood. |
Thanks for the info. Ultrapeer bandwidth: I was referring to upload of shared files, not messages. Sorry for the confusion. I have about 1/5 of the uploads of what I get when I run as a leaf. My thinking is a high percentage of ultrapeers (read: hosts with reduced file upload capacity) is bad for the network. Redundant connections: TTL solution makes sense, although it still seems that the higher the number of Ultrapeers, the higher the chance of circles, but I guess there are reasons for more ultrapeers. GnucDNA: This sucks, there seem to be many, esp. when counting Morpheus. :-( |
Quote:
Quote:
|
Quote:
This could be an isolated exceptional case, but it seems unlikely. I'm on a completely average, normal cable connection. |
Normally a good process for ultrapeer selection includes as a paramater the number of files a user is sharing or the average number of uploads. I know Bearshare is doing that, but I nerver heard about it for Limewire (Trap_jaw???). If you are a big sharer, disable the ultrapeer option in preferences. Oh and an 2.9.x ultrapeer has a hard limit of 8Kb/s of message routing, so even 2.9.10 with 32 connections should route the same amount of message as 16 connections for 2.9.8. |
Unfortunately LimeWire does not consider the number of shared files when electing ultrapeers. Even worse, a client that never shared a single file can never become an ultrapeer because LimeWire could not confirm that the outgoing bandwidth is sufficient to serve as an ultrapeer. |
Quote:
|
Quote:
|
Forced partial file sharing is then the way to go! Leechers will be forced to share at least when downloading videos.... Promoting them to ultrapeer on next startup... |
All times are GMT -7. The time now is 09:38 AM. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2025, vBulletin Solutions, Inc.
SEO by vBSEO 3.6.0 ©2011, Crawlability, Inc.
Copyright © 2020 Gnutella Forums.
All Rights Reserved.