Wow. I really dig this idea of sharded / modular network problem solvers. It would be interesting to take it a step further and let the solvers themselves negotiate their own distribution over time, CPU use, etc. - e.g. replicate all the active solvers on all the clients but allocate chunks of variable size to each depending on which evolves to be the "dominant" solver on any given CPU. You'd need an algorithm to stop Montecarlos from becoming the dominant process everywhere, probably. Montecarlo is notorious for chewing up a processor, but in various applications it often does not need to be run constantly, so the free cycles could be used for something else.

I especially like the idea that this could be applied to anything, not just Go. I did something in this direction a few years ago with an a-life data processing platform that used SOAP to shard problems to groups of machines.

At that point there are two issues, firstly the protocol becomes a bottleneck if you're dealing in large datasets, and secondly if you're dividing something up spatially you still have to aggregate your results. It would be the same if you divided it problematically for Go moves, unless each algorithm could give a "confidence" indicator that could be used reliably so that the master engine would not have to montecarlo each result set. That could be done if the montecarlo was moved to the sub-servers to test their own moves before sending the moves back complete with percentage wins for direct comparison in the master engine. It would chew up a lot more cycles and mean more machines, but it would remove the post-processing bottleneck.