service - CometD サービスとブロードキャスト チャネル

Question

記事http://www.cometdaily.com/2008/05/15/the-many-shades-of-bayeuxcometd-2/index.htmlで、著者は次のように説明しています。

多くの場合、PubSub では、開発者はプライベート メッセージをクライアントに配信するために、ユーザーごとにチャネルを作成する必要があると感じています。たとえば、取引システムが完了した取引をユーザーに通知したい場合、/trades/a_user_id のようなチャネルを作成して、各ユーザーが自分のチャネルにサブスクライブするようにします。このアプローチは機能しますが、この問題を解決する最もリソースに配慮した方法ではなく、権限のないクライアントが他のユーザー チャネルにサブスクライブするのを防ぐためにセキュリティ コードが必要です。

特定のユーザー向けのメッセージを実装するために、サービス チャネルとブロードキャスト チャネルの間のトレードオフは何ですか? トレードオフのセキュリティ面は理解していますが、リソースのオーバーヘッドはどうですか? カスタム ルーティング サービスよりも多くのリソースがブロードキャスト チャネルで使用される理由がわかりません。賢明であるかどうかの包括的な声明ではなく、ユースケースで一方が他方よりも優れている理由を説明できれば、それは私を決定に導くのに役立ちます.

Answer 1

この記事はかなり古いもので、現在は CometD 3 ですが、CometD 1 について言及しています。

ブロードキャスト チャネルとサービス チャネルの背後にある概念は、CometD 3 でも有効です。

サーバーは、ブロードキャスト チャネルまたはサービス チャネルであるチャネルが作成されるたびに、データ構造を割り当てます。

その記事の例では、N 個のブロードキャスト チャネル (それぞれに 1 つずつuser_id) を作成する場合と、サービス チャネルを 1 つだけ作成する場合を比較しています。前者のソリューションは明らかに後者よりも多くのリソースをサーバー上で使用しており、スニーク ピークの対象となります (クライアントは を推測user_idしてそのチャネルにサブスクライブできるため、他のユーザー宛てのメッセージを受信できます)。

この特定のケースでは、アプリケーションが行う必要があるのは、特定のクライアントにメッセージを配信することだけです。このユース ケースでは、サービス チャネルを使用することをお勧めします。これは、使用するリソースが少ないためです (同じサーバー側チャネルをすべてのユーザーに使用でき、ユーザーが自分宛てではないメッセージを受信するリスクがありません)。より安全に。