Filtering Redux

In a past entry, Fredrik explained what caused the “Filtered” count in the Search Window. What is more interesting to me is the why. Why do all the search windows have to get all of the search results? It has to do with the design of the NMDC protocol by Jon Hess. The $Search sends out the essential information: search terms, size limitations, and search type. The $SR (search result) likewise sends the essential information: result type, directory name, file name, size. What is missing is a way to link a given $SR to the $Search that spawned it.

So, what happens when a user does two searches? The original NMDC client would not let the user do this. It didn’t have the ability to support more than one source for a given queued download, so there were no background searches for alternates. It also did not let the user open more than one window. DC++ does both, so it can have multiple searches happening simultaneously. To make sure each place gets its search results, it broadcasts them to all open search windows as well as the download queue. The windows then display the results that match their search criteria. This is the reason that ADC’s search mechanism has a token associated with it. Each search will have a different token, and each window will pick the results matching that token, with no guessing involved.

The limitations on the NMDC search also extend to other DC clients. Clients wishing to return hits based on the contents of the files will be filtered by DC++, since its search windows expect matches in the file or directory names.

5 Responses to Filtering Redux

  1. poy says:

    could this be solved in NMDC too by adding some kind of additional support? like “TokenSearch” for instance. then the clients with “TokenSearch” in their $Supports would use a $TokenSearch and a $TSR instead of the usual search commands…

  2. Your solution addresses part of the issue. The first part that would have to be solved would be to get hubs to accept a change in $Search syntax. The second would be for clients to accept it, and send back appropriate results. Your solution only covers part of the last half. Unfortunately, it’s not workable. $SRs are sent back as a single UDP packet, so the clients do not connect using TCP, which is where the client-client handshake is used and $Supports is issued.

  3. Pingback: DC++: Just These Guys, Ya Know? » Blog Archive » ADC!

  4. Pingback: Search the active ADC and the passive NMDC protocol « DC++: Just These Guys, Ya Know?

  5. Pingback: ADC Search Types « DC++: Just These Guys, Ya Know?

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: