一次关于游戏服务器底层通信架构的重构过程

从昨晚七点，到今天上午11点，先后对大厅和房间服务器进行了重构，重构后的代码结构清晰了，效率也提高了，觉得这次的重构过程很有意义，所以记录下来以备查。

在原有的大厅服务器中，原有的设计是使用统一的一个TUSER对象管理底层数据的接收以及高层对TUSER进行的逻辑层的属性读写操作，不管是玩家 正常连接的SOCKET还是用于临时通信的SOCKET，只要有连接都会分配一个TUSER对象。而在TUSER对象中，又都包含大致这两方面的信息：一 方面的信息是用于底层数据通信的，比如接收缓冲区数组，接收缓冲区大小等属性；而另一方面的信息则是逻辑层的玩家对象定义，包括：玩家账号、性别、年龄等 属性。在原有的设计中，没有将这两个方面的信息进行进一步的划分，而是统一放在了一个TUSER里面。这样作，就存在一个问题，对于一些非正常玩家的连 接，比如玩家注册或者是其它服务器与该服务器通信用的SOCKET，只要有连接，就要建立TUSER对象（因为TUSER里面有接收数据缓冲区，而所有的 数据通信必须要用各自的缓冲区来作），这样TUSER对象的一些玩家属性就没有利用起来，从而导致浪费了大量的内存空间。

新的结构中，将TUSER对象一分为二，将其中有关底层通信的数据和方法分离出来，形成一个新的对象：TCONN，TCONN专门用来处理各玩家的 底层通信数据和维护各玩家自己的接收缓冲区，在SOCKET的RECV里，将根据TCONN以及接收到的新数据形成一个个的逻辑数据包提交给更高层的逻辑 来处理，而在其后的高层逻辑中就包含对TUSER对象的维护。这样一来，当TCONN分离出来的数据包，是要求对TUSER对象进行维护时，就在高一层的 逻辑里维护TUSER，而当TCONN分离出来的数据包是要求对TABLE或其它对象进行维护时，就不用再搭载上TUSER对象。也就是说，TUSER对 象的生与死，是完全按照高层逻辑在走，而不是按照网络连接和断开来走，这样分出来的两个对象应该是较好地区分了网络底层与游戏逻辑两个方面，使其彼此可以 基本脱离，具有更好的扩展性和无关性。

进行了此项重构后，无意中解决了这样一个BUG：用户从桌子退出时有时无法在房间里更改状态的问题。