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