网络传输模块的下一步考虑

基于 XmlRpc++ 而改进
主要扩展了(修改)了以下功能：

• 双端监听：服务器能监听客户端请求，客户端监听服务器请求
• 命令执行由同步改为异步，消息发送后没有确认机制
• 消息发送方：建立发送缓冲区
• 消息发送方：支持多线程的消息发送

//

目前消息的发送与解析相对较稳定，但还存在一些不完善的地方，如下：

１.不支持命令的确认机制；
　　也就是说，当命令发送至缓冲区时，并不能确保消息成功发送至目的地
　　比如说，消息已成功发送至缓冲区，尚未发出，但此时网络断开或者对应应用程序关闭，则消息无法成功发送
　　　暂时还无进一步处理　
　　　后面考虑的可能策略是：a.加入每条消息的确认机制
　　　　　　　　　　　　　　b.发送失败通知应用程序
　　　但是，如果每条消息都进行确认的话，那么资源的消耗与程序复杂度将会大增。因为需要维护每一条消息的收发情况，对其进行计时等等，如果这样，那就相当于在应用层设计一个简单的类似于ＴＣＰ的协议了。但是如果不做这些，那么，可靠性就无法保证。
　　　难以取舍。

２.应用程序无法探知网络层的原始数据：比如说在服务器端，客户端建立连接，连接断开，网络层发送的原始数据等
　此类消息网络层可以感知，但应用程序无法感知此类消息
　后面可能的策略是：提供对应的消息服务，应用程序在对应接口后可以即时感知此类消息
　　　　　

３.使用开放接口不是很方便
　　暂时还没想到什么好办法来改善接口。

４.当消息发送速度非常快(比如１s发送100个数据包)时，缓冲区可能会填满而导致发送队列后面的数据发送失败
　　　当数据发送速度非常快时，可以扩大缓冲区，缩小单次监听时间(work函数里面的参数)两个参数来缓解这种情况
　　　但无法从根本上解决这个问题
　　　现在的设计是通过一个固定的数组做一个循环队列，数组大小不可变。
　　　暂时考虑策略是：数组改为指针。当容量超过缓冲区容量80%时，将缓冲容量扩大1.5倍。再设置一个缓冲区的最大限度，比如1024,不能超过此容量。
　　　比较麻烦的是需要维护内存的重新分配与释放。