SignalR: почему выберите концентратор против постоянного соединения?

недавно я искал и читал о SignalR, и, хотя я вижу много объяснений того, в чем разница между концентраторами и постоянными соединениями, я не смог получить свою голову на следующем уровне, поэтому я бы выбрал один подход над другим?

5 ответов


от того, что я вижу в секция подключения и концентраторов похоже, что концентраторы предоставляют систему тем, перекрывающую постоянные соединения нижнего уровня.

из высоко проголосовавшего комментария ниже:

частично правильно. Вы также можете получить темы или группы в постоянных соединениях. Большая разница заключается в отправке различных типов сообщений. Например, у вас есть различные виды сообщений, и вы хотите отправить различные виды полезная нагрузка. С постоянными соединениями вы должны встроить тип сообщения в полезную нагрузку (см. Пример Raw), но концентраторы дают вам возможность выполнять RPC через соединение (позволяет вызывать методы на клиенте с сервера и с сервера на клиент). Еще одна большая вещь-привязка модели. Концентраторы позволяют передавать строго типизированные параметры методам.

в Примере, используемом в документации, используется метафора чата, где пользователи могут присоединиться к определенной комнате, а затем получить сообщения от других пользователей в той же комнате. В более общем плане ваш код подписывается на тему, а затем получает только сообщения, опубликованные в этой теме. С постоянными связями вы получите все сообщения.

вы можете легко создать свою собственную систему тем поверх постоянных соединений, но в этом случае команда SignalR уже сделала работу за вас.


основное отличие заключается в том, что вы не можете делать RPC с PersistentConnection, вы можете отправлять только необработанные данные. Поэтому вместо отправки сообщений с сервера, как это

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 над концентраторами. Одна из причин, по которой я знаю, что это возможно отправить preserialized JSON через PersistentConnection, что вы не можете сделать использование концентраторов. В некоторых ситуациях это может быть важным преимуществом производительности.

кроме того, см. Эту цитату из документация:

выбор модели связи

большинство приложений должны использовать API концентраторов. API соединений может использовать в следующих случаях:

  • необходимо указать формат фактического отправленного сообщения.

  • разработчик предпочитает работать с моделью обмена сообщениями и диспетчеризации вместо модели удаленного вызова.

  • существующее приложение, использующее модель обмена сообщениями, переносится для использования SignalR.

в зависимости от структуры сообщения вы также можете получить небольшие преимущества от использования PersistentConnection.

вы можете взглянуть на образцы SignalR, в частности этот здесь.


существует два способа использования SignalR: вы можете получить к нему доступ на низком уровне, переопределив его PersistentConnection класс, который дает вам много контроля над ним; или вы можете позволить SignalR сделать все тяжелое для вас, используя "концентраторы" высокого уровня.


постоянное соединение-это API более низкого уровня, вы можете выполнять действия в более конкретное время, когда соединение открыто или закрыто, в большинстве приложений концентратор-лучший выбор


есть три основных момента, которые следует учитывать при сравнении этих двух:

  • Формат Сообщения
  • модель коммуникации
  • настройка SignalR

с концентраторами форматирование сообщений в основном обрабатывается от вас, но с постоянными соединениями сообщение является необработанным и имеет токенизированный и анализируется взад и вперед. Если размер сообщения важен, также обратите внимание, что полезная нагрузка постоянного соединения намного меньше, чем у ступица.

когда дело доходит до модели связи постоянные соединения в основном имеют функцию для отправки и получения сообщений, а концентраторы принимают удаленный вызов процедур модель с уникальной функцией в требование.

когда дело доходит до настройки, так как постоянные соединения более низком уровне они могут дать вам больше контроля над настройки.