对于玩家的超时管理，粒度不能太大。要做超时控制的首要原因，是socket连接太长没有发送消息的话，服务器端应该认为该玩家挂机你时间过长，将其清理出房间，关闭此socekt连接。 

这只是服务器对玩家的时间超时控制的一个比较明显的原因，在 游戏服务器中，往往会低估 一件事情的复杂程度从而呈现出过多的乐观主义。 如果考虑下在时间控制的领域内，需要 清除玩家的因素，可以分为这么几个： 

1.  在房间内挂机时间过长，换句话说就是已经连接的socket过长时间没有发送任何数据。

2.  游戏加载的过程中，如果加载的时间过长，则应关闭此连接，提示玩家重新连接。

3. 玩家要进入游戏房间前，发送预约请求包后，预约的时间超过限制，需要关闭。

4. 在踢出玩家的过程中，如果玩家的消息还没有发送完毕，需要给一个时间专门用来发送剩下的数据，超过这个时间限制后，就强行退出。

踢出玩家这一功能单元，比较好的机制是状态管理器的方式， 玩家存在不同的状态，当每个心跳，处理逻辑的时候，根据玩家的状态进行不同的处理。 在处理过程中，根据游戏的运算逻辑更改玩家的状态属性，这样便将 踢出玩家的逻辑原因 和 处理玩家的退出，包括资源清理 进行了分离， 将代码进行了解耦。 其实这是属于玩家的状态控制， 玩家在不同的状态进行不同的处理。 

在整个服务器的处理中，socket封装层专门用来处理网络连接和数据的传送， 在这一层，是和业务逻辑无关的。 业务层将数据写入已经开辟的缓冲区中，然后在心跳时，socket封装层将缓冲区中的数据进行发送。socket层数据的接收和此类似， poll或者epoll轮询后，从内核中，将tcp/ip协议中传输层里，内核缓冲区的数据进行读取，然后写入soceket封装层的读数据缓存区，然后根据自己服务器的与客户端协商的协议，对数据 进行拆分，然后交由不同的包处理逻辑 执行事件处理。

这样，在socket封装层，不应该进行过多的业务逻辑代码，否则上层业务将会和下层的封装相耦合， 在服务器逻辑 简单，或者是原型期时，缺点尚不明显，但是一旦需求开始增多 ， 业务代码的复杂度会剧烈的上升， 在初期如果功能模块分得不够清晰， 那随后想要进行解耦，将会面临 巨大的技术风险。 重构从来都是件非常痛苦的事情，原有的架构至少是解决了问题，重新做一遍，需要将整个已经解决掉的问题再重新解决一遍，做这样的事情，需要知识、经验、以及义无反顾的勇气。

所以在这个时期，我会尽肯能的将以往的经验，加入到新的项目中，不能让过去出现的错误重复的出现。 而且，也需要将已经成熟的项目经验，累积到下个项目中，这样团队的技术积累才会不断提高， 说直白点，就是

对连接的控制管理， 

对时间超时的控制，

对于服务器群组的管理和分发机制，

对于多线程的使用控制，线程间的并发控制，对死锁的控制，

对线程间通信的使用(为了提高性能使用缓冲区数据通信，特殊要求的话，要用到scocket通信)，

对于资源池的使用，

对于精妙的设计模式的运用，

对于socket层以及io复用的封装，

对于日志记录功能的更好的使用，

对于mysql和mogodb数据库的设计和调优控制，

对于服务器的运行平台，linux对于内存和线程的 管理。(重要而不紧急，是必须要做的事情)

这些是目前最迫切的，那句话还是要不断的提醒我自己，做之前要不断的想，做之后要不断的反思。