Hi there:

I tried phex 0.9.5.67 in a LAN environment with all nodes forced to Ultrapeers, but the searching process is much different from early versions of phex. I think that is due to the DynamicSearchEngine, and I want to use the GUI of version 0.9.5.67 but without dynamic search. My question is where I need to modify the source code to replace dynamic search with original search method. Any feedbacks are much appreciated!

no chance

Unless you are maybe skilled Java programmer and have deep knowleadge about Gnutella network topology.

Dynamic searching goes very deep down into the core implementation and influences the whole handshaking and network communication process.

The other question is why is dynamic search so bad in your LAN environment? What can be done to give you a better experience in a LAN?

Do you have any ideas?

__________________

For example, I use three nodes (all forced to be ultrapeer) to form a line topology like this:
A--->B<---C
If I fire a search request from node A (of cource I know some keywords of files in node C), and at node B, the search request can be seen in the search monitor tab, but fail to be found at node C.

I replaced sendDynamicQuery in sendMyQuery with directly forwarding query to ultrapeers and leaves, such as:

if ( HostManager.getInstance().isUltrapeer() )
{
/*return sendDynamicQuery( queryMsg,
DynamicQueryConstants.DESIRED_ULTRAPEER_RESULTS );*/

// only forward to ultrapeers if I'm not a leaf.
if ( queryMsg.getHeader().getTTL() > 0 )
{
msgMgr.forwardQueryToUltrapeers( queryMsg, null );
msgMgr.forwardQueryToLeaves(queryMsg, null);
return null;
}
}

At this time, node C can receive the search request, but node A fail to receive any replies. Another interesting thing is that node B can receive reply from C, but can not forward the reply to node A.
Any suggestions?

Did Phex already hash those files completely when you started the connection?

If not, try to connect them again after the shared files have been hashed. I assume QRP is active, so only those Queries which can score a hit at the other node are being forwarded. Might be a reason why it doesn't work as it should.

__________________

-> put this banner into your own signature! <-
--
Erst im Spiel lebt der Mensch.
Nur ludantaj homoj vivas.
GnuFU.net - Gnutella For Users
Draketo.de - Shortstories, Poems, Music and strange Ideas.

Yes, the shared files were hashed before the search requests reached. Furthermore, I traced into the source code and found that node C indeed returned correct query results to node B.

In case you are using dynamic query C will never see queries from A since dynamic query is first doing a network probe query with a TTL of 1. The query will only get forwarded to B and not further since the TTL ended and C is not a Leaf (Ultrapeer QRP is only aggregating Leaf QRP tables).

After doing probe queries, the standard query TTL is determined based on the probe query results, the querying is continued. But B will never see a query again since it already received the probe. Usually this is not critical since as ultrapeer you tend to hold 20 connections or more and only a few are probed.

Ok, now you worked around the dynamic query engine fine for doing queries, but you also need to get around it for query replies.
NOTE: With doing this you MUST also change the handshake to not claim you are able to do dynamic queries.

In class ConnectionEngine change the statement
if ( responseHeader.getTTL() > 0 && returnHost != Host.LOCAL_HOST &&
queryEngine != null && !queryEngine.areEnoughResultsRouted() )

to

if ( responseHeader.getTTL() > 0 && returnHost != Host.LOCAL_HOST )

This should get queries routed back without the result limit check on its way back from C to A. Since you have not used dynamic query in the first place this check can not work correctly.

At least this is my guss what could be the cause of your problems.

Gregor

__________________