> It's just a can of worms to require some proprietary binary that people > have to use, trust, and believe is unhackable.
The SSL connectivity part would be reasonably unhackable. (I.e. if you happened to have a supercomputer to hand to decode the signal you would probably want to use it for your program instead!) Reverse-engineering the binary itself to then make your own client is still a risk, but is a specialist skill beyond most go programmers. > And remember, pulling > your network cable from the wall is an unstoppable hack. There could be a definition of reasonable net lag (e.g. max of 6 seconds for any one move, and max average of 2 seconds per move across the whole game). Anyone playing with their network cables is then more likely to do more harm than good to their clock. (This also limits the benefit of making your own client binary.) The server could also run traceroute before and during the game to get a fair idea of what is reasonable net lag for that particular client. Darren -- Darren Cook, Software Researcher/Developer http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic open source dictionary/semantic network) http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) _______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
