Gnutella Forums

Gnutella Forums (https://www.gnutellaforums.com/)
-   LimeWire Beta Archives (https://www.gnutellaforums.com/limewire-beta-archives/)
-   -   ultrapeer connects to too many ultrapeers on 2.9.10 (https://www.gnutellaforums.com/limewire-beta-archives/20260-ultrapeer-connects-too-many-ultrapeers-2-9-10-a.html)

osu_uma May 9th, 2003 05:03 PM

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?

trap_jaw2 May 10th, 2003 12:53 AM

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.

osu_uma May 10th, 2003 01:49 AM

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. :-(

trap_jaw2 May 10th, 2003 03:21 AM

Quote:

Originally posted by osu_uma
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.
I was talking about the same thing. The number of upload requests should be the same when running as an ultrapeer as when running as a leaf. The only thing that could keep you from uploading is that you have to devote bandwidth to relaying messages. - If you have more ultrapeers the number of relayed messages should remain more or less the same so each ultrapeer would have to relay fewer messages. If there are more ultrapeers but the the upload capacity per ultrapeer is increased, you should not loose anything.

Quote:

GnucDNA: This sucks, there seem to be many, esp. when counting Morpheus. :-(
Morpheus doesn't have that many users anymore. Both BearShare and LimeWire have a lot more users.

osu_uma May 10th, 2003 09:29 AM

Quote:

Originally posted by trap_jaw2
The only thing that could keep you from uploading is that you have to devote bandwidth to relaying messages.

Exactly. That's what it seems to be. Again, this is actual experience, not just me theorizing. And if that's the case, more ultrapeers means less upload bandwidth available in the network.

This could be an isolated exceptional case, but it seems unlikely. I'm on a completely average, normal cable connection.

et voilą May 10th, 2003 10:01 AM

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.

trap_jaw2 May 10th, 2003 12:21 PM

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.

osu_uma May 10th, 2003 03:01 PM

Quote:

Originally posted by trap_jaw2
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.
that makes it even worse. does the limewire crew know about this issue?

trap_jaw2 May 10th, 2003 04:41 PM

Quote:

Originally posted by osu_uma
that makes it even worse. does the limewire crew know about this issue?
I guess so.

et voilą May 11th, 2003 06:48 AM

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.