基于 XmlRpc++ 而改进
主要扩展了(修改)了以下功能:
[list]
[*] 双端监听:服务器能监听客户端请求,客户端监听服务器请求
[*] 命令执行由同步改为异步,消息发送后没有确认机制
[*] 消息发送方:建立发送缓冲区
[*] 消息发送方:支持多线程的消息发送
[/list]//
目前消息的发送与解析相对较稳定,但还存在一些不完善的地方,如下:
1.不支持命令的确认机制;
也就是说,当命令发送至缓冲区时,并不能确保消息成功发送至目的地
比如说,消息已成功发送至缓冲区,尚未发出,但此时网络断开或者对应应用程序关闭,则消息无法成功发送
暂时还无进一步处理
后面考虑的可能策略是:a.加入每条消息的确认机制
b.发送失败通知应用程序
但是,如果每条消息都进行确认的话,那么资源的消耗与程序复杂度将会大增。因为需要维护每一条消息的收发情况,对其进行计时等等,如果这样,那就相当于在应用层设计一个简单的类似于TCP的协议了。但是如果不做这些,那么,可靠性就无法保证。
难以取舍。
2.应用程序无法探知网络层的原始数据:比如说在服务器端,客户端建立连接,连接断开,网络层发送的原始数据等
此类消息网络层可以感知,但应用程序无法感知此类消息
后面可能的策略是:提供对应的消息服务,应用程序在对应接口后可以即时感知此类消息
3.使用开放接口不是很方便
暂时还没想到什么好办法来改善接口。
4.当消息发送速度非常快(比如1s发送100个数据包)时,缓冲区可能会填满而导致发送队列后面的数据发送失败
当数据发送速度非常快时,可以扩大缓冲区,缩小单次监听时间(work函数里面的参数)两个参数来缓解这种情况
但无法从根本上解决这个问题
现在的设计是通过一个固定的数组做一个循环队列,数组大小不可变。
暂时考虑策略是:数组改为指针。当容量超过缓冲区容量80%时,将缓冲容量扩大1.5倍。再设置一个缓冲区的最大限度,比如1024,不能超过此容量。
比较麻烦的是需要维护内存的重新分配与释放。
主要扩展了(修改)了以下功能:
[list]
[*] 双端监听:服务器能监听客户端请求,客户端监听服务器请求
[*] 命令执行由同步改为异步,消息发送后没有确认机制
[*] 消息发送方:建立发送缓冲区
[*] 消息发送方:支持多线程的消息发送
[/list]//
目前消息的发送与解析相对较稳定,但还存在一些不完善的地方,如下:
1.不支持命令的确认机制;
也就是说,当命令发送至缓冲区时,并不能确保消息成功发送至目的地
比如说,消息已成功发送至缓冲区,尚未发出,但此时网络断开或者对应应用程序关闭,则消息无法成功发送
暂时还无进一步处理
后面考虑的可能策略是:a.加入每条消息的确认机制
b.发送失败通知应用程序
但是,如果每条消息都进行确认的话,那么资源的消耗与程序复杂度将会大增。因为需要维护每一条消息的收发情况,对其进行计时等等,如果这样,那就相当于在应用层设计一个简单的类似于TCP的协议了。但是如果不做这些,那么,可靠性就无法保证。
难以取舍。
2.应用程序无法探知网络层的原始数据:比如说在服务器端,客户端建立连接,连接断开,网络层发送的原始数据等
此类消息网络层可以感知,但应用程序无法感知此类消息
后面可能的策略是:提供对应的消息服务,应用程序在对应接口后可以即时感知此类消息
3.使用开放接口不是很方便
暂时还没想到什么好办法来改善接口。
4.当消息发送速度非常快(比如1s发送100个数据包)时,缓冲区可能会填满而导致发送队列后面的数据发送失败
当数据发送速度非常快时,可以扩大缓冲区,缩小单次监听时间(work函数里面的参数)两个参数来缓解这种情况
但无法从根本上解决这个问题
现在的设计是通过一个固定的数组做一个循环队列,数组大小不可变。
暂时考虑策略是:数组改为指针。当容量超过缓冲区容量80%时,将缓冲容量扩大1.5倍。再设置一个缓冲区的最大限度,比如1024,不能超过此容量。
比较麻烦的是需要维护内存的重新分配与释放。