Less effective, perhaps, for the average user, but in some situations more so. Even making it somewhat obfusciated would do the trick, someone needing to make peer connections would be able to but users not needing to wouldn't notice it.

There is not a single situation where 0.6 connections are more effective. Theoretically AND practically an ultrapeer connection will always return more results.

But more results isn't always good. Especially given that LimeWire can't filter ports.

An Ultrapeer connection blinds the client to the realities of possible or impossible connections. With 0.6 connections a greater percentage (still not all, but MUCH more) of the queryhits you get are from hosts that you can actually connect to, because obviously if you got the queryhit you can exchange data with that host. Funneling everything in and out via an UP means that more queryhits are returned, but most of the leaves of an average Ultrapeer are inaccesible to me. Getting queryhits bounced off of an Ultrapeer only means that both the host in question and myself can connect to the Ultrapeer. The fact that the Ultrapeer allows me to get queryhits from these hosts is of little consequence in terms of being able to access the hosts themselves, because the actual business of requests and transfers is handled directly between me and the host in question.

With a 0.6 connection, a much greater percentage of my search horizon is made up of hosts I can get to. I have fewer responses, but most of the queryhits I lose vs. an ultrapeer setup represent hosts I could not get to anyway.

In short, a Ultrapeer gives me hits from anything the Ultrapeer can connect to. In a perfect world, I would be able to connect to all of them as well. But I can't. A 0.6 connection gives a more accurate description of files available to me.

LimeWire can if you can.

WHAT??? I don't know what you mean, but I'm almost certain you got something wrong.

Not at all. A client with a 0.6 connection can return queryhits without ever being able to accept incoming connections (= being firewalled).

So you are behind a firewall and don't want to receive results from other firewalled hosts??? 0.6 connections won't help you in that case.

First, what you are saying about Ultrapeers is true for every other gnutella host two. If a host A is connected to a host B, it does NOT mean A accepts incoming connections. - But that doesn't matter, because there is the PUSH request.

That would surprise me indeed, - since the amount of firewalled users is about the same, no matter what clients they use. And you can download from any of them unless you don't accept incoming connections either.

It isn't a firewall in the traditional sense, and pushing won't help. I AM firewalled, as well, but the other problem is just a hack and slash block of gnutella traffic on the standard port.

I can connect to some hosts as would a firewalled user, but other hosts are blocked completely.

I know 0.6's work better from twice being able to get them, and observing that nearly all of the diminished quantity of returns worked. Except the normally firewalled ones, but that is understandable.

Basically, if I can connect to an Ultrapeer, and so can another host, the likelyhood is still quite low that I can connect to the other host. But I can still exchange queries and queryhits. They are just useless to me.

If, however, I connect to other hosts on 0.6, the model changes slightly. Queryhits are not always routed back to me via the host that relayed the query for me. They come straight back. Well, the don't come STRAIGHT back, but they don't get routed around my firewall. So while I can get a query OUT to a host to which I cannot connect, via my connections, that host's queryhit would be blocked, and I wouldn't have to wade through hundreds of false-positives.

For example, this situation:

File F - Whatever
Host A - me - Can connect to B, P, and U but not C
Host B - Has F - connected to P and U
Host C - Has F - connected to P and U
Peer P - Does not have F - connected to B and C
UltraPeer U - Does not have F - connected to B and C

Now, if I (A) am connected to U, then these are the relevant queries:

A->U does not have file
A->U->B returns queryhit via B->U->A
A->U->C returns queryhit via C->U->A

So A sees two responses, B and C. Only B is possible. But A doesn't know that.

Now if A is connected to P, this is the situation

A->P Does not have file
A->P->B returns queryhit via B->A (peers don't force-route returns like UPs do)
A->P->C queryhit fails via C-| |-A

So this time A sees only one response, the one from B. The one from C never made it.

Now in application there are many more C than B. A peer connection, as illustrated, would use my own filters to screen for and weed out C-type hosts from search results.

Now if I am wrong about that (which I don't think, but is possible) and queryhits can bounce off of peers and be counted as successful (which would seem to contradict the idea of ultrapeers) there is another solution for a 0.6 connection being better.

That being the extremely limited number of cases wherein ones own peers (those peers to which one is directly connected) have file F. An ultrapeer has less upload bandwidth, so if only those queryhits which originate from the peers and/or ultrapeers to which I am directly connected are valid, I am more likely to be able to connect.

Oh, and by the way, "LimeWire can if you can", could you elaborate on that?

My search results panel does not tell me the port on which a file is being shared, only the IP.

You did not really understand how gnutella works. Normal 0.6 connections route replies just like ultrapeers. (Since queryhits are sent over the already established tcp connections and not directly via udp).

C will send the queryhit to P which will forward it to you, so you'll get the queryhit anyway. The real question is, - why C could not connect to A. The only possible explanations are:
- C blocked your IP or your listening port
- YOU block C's IP
- Neither C nor YOU accept incoming connections.

Writing packet filters for LimeWire is a trivial task. I wrote part of LimeWire's IP filter and I thought about adding further powerful generic filters but the average user just would not need them anyway.

Well, I'll just tell you my situation.

My ISP is meddling with my connection. I can't connect to anyone if THEIR listening port is 6346 or 6347. I ca't even ask them what they have. I know this is my ISP, because on another ISP it works normally.

I found out that the "browse host" gives me the port of the host, and only returns results if I can get a connection to them so that has effectively become my strategy. Search a query with lots of returns, ungroup, sort by location, and go down the list browsing hosts until I get returns, then look and see if a file I want is in the list.

Reminds me of the old ftps.

Strange however, that I get many more valid connections when I can force LimeWire to connect as a peer. Perhaps I just got very lucky two out of two times, but that seems unlikely.

If you can't connect to a host because your ISP blocked the host's listening port, LimeWire will automatically try sending a PUSH request since it will assume that host is firewalled. If this host has free upload slots, it will try to open a connection to you - and if you can accept incoming connections, you won't have any problems downloading.

In case you are not accepting any incoming connections (and if you can't change that) I wouldn't use LimeWire but a gnutella client that supports HTTP or SOCKS proxy instead.