I have the following local address being reported to me: 127.0.0.1
I wonder, is this normal? My connections are being refused from the other side and I'm not allowed to connect with peers (or Ultrapeers).
Tell me, the above address (127.0.0.1) is being reported to other clients as well? I remember that Limewire, Gnucleus and others filter the local connections out, including 127.0.0.loopback. I conjecture that my connection problems is related to the address thing, ¿What do you think?

Well,well,well my friends. What I am seeing, now... Somehow my address changed and suddenly I am connecting like crazy. I don't know how it happened, but it happened. I must say that, as I thought, I'm getting a very good impression, a very good impression of Phex indeed.
I switched kernels, however. From 2.4 to 2.6; actually replaced my entire system since I last got "the error". This issue, I think, should be investigated further still.

The reported address 127.0.0.1 is not a problem.
Phex determines it's correct address from every new connection its making. So even if you switch IPs Phex will recognize and update it address.
127.0.0.1 is only reported since Phex didnt know any better and you have'nt connected yet.
Phex will not report loopback or any other local network addresses to other peers.

Your initial connection problem might be related to a outdated host file. In this case Phex will need some time to determine fresh addresses and connect. You can help by pressing the GWebCache button.
When you run Phex regularly every couple of days you will connect very fast. Phex will prioritize peers by its connection probability and improve its host cache while its running.

Gregor

__________________

Sounds good. But there's something else that could prevent me from using Phex: I need to return directories coincidences; say that someone search for ...**EDITED**. Suppose that I have no file that match with that string, but I have one or two *directories* that do. So I would like the files "inside" (**EDITED**/) to be returned in response to this query. (Not that I have any **EDITED** songs, I clarify to RIAA hitmen)

It's very unpractical for me, for a number of reasons, to rename my files. However, looking at the share screen, the search count, I wonder if this is or isn't implemented already.

Searches for **EDITED** should return hits if any of the directories above your files or your file contain the words **EDITED** and **EDITED**.
Maybe you are seeing less hits because the query routing tables do not contain directory string entries. I will check this.

Gregor

__________________

Thank you for your swift contestations, Gregor. You have been most helpful with my problems that aren't such.

I am lost, a little with your explanation, because I'm not in the computing thing, at all... I don't think I really get it when you say "routing tables" (not in a profound sense ). But in response to a query like this:
"**EDITED**"
this should (should?) be answered by Phex:
"03.mp3"
.. with no problem because at least in the beta I am, after all, getting hits. (No need, I think, to swim in the code) -Little or no downloads maybe but that is a different story. I'll bother you with two more questions, I hope they will be the last ones.

¿What can you tell me about this?:

"**EDITED**/The best of/03.mp3"
In Gnucleus, I used to get from my part this kind of finding. Notice that there's a relative route there. But that route, where does it come from? Was it added from my client's side? It came along with a search? Anyway, it's practical to have it there, be as it may.

The other thing is that I have a lot of "Ignored candidates" when I'm downloading a file. Their addresses are **edited**, **edited**, etc. Local network addresses, I believe. And they usually are Limewire peers. ¿What's this?

No problem.. if I have time I enjoy to help..

The routing table is basically a condensed table containing all your shared files (I checked, its including your directories). This table is send to your neighbours so they can decide if queries should be forwarded to you since they could generate hits or if its not worth to waste the bandwidth since you might not have anything.

You should definitely use the beta of Phex!

When somebody searches for **edited** and you share it at **edited**/The best of/03.mp3, Phex will only return 03.mp3 currently.. there will be a path addition in the future.
If you search for **edited** and somebody else returns **edited**/The best of/03.mp3, Phex will display you the whole path. But AFAIK there are not many cases you will see a client returning path info. Maybe Gnucleus is using a proprietary extension instead of Gnutella standard.

Ignored download candidates are peers, which you might not be able to reach now and in the future. This can be out of various reasons. Ignored candidates are hold in memory till shutdown. Its a common way to reduce needless retries, but usually not displayed to the user.
Some of the reasons a candidate might get ignored:
- You and the candidate is firewalled and transfers will never succeed
- You are not firewalled but the other peer but you couldn't find a route back to the firewalled peer to start the download.
- Phex tried a couple of times to connect to that client but always failed and it just gives up.
- The peer reports you it will not let you download because it doesn’t like the Gnutella network.

Private addresses usually get ignored very fast, you either have only a very small chance to connect or no chance at all in case you are firewalled.

Hope it could cleared a few things for you and didn't confuse even more ;-)
Gregor

__________________

Clear as water, Gregor. Thank-you.