That is why I've proposed doing a dual protocol arrangement. That way, the existing users can transfer to the newer system as convenient. They can select either a hardened WPN, the new one, or both. And you might be able to use the update broadcast feature to request that those who get the message to download OurMX. If you want to broaden the user base or at least hits more, you could even add G2 support (if you can create a version that follows the rules but adds sanity). But make sure the user can decide what their copy supports.
When you get a new protocol, you might want to ask for what versions and clients are supported by whatever peer/host. So if someone connects to the old one using the new one and finds those with the new one, then they are to communicate with them using solely the new protocol. (Same if you pick up a OMX user using G2.)
The thing to do with the TCP management is use a stateless approach. For instance, there is the "TCP cookies" approach where the address of the other guy is included in the time stamp. So no memory is used during the handshake in the event of junk TCP packets. This makes a minor but compatible change to the TCP protocol that will work regardless of whether the other party does it too. So you encode their IP in the timestamp or unique identifier to where when they return it to you, you can see that the 2 match, and do so using logic rather than memory (the ID *is* the memory).
Now, I already gave a way to tell that fake results are being sent. What you do is to have the UI, not just the protocol, do post result processing to see if what is returned is valid and meets the search criteria in any way. If not, it never goes into the results buffer. So similar to the TCP cookie approach, the goal is to make things as stateless as possible. You don't commit memory for anything unless you know it is valid. So this change will allow the original client to handle the garbage without crashing (though it will take quite a CPU hit). The old client committed everything to memory and had no sanity checks to see if any of it was what was being searched. It puts the sole duty for searching on the OTHER machine and blinding trusting the data. But my approach is to search within the results immediately and only accept what is valid. And if you want to rule out fake file generating clients some, you send the search out to the network with a letter or 2 missing and THEN apply the original search to the results. So anything that was dynamically created, assuming you search for literal strings (and not an OR search), would tell on itself. So you might search for "Britney Spears", the protocol sends out "Britney Spea," and the UI or other code checks to see what comes in is "Britney Spears" before adding it to the results buffer. The dynamic fake makers won't know you are actually searching for "Britney Spears," and thus they send out the truncated results. But I just found one problem with that exact example. There might be a real file called "Britney Speach" or another celebrity named "Britney Spearhead." While that is not what you are looking for and should not be returned, you don't want to eject clients that truly actually contain other files with similar names. (If you use the intelligence of another client sending bad results to eject them for that session, then you only want to eject those that return shorter results than the original, not the same or longer. And if you want to keep an ejection list, keep it small, like the last 10 ejected IPs or something -- remember the principle of "as stateless as possible").
I agree that you don't want to publish specs for an immature protocol.
