离开R-Tank

9 月 22 日了,记得去年年末的时候,我们开始了 R-tank 项目,经过两次的重构,并尝试了三种不同的实现方式,即使这个项目最终未能吸引很多人的注意,但也积累了不少的经验。

由于一直以来都是独立开发,所以并没有在博客上写起关于 R-tank 项目的细节。R-Tank 项目其实是由 Lu 学长发起的以 WIFI 远程控制为基础的智能玩具项目。想法其实在国外已经有实现了,不过在去年的国内,还是一个很新奇的想法。于是,我们(LuDa、WeiJianwen、GuoZiyi等)开始了这个项目的构建。

看着以前简陋的草图还觉得挺好笑的:

架构草图

不过可以体现出我还是很努力地尝试把这个项目构建好。上图中的所有线表示一个 TCP 连接或者内部调用,可惜当时没分清,所以都用实线了。这幅图应该是最后一次维护的时候画的,已经从 UDP 转移到 TCP 来管理连接。

简要地说明一下,NetBase 类是一个抽象的基类,负责提供一个消息传达者的作用,维护一个。里面有 3 个方法,分别是发送往第几个客户端的。然后交给子类来实现不同的网络操作。这样看上去的架构还是挺完善的,不过,可惜的是,不一致的网络消息发送导致维护成本的提高,以及用 TCP 导致广播消息的困难,都是这个项目的挑战;另一方面,消息协议的确定也是一个难题,如何同步游戏中各种数据也是一个难题。


一些小插曲:

  • 一开始的 UDP 本来也可以很好地工作,不过要耗掉很多电量用于同步。而用 UDP 实现注意的问题或许就在于同步信息的时机:不能频繁发送,也不能只发送一次。
  • TCP 与 UDP 论战,最后由于不了解 UDP 如何“不可靠”。于是,放弃 UDP 采用 TCP 。并用测试连接来确定网内的其他客户端。确实获得了更好的连接效率。
  • 有点错误地用 Java NIO 来实现 TCP 连接。而不阻塞的 IO 对于无状态网络服务来说应该是可用的,但不是所有的网络服务都是无状态的。而且,NIO 强调数据的可控制性,大量应用 Buffer 类,是否完成是不确定(因为不阻塞),所以考虑情况很多。导致这个项目在这个阶段耗费了大量时间。
  • 确定 NetBase 类的稳定 API 。采用原始 Java Socket 进行最后实现。