これは、統合セットアップに関する私の質問に関連しています (永続的なチャネルを使用したポートの統合)
プロトコルのすべてのトラフィックにプレフィックスを付けた 2 バイト シーケンスを送信しようとしています。私はこれを行っているので、複数のプロトコルをサポートするように更新するときに、統合ハンドラーで盗聴するものがあります。
クライアントでは、パイプラインの最後に、バイトを識別する 2 つのプロトコルを ByteBuf の前に付けるシンプルなアウトバウンド ハンドラーと、それらを抽出するサーバー パイプラインの前にシンプルなインバウンド ハンドラーがあります。これを小さなメッセージで機能させることができました。
サーバー キュー内の後続のハンドラーはLengthFieldBasedFrameDecoder
、着信トラフィック (protobuf オブジェクト) をフレーム化するために使用している です。発生しているように見えるのは、クライアントが 5M などの大きなリクエストを送信していることです。サーバーパイプラインを通過する一連の 64k バッファーを取得します。最後のバッファーは、LengthFieldBasedFrameDecoder
待機しているしきい値を超え、フレームを抽出して処理のために渡します。これは正しく行われます。
この時点で、すべてが壊れます。私が知る限り、クライアントからの最後の 64k バッファーには、フレームの残りのデータ、次の要求の開始を知らせる 2 バイト シーケンス、およびその他のコンテンツが含まれていました。このデータはフレーム デコーダーにあると思いますが、これは次のフレームの長さとして 2 つのプロトコル マジック バイトを使用しますが、これは誤りであり、そこから問題が発生します。
このDelimiterBasedFrameDecoder
場合、その 2 バイト シーケンスは各論理フレーム/リクエストを分割するため、うまくいくように見えますが、このシナリオではやり過ぎのように思えます。
この場合に機能する他のデコーダーはありDelimiterBasedFrameDecoder
ますか?