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.