Whenever Limewire connects to a Gnucleus untrapeer, I notice two things. The connection is tenacious, and it gives me access to about five other hosts--compared to hundreds through any other software. Eventually, Gnucleus takes a sizable percentage of my ultrapeer connections. Hits drop dramatically. I now am in the habit of breaking a Gnucleus connection as soon as it appears.

Now this program may serve its users well as a downloading program, but integrated into the network it is really a drain on the rest of us.

isn't that what it should do?
reduced hits is a good thing on a 56K connection, what are you complaining about?
the "hits" are being handled by the ultrapeer that you are connected to, if you are a leaf node that is
you shouldn't be a ultrapeer if you are on a 56K connection
however, you should be sharing about the same amount of files with or without ultrapeers, in the number of uploads per day I mean

1) I have DSL, not 56K. I have no idea where you got that idea.

2) "Hits" I am using to describe how many items appear in a search window. I am not sure how you are using the term.

3) While the horizon numbers in Limewire are not necessarily accurate, if I notice that the number of available hosts is small relative to the number of connections, then it is because two or three Gnucleus ultrapeers are connected. If I make an effort to weed them out, hosts increase and hits increase, and thus my chances of getting a download. The I/O statistics are another indication. Gnucleus hangs on like a pitbull, but a Gnucleus ultrapeer brings me very little in terms of download potential.

[1) I have DSL, not 56K. I have no idea where you got that idea.]
I think he misunderstood you, see 2).

[2) "Hits" I am using to describe how many items appear in a search window. I am not sure how you are using the term.]
I think he referred to the term 'query hits'; where it is indeed a good thing for child/normal nodes to have a low query throughput.

[3) While the horizon numbers in Limewire are not necessarily accurate,...]
*grin* they are nowhere never accurate, I think.

[...if I notice that the number of available hosts is small relative to the number of connections, then it is because two or three Gnucleus ultrapeers are connected. If I make an effort to weed them out, hosts increase and hits increase, and thus my chances of getting a download.]
Well, I usually have one to two (sometimes three) Gnucleus Ultrapeers, and I am very satisfied with my downloads/uploads.
Also I took a look at downloading (I mean downloading from me) clients and I found them to be relative broadly distributed, according to 'market shares'.

But I have to say that I haven't made any statistical worthy notes - it would be surely helpful if you can investigate a little further, as no Gnucleus user wants such a bug (if it is) to persist.

Well, a new gnucleus version also came out featuring a rewritten ultrapeer part. Eventually the mentioned behaviour is already solved.

If you think this persists you can also take a look to [gnucleus.com], there's also a forum.

Greetings...

Thanks for clearing this up. Hits can mean two things uploads/downloads, I thought you meant hits on your shared files. As for DSL, you didnt say in your post so I read your mind. Must have been someone else I read.
I think that Swabby is doing a good job of keeping up with all the new improvements, so give him a chance and as new versions come out you should see things improve.
It is nice to know that most gnucleus users upgrade when stable versions are available.
Basicly you are complaining that when you use LW but get connected to a lot of gnucleus ultrapeers, it seems that you don't get as many search hit returns back and thus your life isn't complete.
Can you tell what version of gnucleus you mostly connect to? Is there any chance you connect to a university network and that is limiting your "hits". Meaning is the first numbers of the IP for these ultrapeers close to the same?

The Gnucleus "ultrapeers" that you are droping should not be ultrapeers. I run into them all the time. the problem is they have a dsl connection and meet the other requirements to be an ultrapeer but they don't look at the preferences and change minnium and maximumn connections to a higher number. So they don't connect to more peers and they become sitting ducks that everyone hates. Most Gnucleus users don't know about being a good user. Though some Gnucleus Ultrapeers have many connections, I for one use Gnucleus and I like MOST Limewire Ultrapeers, some are like the Gnucleus ones but they generaly host more people. The whole network needs to read a letter/ message telling them how to be a good user and what to do to be a good user on their Gnutella client. Morpheus caused the problem and they are doing nothing to solve it. What I mean by that is that allot of Morpheus users have gotten mad at the software and found out that it is a clone of Gnucleus and downloaded Gnucleus and are trying to use it, but their intellagence level of the software limmits their ability to comprehend that they are making people mad.

1.8.2 and 1.8.3. Checking a few of the IP's yielded common providers (Roadrunner, AOL, etc.), not universities. Whether it is the users or the software itself, face it. Gnucleus as it is now makes a lousy ultrapeer. I'm sure the developers are charming people and kind to animals, but if they could keep the pitbull tenacity AND increase the number of hosts, then everyone would be happy.

I'm currently collecting some statistical data for gnucleus ultrapeers. As it seems your horizon is smaller than with LimeWire ultrapeers, - although you can do some funny things with gnucleus ultrapeers you can't do with LimeWire.

Since Gnucleus ultrapeers don't seem to pass on many ultrapeer pongs to their leaf clients (those are used to create horizon statistics in most clients), they appear to be a lot worse than they really are.

For example you can spam Gnucleus ultrapeers with greedy queries ('mp3', 'avi', etc.) and while LimeWire ultrapeers would soon drop the connection, Gnucleus will keep on routing results for minutes (taking the ultrapeer out for the rest of its leaf clients completely).

So now BLOCKING is OK as long as you do it MANUALLY?
So it would be OK to provide blocking based on horizon but not on the client name or version number? WHY NOT?
Add blocking to Gnucleus! You had the code, and the chance to do it a long time ago, what's the problem?

So basically, given Gnucleus' superior ability to hold an ultrapeer connection compared to other client software, if it altered 1) the processing of greedy queries and 2) user alterable parameters for ultrapeers (on Limewire, you check a box or no. There is nothing more to set), then it would make a fine ultrapeer?