以前编写过一个Android跳棋对战的程序,
服务器端用的 RESTfull, 有game, user, room 等这些resources
客户端是不断轮询resources,而后不断对比,得知游戏状态的变化,当时时间有限,也就没有探索更好的方法
有一天跟一个资深同事说了这事,他说:你就长连接去等就行了。
对呀,状态变化我再给 client 回消息,这节约了cpu, 但服务器端就要做更多的工作
1)请求来的时候,我要hold住
2)等另一玩家完成了,再给hold住的玩家回消息
最近阅读了一篇文章也说的是这个道理
http://blog.csdn.net/shanliangliuxing/article/details/7755300
要让client知道 server 的变化
1)可以轮询 (comet的一种方式)
2)可以用长连接,并在server 端做手脚(comet 的另一种方式)
随着 html5的成熟, websocket 将取代 comet 了,我猜想其实现方式
是否它要在client端开一个监听端口,这样就可以实现多对多的双向通行
看来不是这样,下面有个很好的学习文档
http://www.oseye.net/user/kevin/blog/79
websocket 是在browser 端,和 server 端的扩展
browser 支持websocket表现在不用每次都去connect, 只用connect 一次,而后server 有的事件会触发 onmessage 函数,所有browser的js编程大大简化了。
服务器端以前处理长连接要 hold住, 有了server 端的框架也不例外,只是有了可复用的http server 扩展(比如jetty的websocket 扩展)使用更方便
1) 一般有 onConnect() onDisconnect , onMessage ,在其中处理
2) 如果不能立即给client回复信息,但有session对象保存会话,等就绪的时候再 session.getRemote() 回复消息。(当然在回复消息前,client用长连接在等消息,消息到来触发client的onMessage)
所以我的跳棋程序可以改为,在开始游戏的时候,依然使用Restful 浏览房间和游戏列表,开始游戏后,就使用 websocket 方式。
由于是android程序,当然我就需要一个java 的 websocket client 而不是 browser 中的 java script websocket
java 的 websocket 的 example
http://www.eclipse.org/jetty/documentation/current/jetty-websocket-client-api.html