NettyとProtobufを使ってメッセージディストリビュータを実装したいと思います。ディストリビューターは、基本プロトページメッセージを知っているサーバーであり、拡張機能を持っており、それらの拡張機能に登録する他のクラスにそれらを渡すサーバーです。Nettyのprotobuf拡張を使用して汎用ディストリビュータを実装する
Protobufでは、拡張子の宣言を別々のファイルで行うことができるため、配布者は拡張子の形式について知る必要はありません。しかし、これはNetty配管と連携して、すべての拡張機能について知っているExtensionRegistryでProtobufDecoderを作成する必要があると思われます。そうでないと、hereという問題が発生します。
ここに何か不足していますか、それとも私自身のデコーダを書いていないとできないものですか？ Javaで例があれば、非常に役に立ちます。
the API documentationに記載されているように、ProtobufDecoderを構築するときにExtensionRegistryを指定することができます。
私の2つのセントは、要素のリストや潜在的に大きなメッセージである可能性のあるものがある場合、拡張機能を使用しないことです。 protobufメッセージとともにlength-framingデコーダ/エンコーダのいずれかを使用して、サイズが正しく区切られている必要があります。あなたの2バイトサイズのヘッダーに、例えば64k w /にメッセージを収めたいのであれば、フレーム内に収まるかどうかを確認するために、メッセージにtoByteArrayを呼び続けるのは非効率です。
マスターメッセージで拡張子ではなく列挙型を使用する代わりに、拡張子に含まれるはずのprotobufシリアル化メッセージであるバイト配列を使用します。こうすることで、構築時にメッセージにポストフィックスデータを保持することができます。サイズ制限を超えて実行すると、Nettyがフレームに対して大きすぎるという例外をスローするのではなく、半分に分けて正常に分割できます。
ありがとう、Trustin - 私はすでに分かっていましたが、私が混乱しているのは、ディストリビュータにすべての拡張機能を知らせたくないため、ProtobufDecoderに与えるExtensionRegistryがかなり空になることです。私は* OKだと思う - 私はメッセージを再シリアライズし、関連する拡張機能を知っているExtensionRegistryで独自のデコード処理を行うハンドラに渡すことができます。正しい？ –
残念ながら、私はprotobuf拡張で作業する機会がなかったので、正しいかどうかはわかりません。私の推測ですが、それは動作するはずです。ここに戻り、それが動作するかどうかお知らせください。 – trustin