私は暗号化されたP2Pアーキテクチャの低レベルUDPメッセージングレイヤーに取り組んでいます。興味があれば、そのgithubページで詳細を読むことができます。
私は、POJOをコンパクトなByteBufferに変換するきちんとしたシリアル化フレームワークと、対称および非対称の暗号をかなり簡単に使用できるようにするさまざまなライブラリを構築しました。
私は現在、動的プロキシを利用してGWTのRPCメカニズムと同様の機能を実現するメッセージングフレームワークに取り組んでいます。
私の問題は、早い段階でシリアル化メカニズムをByteBuffersとの間で読み書きすることにしたことです。私は今、これにはいくつかの問題があることに気づいています。
このフレームワークでシリアル化を実装する別の方法を誰かが提案できますか？
KryoNetを見てみる価値があるかもしれません- それはあなたのニーズに合うかもしれません。
ちなみに、TCP 接続と UDP 接続の両方に ByteBuffers を使用します。クライアント コードが POJO だけで機能するように、ByteBuffer を抽象化するのが秘訣だと思います。これを行うには、大きなオブジェクトを複数のバッファリングされた書き込みに分割できるロジックがどこかに必要であることは明らかです。
ByteBuffers は非常に高速であり、さまざまなネイティブ アクセラレーション トリックをサポートし、好むと好まざるとにかかわらず、最終的には高スループットの IO 環境でバッファリングを処理する必要があるため、実際にはまだ内部で ByteBuffers が必要だと思います....
このフレームワークでシリアル化を実装する別の方法を誰かが提案できますか？
なぜ代替的なのか、ここで私はあなたの主な懸念に対処します：
- オブジェクトをシリアル化する前に、最大バイトバッファサイズを知っておく必要があります
なぜByteBufferの最大サイズなのですか？バッファのプールを使用できます。オブジェクトを複数のパケットに分割する準備をする必要があります。1つのパケット-1つのオブジェクトは大きなオブジェクトでは機能しません。シリアル化は興味深い点です。通常、それが厄介になるところです。あなたはいくつかのまともなプロトコル層が必要になります（+-パケットの再送信など）
- それらは変更可能であるため、エラーが発生しやすくなります
パフォーマンス上の理由から、'emを変更可能にする必要があります。それらが変更可能であることに問題があったことは一度もありません。直接バッファも必要になる可能性があります。Goodnessに感謝します。割り当てを（割り当て解除）するのは安価ではないため、変更されます。直接バッファーはOSコードに直接マップされます（sun.nio.ch.DatagramDispatcherを参照してください）。
- それらはDatagramPacketと特に互換性がなく、DatagramChannelsは混乱を招きます。
それらは大丈夫です、あなたはただあなたのオブジェクトを複数のパケットに分割する必要があります。バッファを使用する場合は、バッファに固執すれば問題ありません。