eric wrote:

There is a little flaw in your demonstration. You have assumed when a client searches for "a b c d", this means "a" & "b" & "c" & "d" but it is wrong.  

Matching all of the substrings is the way Jon Hess coded the original client, how can that somehow be an incorrect assumption?

Speaking about probability, a.*b.*c.*d is probably what the user wants the most. For example, if a user searches for an album, he won't spend time to write the album title in the reverse order. That's why most of the time, "a b  

What's wrong with supporting out of order matching of search strings?  Some users do use it - I'm one.

optimizing something is good but optimizing something which is limited is IMHO just a waste of time.

Using Gnutella's QRP model will limit the number of users that a hub has to broadcast to.  Hub bandwidth, not CPU power, is the limiting factor, so I don't think that you should have dismissed cologic's suggested optimizations that easily.

- Todd