Gnutella Forums

Gnutella Forums (https://www.gnutellaforums.com/)
-   New Feature Requests (https://www.gnutellaforums.com/new-feature-requests/)
-   -   connection limit suggestion (https://www.gnutellaforums.com/new-feature-requests/10787-connection-limit-suggestion.html)

Cornholio April 24th, 2002 04:47 PM

connection limit suggestion
 
Get rid of it!!! It is ABSURD to be on a T1 and to be able to maintain only 10 connections (especially with the new ultrapeer code).

I can hear the followup "workaround" suggestions already... "Why don't you just switch your connection type to T3, then you can have as many as you want." I don't want to. Firstly, I don't like the idea of misrepresenting my connection to others. Secondly, I am at a business and like to limit my upload bandwith (usually 35 KB/s). I've noticed that if I switch to T3, the minimum cutoff for uploads jumps to 90 something KB/s.

I'd suggest just making it a warning. Something along the lines of "The number of connections you have selected is above the suggested limit (##) for your selected bandwidth. Proceed? (Y/N)"

Smilin' Joe Fission April 24th, 2002 05:23 PM

Re: connection limit suggestion
 
Quote:

Originally posted by Cornholio
I can hear the followup "workaround" suggestions already... "Why don't you just switch your connection type to T3, then you can have as many as you want." I don't want to.
Then don't. What I've found works is you can switch to T3, jack up the number of connections and then switch back. When you switch back, LimeWire doesn't automatically scale back the number of connections. It works for me at least. I have a DSL connection (although I get near T1 service) and I'm unsatisfied with the measely 6 connections I'm allowed either. So I switched my connection type to a T3, jacked up my number of connections to 20, and changed my connection type back to DSL. My number of connections stays at 20 even after shutting down and restarting LimeWire. The only time it changes is when I manually change it... but then I just change the connection type back to T3 and jack up the number of connections again. (BTW, I'm using 2.3.3 Pro.)

I know... in a perfect world, we shouldn't have to use loopholes to get the performance we want. This is why I agree that we should have the option of setting the number of connections ourselves. I'm just letting you know that you're not stuck with misrepresenting your connection type if you want to manually jack up your max connections.

Taliban April 25th, 2002 05:13 AM

You can expect the connection limit to be enforced much more strictly in future versions, since people with lot's of Ultrapeer connections can reduce the overall Gnutella performance, while only marginally improving their own search results. - I doubt you will have more than 25% more search results with 20 connections, than with let's say 6.

You can imagine it like that. There are 16 ultrapeers, A1 to A4, B1 to B4, ... , D1 to D4. A1 to A4 and B1 to B4 [...] are connected to each other directly, so being connected to e.g. A1 and A4 at the same time will not increase your search horizon. With three connections the mathematical probability to have _one_ useless connection is ~60%, with six connections the probability will be 80% that you have _three_ useless connections.

That's why increasing your connections does only hurt the network.

Smilin' Joe Fission April 25th, 2002 01:54 PM

Quote:

Originally posted by Taliban
You can expect the connection limit to be enforced much more strictly in future versions, since people with lot's of Ultrapeer connections can reduce the overall Gnutella performance, while only marginally improving their own search results.
Unfortunately, that only means I will be forced to misrepresent my connection speed. It's not going to stop me from putting in as many connections as I think my system can handle... with a strong emphasis on what *I* think my system can handle... not what Limewire thinks my system can handle.

Quote:

- I doubt you will have more than 25% more search results with 20 connections, than with let's say 6.
After experiencing the results of both scenarios, I seriously beg to differ.

Quote:

You can imagine it like that. There are 16 ultrapeers, A1 to A4, B1 to B4, ... , D1 to D4. A1 to A4 and B1 to B4 [...] are connected to each other directly, so being connected to e.g. A1 and A4 at the same time will not increase your search horizon. With three connections the mathematical probability to have _one_ useless connection is ~60%, with six connections the probability will be 80% that you have _three_ useless connections.
That may be true, but it still works for me... and besides the scenario you describe doesn't happen all the time. Not only that, the same scenario can happen with 6 connections as well, so by jacking my connections up to 20, one might argue that I'm increasing the probability that I will have fewer redundant connections.

Quote:

That's why increasing your connections does only hurt the network.
I don't think so. I am only taking part on the network as a leaf node... I am never an ultrapeer. I have no incoming connections of my own, so please describe how I'm hurting the network.

I see it quite the opposite. By connecting to many more ultrapeers, I am exposing my shared library to a larger audience.

Not only this, but I have often wondered what makes 6 connections the optimum number of connections for a DSL internet connection? Did the LimeWire devs do a bunch of tests to determine that 6 connections yielded the best results for most DSL users? How do we know that the max number of connections for DSL shouldn't be 8 or 10 or more? And since it appears that DSL speeds vary from ISP to ISP, why do ALL DSL users have to be lumped in together in one group? I have a DSL connection that seems to me to be on par with a T1, and if I didn't use the loopholes to my advantage, I'd still be stuck with only 6 connections because it's still a DSL connection.

You know what I think? I think some LimeWire dev picked a magic number out of the air (or magic fairies gave him a number in his sleep... one of the two) and that's the number that was used.

Cornholio April 25th, 2002 02:53 PM

I wholeheartedly agree with SJF's post. However, I think that instead of the limit being some magic number somebody pulled out of their rectum, I believe the limits are leftovers from the pre-ultrapeer days (when each connection used a LOT more bandwidth).

I also get far more results by adding more connections (although not in a 1-1 ratio... 150 connections doesn't give me 15x the results of 10 connections, but it does give a hell of a lot more).

I think the Limewire folks should not try to dictate how many connections the users maintain and instead leave that up to us (maybe make it an advanced option or something we can edit in a config file?)

BenGreen September 26th, 2002 09:24 PM

Connection limits
 
I cannot agree with Limewires implimentation of connection limits within LimeWire. I have tested searches with only 6 connections and also increasing to 20. Whay I found was that 20 produced up to 250 more hits per search. I cannot understand why LimeWire felt they needed to produce "cripple ware" to it's users. I really have supported LimeWire in the past due to it's great coding, but now I believe I will take the link off my website until I see it changed back!

Blackbelt September 27th, 2002 12:59 AM

Well, then you can take your link from your site forever. Expect LimeWire to reduce the number of allowed connections even further, soon.

Joe Cuervo September 27th, 2002 01:10 PM

Re: connection limit suggestion
 
Quote:

Originally posted by Cornholio
Get rid of it!!! It is ABSURD to be on a T1 and to be able to maintain only 10 connections (especially with the new ultrapeer code).

Much better: Get rid of the slider method of setting the bandwidth. My bandwidth simply doesn't fit into either the "modem" or "DSL" and this makes the slider absolutely useless to me. The highest "modem" setting is too low and the lowest "DSL" setting is too high.

BenGreen September 27th, 2002 03:08 PM

Connection limits
 
I seriously believe that Limewire doesn't even think of reading these posts.. I find myself wondering why I would even write anything here anyway. If they did take these posts seriously they would do away with the connection limits altogether!
Do that LimeWire and I will plunk down the cash via PayPal instead of looking for a different front end like I did last night.

Unregistered October 2nd, 2002 12:57 AM

Dude.. you guys don't understand how the network work at all. If you jag up the connection number as a leaf node. You get a bigger footprint on the network by displacing other leaf nodes. So, you ended up with more search results yourself by reducing the total network size.

For example, lets say the total network size is 8 and you can only search result 1 up and 1 down. So, if you come in as slot 4, you see results from 3 and 5. Search results come from 2 nodes out of 8 unique leaf node. Let's say if you are unsatified with the result and jag up your connection to 2. Now you occupied slot 4 and 6 now. Search results come from 4 nodes out of 7. You increase your search results by shrinking the total network size. Let's say if you are still unsatified with the result and jag up your connection to 8. Guess what, you are the network and you can get search results by just opening your harddrive.

Of course, this assumption don't hold true if the network is fragmented. This assumption also don't hold true if there are more ultrapeers nodes than leaf nodes. (Since there are people complain about connections can't stay up, I think this is not true anymore)

Anyway, I have to agree with limewire here.

To get good search results as a leaf node, you have to hook up with a good ultrapeer node (One that has a lot of leaf nodes). That means a ultrapeer node that stay around for a long time. You can't tell which one is good unless you-- yourself stay up for a while and let's the bad ultrapeer node switch out themselves.

In terms of search results, gnucleus seems to do a better job than limewire but they use up more bandwidth.


All times are GMT -7. The time now is 06:23 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
SEO by vBSEO 3.6.0 ©2011, Crawlability, Inc.

Copyright © 2020 Gnutella Forums.
All Rights Reserved.