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 😁