重写了下远程服务支持库修了一下BUG

80805777

这两个BUG都没了
远程服务支持 - 会员讨论区 - 递归火山软件开发平台 - Powered by Discuz!
远程服务支持库0day bug - 错误及建议提交 - 递归火山软件开发平台 - Powered by Discuz!
之前主要是崩溃BUG，未校验逻辑帧总长度，还有攻击者修改包长位置为负数,还有原本的内存序列处理函数公用静态变量导致的竞争崩溃。都做了一下校验。然后就是性能方面改为纯IOCP了，不是原来的线程池加链表循环select recv的伪异步了。丢包和粘包问题我简单测了下倒是没有发现。用论坛反馈的BUG代码测了下应该也是没有问题。没去给火山封装主要是一个很长时间没有用过火山，导致现在上手很陌生，二来主要是想给易语言去用的，但是因为火山也有顺手一起就发了，各位水友可以外层写一个C++11绑定给火山用。遵守的协议规定如下:
1.传输层定义数据的消息ID和负载长度。
2.消息帧携带实际的分片数据
每个包固定头部 20 字节，用于支持大消息分包（分片）和粘包处理。
Magic        char[4]        魔数，固定为 ASCII 字符串 "EMSG"。
MsgID        char[4]        消息标识符，4 位 ASCII 数字，对应逻辑消息头的 ID，易语言里从第10开始，似乎保留了一些,0已经确定为投递推出消息。
TotalLen        u32（小端）        整个逻辑消息负载的总长度（即逻辑帧中 XML 标记的 N 值）。
Seq        u32（小端）        分片序号，从 0 开始递增。用于接收端重组 fetch类似。
PktLen        u32（小端）        当前分片的负载长度（即紧跟在头部后面的 Payload 字节数）。
Payload        u8[PktLen]        数据分片一个柔性数组。最后一片的数据长度可能小于 MSS。
实际荷载Payload的结构为文本协议头 + 二进制数据，用于让服务端精确提取出业务载荷。
结构格式为：
<Msg{MsgID}>{Payload长度}</Msg{MsgID}> + {原始二进制数据}
举个例子：
假设 MsgId 是 "0010"，业务载荷是 "Hello"（5字节），完整的Payload为：
<Msg0010>5</Msg0010>Hello
这可能也是xmlrpc名称来源的一个原因,它本身就像是一个极其简单的协议格式。

里面带了一个跨平台的易语言远程服务协议的解析库，传输层你也可以自己实现。

仓库:AlongsCode/erpc
附件: erpc.zip (40.7 KB, 下载次数: 3)

昨天 20:05 上传

点击文件名下载附件