2

このエラーを直接報告したかったのですが、メインページ netty.io からまだ可能性が見つかりませんでした

データをチャネルに送信中にエラーが発生しました。常に発生するわけではなく、10 ~ 20% のケースで発生しますが、発生します。続く、

  1. 例として、1024バイトのデータのメッセージで最初の接続を取得した場合、HexDumpProxyInboundHandlerでそれを行う転送アドレスへのソケットを作成するよりも、今まではすべて問題ありません

  2. ここではすべて問題ありませんが、1 つを除いて、転送されたアドレスでトラフィック ログを使用してリスナーを作成しました。ここで、Netty によって送信されたメッセージを取得します。1024 バイトのデータが期待されますが、100% の場合ではなく、常に発生するとは限りません。時折...

  3. 悪夢がここから始まる場合があります.1024バイトのメッセージの後に同じチャネルの次のメッセージを受信すると、データは次のような形式で書き込まれます:

3.1最初のメッセージと2番目のメッセージがマージされ、ポートリスナーで取得したデータは正しく、1024 + 72(例として)で、正しいバイトオーダーでもあります(ただし、マージされた形式では、すでに正しくありません)

3.2 または最初のメッセージと 2 番目のメッセージもマージされますが、データがサーバー ソケットによって正しく受信され、正しい順序であったとしても、順序が異なり、72 (例として) + 1024 バイトという小さな違いが 1 つあります。も間違っていました。

3.3 または最後に 1024 の最初のメッセージがそのまま送信され、続いて 2 番目のメッセージがそのまま送信されるため、ここでもすべて問題なく、これが正しく期待される動作です。

また、エラーは常に発生するわけではありませんが、常に発生し、発生する場合は、最初の接続で最初のメッセージの長さが 1024 バイトで、2 番目のメッセージが最初のメッセージの直後に送信され、以前に受信したデータがない場合にのみ発生します。

コミュニティへの質問ですが、Netty でこのような奇妙なバッファリング動作をオフにすることは可能ですか? そのため、サーバー ソケットで受信したすべてのメッセージは、データをマージすることなく、まったく同じ方法でクライアント ソケット チャネルに送信されます。

前もって感謝します!

4

2 に答える 2

3

この「奇妙な」振る舞いは、nettyとは何の関係もありません。一度に転送されるバイト数はネットワーク層次第なので、これを実際に確認することが期待されます。1024バイトすべてが必要な場合は、十分に受信するまでそれらをバッファリングする必要があります。

于 2012-06-23T18:37:51.423 に答える
1

わかりました、長い夜の後、私はついに問題を解決しました。どうやら、Netty プロジェクトはこのようにまだバグが多く、間違った順序で送信された受信メッセージを受け入れるようです。したがって、私が行うことは、クライアントによるリモート接続が開かれるまで受信メッセージでバッファーを埋めるため、代わりに完全な正しいバッファーよりも送信して、Netty で処理できるようにすることです。

于 2012-06-20T01:33:59.740 に答える