3

背景: 現在、通信インフラストラクチャに Netty を使用するフェデレーション/分散ソリューションのプロトタイプを作成中です。

必要なものを実現するために、Netty の周りにいくつかの機能を作成する必要があることは理解していますが、Netty が提供するものを理解したいので、車輪を再発明する必要はありません。

目標: 通信相手のターゲット エンドポイントに基づいて適切な通信チャネルを自動的に選択する汎用通信ディスパッチ レイヤーを提供する必要があります。

ターゲットがローカルの場合、in-vm で通信したいと考えています。リモートの場合は、websocket で独自のバイナリ形式を使用する予定です。ローカルかリモートかがわかるので、適切なチャネルを作成/選択するだけです。

各サーバー インスタンスには、何らかの種類のチャネル キャッシュ/マップがあると思います。これには以下が含まれます。

  • 1 (VM 内) チャネル
  • 0+ (websocket) チャネル: サーバー間チャネルごとに 1 つ

質問: ローカル (VM 内) 通信の目標を考えると、次のことを行う必要があります。

  • LocalChannelを使用しますか？
  • EmbeddedChannel を使用しますか? - これが何を意図しているのかわからない
  • 通話をショートして、公式チャンネルを使用せずに直接通信しますか?

LocalChannel を使用する場合とローカル コールを短絡する場合のパフォーマンスに大きな違いはありますか? ローカルケースでのエンコード/デコードを排除できれば、それが望ましいでしょう。

ありがとう！

4

1 に答える 1

3

次のマルチプレイヤー ゲーム サーバーで VM 内メッセージングに Netty で Jetlang を使用しました。コードのUDP部分を見て、セッションルックアップなどを行う方法を確認することをお勧めします。これは、ユースケースに少し似ているようです。
EmbeddedChannelテスト目的で使用されます。使用例については、jetserver のテスト ケースをご覧ください。主流の使用を意図したものではありません。
チャンネルを使わずにどうするかわからないので、その部分に答えることができません.

于 2012-10-26T03:45:19.230 に答える