QQ: 2#4#2#1#0#6#7#6#4 #表示为空
Mail: lin_style#foxmail.com #替换成@
系列一：游戏服务器的总体框架
系列二：游戏服务器的邮局路由
系列三：游戏服务器的邮局服务器
该篇的小总结主要是想综合我手上的代码情况做个总结。此篇后，可能会暂时停止编码，我发现我的很多思维上的东西，其他类似的已经有很多交集点。因此我觉得需要潜心专研几个其他的框架。 而现在手头上的编码大概有4000行左右(不完全统计)，一些很基本的服务器和框架形状已经呈现,达到目的了，再下去就是闭门造车了。而且对以前发的文章一些新的方法也不在更新了。
目前已有的组件：
- CommonLib:顾名思义
- ClientPlay:模拟的客户端
- PostofficeRoute:控制邮局的路由
- PostofficeServer:邮局
- ServerBin:逻辑服务器
- ServerDPC:无。一个延迟的事件处理(对逻辑服务器的全局控制)
目前编码的风格方式： 
可以参考前面的几个章节。因此在目录的大分类上，把最主要的提取出来,使得一目了然(自认为)：
- Config:配置文件
- Protocol:协议文件
- Logic:逻辑层
- Brdige:粘贴逻辑/网络层的一个文件头，主要是放置两边通用的信息
- Network:网络层
- Standalone:一些独立的对象文件
- 其他:一些主函数体
在工程的内部，我就开始细分。见图： 
既然是做游戏，那么为了符合一个理解，我把Role,Scene单独提炼了出来。在Standalone里我放置了平常需要用到的单独对象，比如需要自定的时间、封装的线程生命周期，可以放到"OS"这个单独的目录里，其他也是如此。不过注意，我把算法"Algorithm"单独提取了出来。
这样通过目录的分层和工程内部的分层,起码对我来说，隔个十几天再去回顾时，这些名字和结构很容易提醒起我这是干嘛的
并且在名字上，为了保持统一性，比如这个工程师PostofficeServer(邮局的)，那么他可能对bin和PostofficeRoute都要进行通讯，那么在Network里命名规则就是CServerXXXX, CServer即PostofficeServer的缩写，XXXX如果是Route,就表示是对PostofficeRoute的通讯。除此之外，在Logic，protocol里等等，我都采取了这样的规则( “C主方次方” )。一点小规则。。
每个组件现在能完成的功能：
- ClientPlay:可以加入协议开始和服务端调测
- PostofficeRoute:可以根据CPU数自动的开启对应的UDP线程对客户端回应；可以根据邮局服务器的更新做出负载控制(见前三章)；可以动态的接收连接
- PostofficeServer:可以做出与Route的控制更新；可以接受客户端的连接；可以和ServerBin进行通讯；可以动态的接收ServerBin的连接；可以支持PostofficeServe和ServerBin的对应关系；可以进行客户端在ServerBin的动态跳转
- ServerBin:主要配合PostofficeServer的调试。数据库，角色等不具体写代码
- ServerDPC:无。一个延迟的事件处理(对逻辑服务器的全局控制)
完成这些功能调试后暂时收工：
- 客户端到ServerBin的信息互相转发
- 客户端动态的在ServerBin上切换
尾声：
在不知不觉的挤时间中，它终于有点了小的模型和设计。截止发布这篇文章为止，svn的版本已经到了200。这就可以看出平时我对它的时间是多么的零碎。
不过，最近发生了一点事，进度拖了很多。咳~~end..