SignalR:ハブと永続的な接続を選択する理由


150

私は最近SignalRを検索して読んでいますが、ハブと永続的な接続の違いはたくさんの説明がありますが、次のレベルに頭を悩ませることはできませんでした。もう一方のアプローチを選択しますか?

回答:


92

接続とハブ」セクションで私が見たことから、ハブは下位レベルの永続的な接続をオーバーレイするトピックシステムを提供しているようです。

以下の非常に高く投票されたコメントから:

部分的に正しい。トピックまたはグループを永続的な接続で取得することもできます。大きな違いは、さまざまなタイプのメッセージをディスパッチすることです。たとえば、さまざまな種類のメッセージがあり、さまざまな種類のペイロードを送信したいとします。永続的な接続では、ペイロードにメッセージタイプを埋め込む必要がありますが(Rawサンプルを参照)、ハブを使用すると、接続を介してRPCを実行できます(サーバー上のクライアントからサーバー上のクライアントにメソッドを呼び出すことができます)。 。もう1つの大きな点は、モデルのバインドです。ハブを使用すると、厳密に型指定されたパラメーターをメソッドに渡すことができます。

ドキュメントで使用されている例では、チャットルームのメタファーを使用しています。ユーザーは特定のルームに参加して、同じルームの他のユーザーからのメッセージのみを受け取ることができます。より一般的には、コードはトピックをサブスクライブし、そのトピックにパブリッシュされたメッセージのみを取得します。永続的な接続を使用すると、すべてのメッセージが表示されます。

永続的な接続の上に独自のトピックシステムを簡単に構築できますが、この場合、SignalRチームが既に作業を行っています。


180
部分的に正しい。永続的な接続でトピックまたはグループを取得することもできます。大きな違いは、さまざまなタイプのメッセージをディスパッチすることです。たとえば、さまざまな種類のメッセージがあり、さまざまな種類のペイロードを送信したいとします。永続的な接続では、ペイロードにメッセージタイプを埋め込む必要がありますが(Rawサンプルを参照)、ハブを使用すると、接続を介してRPCを実行できます(サーバー上のクライアントからサーバー上のクライアントにメソッドを呼び出すことができます)。 。もう1つの大きなことは、モデルのバインドです。ハブを使用すると、厳密に型指定されたパラメーターをメソッドに渡すことができます。
davidfowl

1
良い点@davidfowl-あなたのコメントを回答にコピーしました。
ColinE 2017

63

主な違いは、PersistentConnectionではRPCを実行できないことです。生データしか送信できません。このようにサーバーからメッセージを送信する代わりに

Clients.All.addNewMessageToPage(name, message);

Connection.Broadcast()またはConnection.Send()でオブジェクトを送信する必要があり、クライアントはそれをどうするかを決定する必要があります。たとえば、次のようなオブジェクトを送信できます。

Connection.Broadcast(new {
    method: "addNewMessageToPage",
    name: "Albert",
    message: "Hello"
});

そしてクライアントでは、単に定義するのではなく

yourHub.client.addNewMessageToPage = function(name, message) { 
    // things and stuff
};

すべての着信メッセージを処理するには、コールバックを追加する必要があります。

function addNewMessageToPage(name, message) {
    // things and stuff
}

connection.received(function (data) {
    var method = data.method;

    window[method](data.name, data.message);
});

OnReceivedメソッドのサーバー側で同じ種類のディスパッチを行う必要があります。また、ハブメソッドのように厳密に型指定されたオブジェクトを受け取る代わりに、そこでデータ文字列を逆シリアル化する必要があります。

ハブ経由でPersistentConnectionを選択する理由はそれほど多くありません。私が知っている1つの理由は、ハブを使用して行うことができない、PersistentConnectionを介して事前シリアル化されたJSON送信できることです。特定の状況では、これは関連するパフォーマンス上の利点になる場合があります。

それとは別に、ドキュメントからこの引用を参照してください:

コミュニケーションモデルの選択

ほとんどのアプリケーションはHubs APIを使用する必要があります。Connections APIは、次の状況で使用できます。

  • 送信される実際のメッセージの形式を指定する必要があります。

  • 開発者は、リモート呼び出しモデルではなく、メッセージングおよびディスパッチモデルを使用することを好みます。

  • メッセージングモデルを使用する既存のアプリケーションが、SignalRを使用するように移植されています。

メッセージ構造によっては、PersistentConnectionを使用することでパフォーマンスのメリットがわずかに得られる場合もあります。

あなたはSignalRサンプル、特にここにこれを見たいかもしれません


同僚の1人が、ハブ経由でPersistentConnectionを選択する理由はセキュリティ上の理由であると私に言ったが、ハブなどにセキュリティ上の問題はあるのか?
Mehdi Dehghani

24

SignalRを使用するには2つの方法があります。PersistentConnectionクラスをオーバーライドすることで低レベルでアクセスできます。これにより、多くの制御が可能になります。または、高レベルの「ハブ」を使用することで、SignalRにすべての重い作業を実行させることができます。


5

持続的接続はより低レベルのAPIであり、接続が開かれたり閉じられたりしたときに、より特定の時間にアクションを実行できます。ほとんどのアプリケーションでは、ハブが最適です。


4

これら2つを比較するときに考慮すべき3つの主要なポイントがあります。

  • メッセージフォーマット
  • コミュニケーションモデル
  • SignalRのカスタマイズ

ハブを使用すると、メッセージのフォーマットは基本的にユーザーから処理されますが、永続的な接続を使用すると、メッセージは未加工でトークン化され、前後に解析されます。メッセージサイズが重要な場合は、固定接続のペイロードがハブのペイロードよりもはるかに少ないことにも注意してください。

通信モデルに関して言えば、永続的な接続には基本的にメッセージングを送受信する機能があり、ハブは要件ごとに固有の機能を持つリモートプロシージャコールモデルを採用しています。

永続的な接続のレベルが低いため、カスタマイズに関しては、カスタマイズをより詳細に制御できる場合があります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.