ithewei

> 如果请求频繁，程序就coredump，输出 > > ``` > 2022-09-21 17:00:27.094 ERROR proc crash, pid=2800 spawn_cnt=3 run_time=1s [hmain.c:402:signal_handler] > ``` > > 否则只会输出 > > ``` > 2022-09-21 17:00:26.926 WARN proc stop/waiting, pid=1799...

看你的崩溃信息是在http_parser_init 这个函数在libhv里是用的开源的没有改动的http_parser，但是workflow里是自己魔改过，如果静态链接workflow库，导致原本应该使用hv动态库里的http_parser，但是却使用了workflow里的，导致崩溃。 解决方法可以动态链接workflow，或者给其中一个库源码里的http_parser加个前缀改名

打印出request failed!，说明resp为空，你后面还使用resp->body，空指针崩溃了

我没有开发过组播相关的业务，对这块不是很熟，如果你需要的话，可以提PR

use channel->close(true)

> 协议报文本身多变，body长度的字段 可能在 body_offset之后。所以这里的assert是不正常的提示。 例如，报文是 [0xff, 0xff, 0x3, 0x2（长度字段）, 0xA]， 前两个字节是head，0x3是类型，0x2是body_len（0x3和0x2两个字节），0xA是校验位 设置时候，body_offset= 2，length_field_offset= 3，length_field_bytes=1， length_adjustment= 1。 这里与assert相悖，所以应该去除assert语句。 body之前的都应该当做head来设置，即 body_offset=5, length_field_offset= 3，length_field_bytes=1， length_adjustment= -2

> 这种计算方式，对使用者来说，要求有点高。必须先理解这4-5个字段的含义后，才能正确使用。感觉还是有改进的空间。特别是length_adjustment 可以为负值这点。 另外，一定要设置这个assert的目的是什么呢？如果按照上例的配置方式，有何不妥之处呢？ hio_unpack_by_length_field里是通过判断收到body_offset字节，即收到整个头部，才开始从头部解析出长度，然后收完body才回调，所以上面assert断言头部长度字段是包含在头部里的，如果不是，则不适用于这个拆包规则。 length_adjustment为负也很常见，有些协议里头部长度字段表示head+body的总长度，此时可以把length_adjustment设置为-body_offset，即减去head的长度。 至于掌握这些字段含义是必须的，也是参考了netty，见https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/handler/codec/LengthFieldBasedFrameDecoder.java

QQ技术交流群：739352073

此issue下不要评论，有问题另外新建issue

> 我写了部分实现，可以参考下： ```c #ifndef HV_LIBEVENT_COMPAT_H_ #define HV_LIBEVENT_COMPAT_H #include "hexport.h" #include "hloop.h" #define event_base hloop_s; #define event hio_s; #define EV_READ HV_READ #define EV_WRITE HV_WRITE typedef int evutil_socket_t; typedef void (*event_callback_fn)(evutil_socket_t fd,...