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.