哦，我正在重写这段，以前写的感觉有点乱，正在重做。
感谢大家的支持，0.71发布了，希望这个服务器能帮助大家。
下一个版本我将重写服务器之间通讯的部分，希望得到大家使用便捷性的一些需求。
最近几天看了下LZ的代码实现，并实际测试了下，有一些体验：
1、LZ现在的服务器之间的通讯是通过IPostMessage来进行的，也就是说，服务器A向服务器B发送一条消息，相应的也只能获取到一条消息进入到Base中去处理，因为你的框架中一条消息是对应一个MsgID，返回时是取回该MsgID对应的IPostMessage来进行设置的。但在实际应用中，服务器A向服务器B可能发送一条消息，也可能不发送消息，并且有可能收到1 ～ N条消息，如果绑定MsgID，这个处理就有缺陷了。所以，我的建议是LZ应该取消和MsgID的绑定，在ProServerConnect类关于读的部分采取和ProConnectHandle一样的方式进行读取数据，并放入消息线程调用注册的ClientCommand的函数进行处理，在ClientCommand中的接口可以不是DoMessage，另外定义一个如DoServerMessage。
2、另外，如果有连接到服务器端的链接有断开发生，我建议LZ也将该事件通知到注册的ClientCommand中去，有利于逻辑的处理。所以，ClientComand对应的接口估计要比现在丰富多些。
3、对于ConnectServer.conf里面的配置信息，现在是在启动服务器开始才会有读取，是否可以考虑设定一定的时间，每隔一定的时间去检测下ConnectServer.conf是否有服务器的增减。因为，在实际应用中，如果我增开服务器，按照现在的操作来讲，应该是先断开，再重新启动，这样的话，不能只能动态的增减服务器，是对用户有影响的。
以上只是我的一些体验和建议，如理解不对，望指出，仅供LZ参考。
很中肯的建议，我正在重写服务器间通讯这部分。你的建议我会进行详细设计考虑。
现在遇到一些思维上的瓶颈，正在考虑更好的设计方法。
对于服务器间的通讯，因为协议格式是不同的。如果把解析代码生硬的加在框架里，通用性就没有了。但是如果剥离出来成为so去实现，那么又过于繁复（一个服务器链接对象一个so，在未来服务器配置上会有繁杂的感觉）
关于你的问题。
1。我考虑过你的方案，这部分确实可行，也是最近我正在重写这套逻辑，但是在于逻辑中，这样的写法会不会导致同一逻辑下，代码模块完全不同呢？给以后代码的阅读和维护造成困难？
2。关于链接断开，这部分可以放入一个事件。这部分确实需要增加。
3。关于动态加载的问题，我也通盘考虑过，我希望通过提供维护端口实现任何配置文件的reload()。这部分将会开放出一个维护端口，管理员可以绑定指定IP，并通过指令控制服务器的so动态加载以及其他配置的生效。
我建议把通讯部分的处理过程与端口号进行绑定，这样服务器可以很好的处理对应的消息；同时，通讯协议里面最好定义8个字节（命令流+命令ID+数据包的总长度）；这样就可以很好的实现插件式的思想，不同的处理过程包装成对应的DLL/SO文件即可，这样服务器就不用进行修改了。
jackypeng 我想过你说的方法，但是这样的话，就很难保持通用性，毕竟服务器之间的链接和协议，未必就是我们所能指定的格式。
现在有两条思路，要不就是做复杂的，通过配置文件和动态库完成完全通用的架构，另外一个就是指定协议，要想使用这个模块必须遵循这个协议。哪个更好呢？
大部分的开源程序或者windows的COM组建思想，也必须遵从一定的协议规则，只要支持自定义的方式，这样就可以很好执行所有人的使用了。我认为遵循一个协议是必须的，也是很有必要的。
思考了一下，同意你的看法，就按照你说的办，协议规格尽量保持弹性即可。
谢谢楼主分享，共同进步
我想问问楼主，当链接断开的时候，如何回收链接句柄handler，此时有可能其他线程正从队列中取消息？