在我们的应用程序中,我们有一个客户端/服务器对,他们使用一个小握手协议P1来初始化连接,之后切换到另一个协议P2。
对于P1协议,管道被初始化为以下处理程序:
完成P1握手协议后,流量应切换到P2协议,此时我们首先需要清空管道,然后添加一组独立的处理程序。
遇到的问题是LengthFieldBasedFrameDecoder的移除会触发意外读取(因为处理程序的ByteBuf中还有未读的字节)。但是,由于此时管道为空(已清除,但尚未添加新处理程序),传入消息将被丢弃。
在处理程序尚未放置的时间内,是否有任何“安全”的方法来进行管道切换而不触发不必要的读取?
谢谢
后续编辑:
我在这里阅读有关替换解码器的信息: (标题为“在管道中用另一个解码器替换解码器”部分)
对于P1协议,管道被初始化为以下处理程序:
LengthFieldBasedFrameDecoder
P1ProtocolMessageDecoder
LengthFieldPrepender
P1ProtocolMessageEncoder
完成P1握手协议后,流量应切换到P2协议,此时我们首先需要清空管道,然后添加一组独立的处理程序。
P2MessageDecoder
P2MessageEncoder
IdleHandler
当收到P1协议中的最后一个预期消息时,会进行管道切换:
// switch traffic to P2 protocol
clearPipeline();
addNewHandlers();
遇到的问题是LengthFieldBasedFrameDecoder的移除会触发意外读取(因为处理程序的ByteBuf中还有未读的字节)。但是,由于此时管道为空(已清除,但尚未添加新处理程序),传入消息将被丢弃。
在处理程序尚未放置的时间内,是否有任何“安全”的方法来进行管道切换而不触发不必要的读取?
谢谢
后续编辑:
我在这里阅读有关替换解码器的信息: (标题为“在管道中用另一个解码器替换解码器”部分)
http://netty.io/4.0/api/io/netty/handler/codec/ReplayingDecoder.html
我成功应用的解决方法是:我已经成功应用的解决方法是:
removeOldNonByteToMessageHandlers();
addNewHandlers()
removeOldByteToMessageHandlers();
// when the "leftover bytes" read is triggered the new handlers are already in place
我的解决方案似乎有些笨拙。 是否有更好的“netty-er”方式来实现这个?