Nettyを使用してクライアント/サーバ通信用のバイナリプロトコルを設計しています。送信されるバイト数は固定量ではなく、任意のサイズにすることができます。Nettyでフラグメンテーションを扱う
クライアントがこのような送信された：ID番号 を表す
最初の4バイトの残りのバイトは私が見た例の文字列
で、メッセージのサイズは固定されているがStringコンテンツは任意のサイズにすることができ、サーバーによって受信されたときに断片化されないようにする必要があります。どうすればNettyでこれを達成できますか？
ありがとうございます。
どのようにメッセージの終わりを決定していますか？ゼロ？それはあなたのために物事が容易になります
http://docs.jboss.org/netty/3.2/api/org/jboss/netty/handler/codec/replay/ReplayingDecoder.html
：私はネッティー再生デコーダをチェックアウトします。ゼロを見つけるまで読書を続けてください。ゼロに達する前にバイトを使い果たすと、デコードメソッドを終了するための例外がスローされます。より多くのバイトが利用可能になると、既存のバイトと新しいバイトが1つのChannelBufferで結合された状態で、decodeメソッドが再度呼び出されます。
このサイクルは、メッセージ全体がChannelBufferに入るまで繰り返すことができます。このサイクルは、処理のために次のレイヤーに渡すことができます。
プロトコルを変更することができた場合は、長さを追加すると、長さを読み取ることができるため、すべてのバイトをゼロでチェックするよりもはるかに効率的です。
または、その行に基づいている場合は、そのジョブにDelimiterBasedFrameDecoderを使用するだけです。
参照： http://netty.io/docs/stable/api/org/jboss/netty/handler/codec/frame/DelimiterBasedFrameDecoder.html
ありがとう！ FrameDecoderの独自の実装を作成する必要があるようです。 – algolicious
こんにちはギャレス、答えてくれてありがとう - 非常に感謝しています。私は現在、メッセージの終わりを判断するために何も使用していません。 buffer.readLong（）を呼び出してIDを取得すると、次にbuffer.toString（String charsetName）を呼び出します。これは理想的ではありません。ペイロードのサイズを送信することを参照するとき、それを最初に追加し、長さが受信されるまで待つことを提案し、その任意の数を使用してサーバー上のより多くのバイトを待つことを決定しますか？ – algolicious
はい。長さが決まったら、LengthFieldBasedFrameDecoderを使用することができます（メッセージが非常に大きい場合は、SimpleChannelUpstreamHandlerに基づいて独自のバッファを作成し、バッファを1回だけ割り当てます）。 – Gareth