SignalR: ¿Por qué elegir Hub vs. Conexión persistente?


150

He estado buscando y leyendo sobre SignalR recientemente y, aunque veo muchas explicaciones sobre cuál es la diferencia entre los Hubs y las Conexiones persistentes, no he podido entender el siguiente nivel, por lo que debería elegir un enfoque sobre el otro?

Respuestas:


92

Por lo que veo en la sección Conexión y Hubs, parece que los Hubs proporcionan un sistema de temas que superpone las conexiones persistentes de nivel inferior.

Del comentario altamente votado a continuación:

Parcialmente correcto. También puede obtener temas o grupos en conexiones persistentes. La gran diferencia es enviar diferentes tipos de mensajes. Por ejemplo, tiene diferentes tipos de mensajes y desea enviar diferentes tipos de cargas. Con conexiones persistentes, debe incrustar el tipo de mensaje en la carga útil (consulte la muestra sin formato), pero los concentradores le permiten realizar RPC a través de una conexión (le permite invocar métodos en el cliente desde el servidor y desde el servidor al cliente) . Otra gran cosa es el modelo de encuadernación. Los concentradores le permiten pasar parámetros fuertemente tipados a los métodos.

El ejemplo utilizado en la documentación utiliza una metáfora de la sala de chat, donde los usuarios pueden unirse a una sala específica y luego solo recibir mensajes de otros usuarios en la misma sala. Más genéricamente, su código se suscribe a un tema y luego solo recibe mensajes publicados sobre ese tema. Con las conexiones persistentes obtendrías todos los mensajes.

Puede crear fácilmente su propio sistema de temas sobre las conexiones persistentes, pero en este caso el equipo de SignalR ya hizo el trabajo por usted.


180
Parcialmente correcto. También puede obtener temas o grupos en conexiones persistentes. La gran diferencia es enviar diferentes tipos de mensajes. Por ejemplo, tiene diferentes tipos de mensajes y desea enviar diferentes tipos de cargas. Con conexiones persistentes, debe incrustar el tipo de mensaje en la carga útil (consulte la muestra sin formato), pero los concentradores le permiten realizar RPC a través de una conexión (le permite invocar métodos en el cliente desde el servidor y desde el servidor al cliente) . Otra gran cosa es el modelo de encuadernación. Los concentradores le permiten pasar parámetros fuertemente tipados a los métodos.
davidfowl

1
Buen punto @davidfowl: he copiado tu comentario en la respuesta, ya que creo que debería ser más prominente.
ColinE

63

La principal diferencia es que no puede hacer RPC con PersistentConnection, solo puede enviar datos sin procesar. Entonces, en lugar de enviar mensajes desde el servidor como este

Clients.All.addNewMessageToPage(name, message);

tendrías que enviar un objeto con Connection.Broadcast()o Connection.Send()y luego el cliente tendría que decidir qué hacer con eso. Podría, por ejemplo, enviar un objeto como este:

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

Y en el cliente, en lugar de simplemente definir

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

tendría que agregar una devolución de llamada para manejar todos los mensajes entrantes:

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

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

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

Tendría que hacer el mismo tipo de despacho en el lado del servidor en el OnReceivedmétodo. También tendría que deserializar la cadena de datos allí en lugar de recibir los objetos fuertemente tipados como lo hace con los métodos de concentrador.

No hay muchas razones para elegir PersistentConnection sobre Hubs. Una de las razones por las que estoy al tanto es que es posible enviar JSON preerializados a través de PersistentConnection, lo que no se puede hacer con los concentradores. En ciertas situaciones, esto podría ser un beneficio de rendimiento relevante.

Aparte de eso, vea esta cita de la documentación :

Elegir un modelo de comunicación

La mayoría de las aplicaciones deberían usar la API de Hubs. La API de Connections podría usarse en las siguientes circunstancias:

  • El formato del mensaje real enviado debe especificarse.

  • El desarrollador prefiere trabajar con un modelo de mensajería y despacho en lugar de un modelo de invocación remota.

  • Una aplicación existente que usa un modelo de mensajería está siendo portada para usar SignalR.

Dependiendo de la estructura de su mensaje, también puede obtener pequeños beneficios de rendimiento al usar PersistentConnection.

Es posible que desee echar un vistazo a las muestras de SignalR, específicamente esto aquí.


Uno de mis compañeros de trabajo me dijo que la razón por la que elige PersistentConnection sobre Hubs es la razón de seguridad, ¿hay algún problema de seguridad en Hubs o algo así?
Mehdi Dehghani

24

Hay dos formas de usar SignalR: puede acceder a él en un nivel bajo anulando su PersistentConnectionclase, lo que le da mucho control sobre él; o puede dejar que SignalR haga todo el trabajo pesado por usted, utilizando los 'Hubs' de alto nivel.


5

La conexión persistente es una API de nivel inferior, puede realizar acciones en un momento más específico cuando la conexión se abre o se cierra, en la mayoría de las aplicaciones, el Hub es la mejor opción


4

Hay tres puntos principales a considerar al comparar estos dos:

  • Formato de mensaje
  • Modelo de comunicación
  • Personalización de SignalR

Con el formato de mensajes de los concentradores, básicamente se maneja desde usted, pero con conexiones persistentes, el mensaje es sin formato y se ha tokenizado y analizado de un lado a otro. Si el tamaño del mensaje es importante, también tenga en cuenta que la carga útil de una conexión persistente es mucho menor que la de un concentrador.

Cuando se trata del modelo de comunicación, las conexiones persistentes básicamente tienen una función para enviar y recibir mensajes, mientras que los concentradores toman un modelo de llamada a procedimiento remoto con una función única por requerimiento.

Cuando se trata de personalización, ya que las conexiones persistentes tienen un nivel más bajo, pueden darle más control sobre la personalización.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.