对客户端/服务端开发的随想

      从某种意义上来看，可以把所有客户端/服务端程序理解成远程数据同步程序。抛开各不相同的业务逻辑，它们总是把某些数据从客户端同步到服务端，或者从服务端同步到客户端并显示出来。比如你用QQ发了一个群消息。则消息这个数据从客户端同步到服务端，然后同步到该群所有的客户端，最终显示给这些用户查看。所以如果有一个“万能同步机制（同步且只同步需要同步的）”，客户端/服务端程序员的工作就轻松多了（于是这些倒霉蛋都被Fire了）。
      但是不幸(or幸运？不用被解雇还可以拉上人成立项目组）的是，我们没有可用的“万能数据同步机制”，所以同步方式还是要靠自己设计，常用同步方式有：
      1）将计算逻辑集中在服务端，客户端发消息请求，服务端计算后用消息通知客户端计算结果。这种方式的优点是实现简单，很容易实现客户端间的一致，缺点是有时逼着客户端一定要转圈圈（就是loading，等待服务端返回结果）。
    2）将计算逻辑集中在客户端，用消息通知服务端计算结果，服务器再周知其他客户端。这种方式适用于p2p，一般不适合普通CS程序，但有时也用来统计一些不那么重要的信息。
    3）将计算逻辑提取出来，客户端和服务端都进行计算，用消息传递的是事件，而不是计算结果。这种方法主要是实现起来麻烦——要有一个取消机制，当服务器告诉客户端某个事件不能生效时，可以正确的回退。这么说好像很玄幻，但回想下使用qq发消息，一按发送就显示在消息框中，但可能过了一段时间，告诉你那条消息发送失败；又比如网游中常出现的月光宝盒事件——角色突然又回到几秒前的位置。
    由于2比较适用于p2p的场景，所以我们一般设计通信协议的时候，是在1和3中做取舍。如果确实需要用户等待（比如登录，还有各种转圈圈不会让用户觉得不爽的场合），那么使用1比较合适，其他场合使用3用户体验比较好，因为操作可以立即生效。但就像没有万能同步机制一样，也没有万能取消机制。如何处理服务端判定为失败的事件，又是需要好好设计了。不过也别想得太复杂了，很多时候只要根据服务端的计算结果再刷新一次就ok了。