limpo1989
limpo1989
go-netty设计之初是想要结合netty的流水线思想 + Go协程编程模式来简化网络编程,如果回退到reactor模式,那就和传统的C++/Java 一样了(C++/Java 社区也有各种基于协程的改造版本来提升编程体验),如果不是用来做高性能网关,当前的模式是性能足够的
是否需要LengthFieldCodec 需要业务自己决定(在流水线装配阶段),通常基于TCP的网络都需要有个头,用来处理粘包问题,你可以参考下编解码器完全自定义
> 刚启动服务端时,就不断出现读事件,而且没启动客户端,打开飞行模式也一样,可以排查外网的影响,而且之前在java的netty框架中启动服务端也不会出现不断的读事件,事件处理器这块是这样的 `go-netty` 不是一款事件驱动的网络库,因此编解码器是必须要指定的,不然就会出现你说的这个问题
> 但就是无法单方向接收java语言的Netty框架请求,有时候可以 建议断点跟踪一下 [delimiter](https://github.com/go-netty/go-netty/blob/a9df2d21ebc0b4929b4f3ad2ebd19347d431b019/codec/frame/delimiter.go#L50C10-L50C24),看你描述是不是Java netty那边没有把数据 flush出来 导致go这边没有收到数据,可以考虑一下在发送完数据后调用下flush
`go-netty` DelimiterCodec 中会在Write操作后面增加 分隔符,不需要外部手动插入分隔符 https://github.com/go-netty/go-netty/blob/c349cfd03a346383a9fed72123bd96f4ddc530e5/codec/frame/delimiter.go#L83-L101 在REMEAD中提供的示例,可以看到在发送数据的过程中 不需要主动插入分隔符
Java是异步IO,如果遇到半包需要在下次收到消息时继续尝试解析,但是在Go的世界中IO都是阻塞的,如果存在半包消息则Read接口会阻塞,直到收到指定大小的数据后才会解除阻塞,因此你提到的半包/粘包在Go的世界中不需要像Java那样处理~
> > Java是异步IO,如果遇到半包需要在下次收到消息时继续尝试解析,但是在Go的世界中IO都是阻塞的,如果存在半包消息则Read接口会阻塞,直到收到指定大小的数据后才会解除阻塞,因此你提到的半包/粘包在Go的世界中不需要像Java那样处理~ > > 对应的具体方法是 `io.ReadFull` 吗? 可以这么认为,当从头部解析出来长度之后,通过ReadFull读取这么长的数据包,自然就解决了半包/粘包问题
Yes, in the company in my job, we use `go-netty` to implement a RPC framework and serve as our application layer infrastructure. It works well 😁