whatever dude, I get more results with 12 hosts opposed to 3, so ..

I hope this doesn't offend anyone. But I wish we could have a feature, or way to hack the config files to allow us to make not 12 connections, not 20 but 100.

When I used to use older versions of limewire with 100 connections (even before ultrapeer) I successfully connected to 1000 to 1500 TeraBytes. Now days with the limit of 12, I am lucky to get 1-2 TeraBytes of available Data/Files in my statistics window.

Its a lot harder to find anything now. (I use 45Meg DS3 so modem and T1 users cannot get the number of connections I just wrote about above.)

Does any one know if there any chance we can edit something to try out larger connection amounts than the 12 limit? (I personally have found that my CPU MAXes long before my Internet connection does, so I know I can use higher connection numbers.)

Yes. There is someone who knows and there is also a chance to edit something to try out larger connection amounts.

If every user had 100 ultrapeer connections or if every user had 3 ultrapeer connections would not change the individual search horizon (in theory at least, in the real world the network would collapse in a second). Now if most people have 3 connections and some have 100 connections those with many connections would have a much bigger search horizon reducing the search horizon of all others. - That's why I as a responsible person, am not going to tell how to do it.

However, I will give you a hint, - the answer is in the source code (only some 140.000 lines of code - to discourage you as much as possible).

more than 12 hosts is a simple modification to a java file, I already did it, but its for a really ancient version of limewire (6/2002), if someone can point me to the latest source code (the latest zip on www.limewire.org is from 6/2002 I'd be more than happy to make the hack and release it.

There are no zips any more.

By the way, the next version introduces GUESS. GUESS is a search architecture that doesn't broadcast your queries via tcp anymore but searches (via udp one ultrapeer at a time) for up to 200 results and then stops the querying.

More tcp connections won't help either.

I think I'll stick with the non-guess version, only 200 results sounds kinda lame..

only 200? ffs. The idea behind GUESS as I understand it is that it searches until it has some results for you. A rare file will be searched for longer and over a wider area, until you get results. This will be possible because very common files are limited to 200 results, saving bandwidth that can be used to search farther for rare files.

This means you have a much better chance of finding a rare song, and when you search for a common song you are limited to 200 results. How many do you need?

It may require a slight change in your searching patterns. Instead of searching for "Beethoven" you would search for "Beethoven - für Elise" This way, instead of 3000 results for all things beethoven, you get 200 for the song you wanted, which should be plenty.

I would suggest you upgrade when GUESS comes out. Unless you only like totally mainstream stuff and want 3000 results for a britney spears search. GUESS will help you find specific files much easier, and will help the network overall.

You have to edit more than one file to have more connections, but having 100 ultrapeer connections would be lame. It might help you, but would not be nice for the network. With enough people doing that it would really gum things up.

Okay, here is the latest from LimeWire development versions: The number of results when GUESSing has been set to 250 actually not 200 as I said before. However GUESS is complete yet and it might be changed.

The number of results next-gen ultrapeers return when being queried has been set to 150 at the moment. The number of ultrapeer connections for leafs will be set to 2 by default.

The number of leafs for ultrapeers has been reduced to 40, the number of ultrapeer connections for ultrapeers have been increased to 47.

I've been seeing that. Been going through the new code. Interesting that ultrapeers connect to more ultrapeers than leaves. I am bettting there are far more leaves, it seems like this would make it harder for them to connect..

Though if each leaf connects to fewer ultrapeers, it might balance out. bleh. Seems a bit shoddy though. When you first start, if you are a leaf, it limits you to 2 connections. Once you have two connections though, you can set it to something higher (as long as i's not higher than the max # of connections for your speed. Speaking of that, what good is max # of connections for your speed for anyway?)

There is nothing stopping you from setting it to a higher number once LW has started..

the reason for the more ultrapeer<-->ultrapeer connections and the less leaf<-->ultrapeer connections are because of the amount of traffic and flow-control algorithms of various gnutella clients...

if a leaf has many ultrapeers and sends a message (that lasts for 7 hops) to those ultrapeers, who then forward it to a few ultrapeers and their many leaves, who then forward it to a few more ultrapeers and their many leaves, (repeat 4 moretimes), chances are that sometime along the way, a client is going to 'drop' this message because its handling too much traffic. therefore, it actually lowers the amount of hits you're going to get for that file.

if a leaf has a few ultrapeers connections and sends a message (which now lasts for 4 hops) to those ultrapeers, who then forwards it to many many ultrapeers and their few leaves, who then forwards it to many many ultrapeers and their few leaves (repeat 1 more time), there is a much lower chance that a client is going to lose the message among the traffic.

this also opens the door for allowing one to 'probe' for queries, by first sending a short-lived message and letting it go to the much larger range and seeing if results come back -- if none, or not many, do, then it sends a longer-lived message, reaching further out into the network.

and to help reduce the traffic even further, QRT messages(essentially filters) are forwarded between ultrapeers now (although only checked on the last hop) instead of just from leaves to ultrapeers, ensuring that ultrapeers won't needlessly send message to the many other ultrapeers.

basically, it's a good thing the way it is.