.net - mvc - Investigando soluciones para notificar a los clientes WPF desde el servidor

signalr php

Question

Tengo un proyecto que viene con el requisito de notificar a los clientes de escritorio de WPF cuando algo sucede en el servidor. Además, la notificación a los clientes de WPF no se emitirá (se enviará a cada cliente), se debe enviar a clientes específicos.

Quiero mantenerme alejado del viejo servidor de encuestas. Esto debe ser lo más cercano al tiempo real posible.

Nunca he tenido este requisito antes y estoy investigando soluciones. Mi primer pensamiento fue utilizar SignalR con el cliente .NET . No he trabajado con SignalR todavía, pero parece que podría ser una solución. Soy consciente de que esto es una abstracción sobre los sondeos largos, los eventos enviados por el servidor y los WebSockets, dependiendo de lo que esté disponible.

He leído brevemente sobre WCF con Callbacks y buses de servicio, pero no sé nada acerca de ellos todavía o si esas tecnologías se aplican aquí. Podría usar algunos comentarios y sugerencias de las personas que han abordado esto antes. ¿Como lo harias?

Answer 1

Deberías mirar en WebSync desde Frozen Mountain. Lo he usado en el pasado con grandes resultados. Hace todo lo que necesita. Incluso ofrecen un servicio alojado ''WebSync on Demand''. También ofrecen un producto gratuito (pero hasta 10 usuarios concurrentes). Es un producto comercial. Si no desea hacer todas las tuberías, WebSync le ofrece listo para usar las API que puede comenzar a usar y ponerse en marcha rápidamente. He escuchado / leído sobre SignalR, no lo he usado todavía, pero SignalR parece estar en alpha / beta, mientras que WebSync es muy maduro.

Answer 2

Esta pregunta es interesante.

Actualmente estamos desarrollando una aplicación que interactúa con múltiples servicios web. Uno de los requisitos es que cada cliente debe estar al tanto de las acciones realizadas por los otros clientes.

Para lograr esto, estamos pensando en crear un servicio web cuyo propósito es crear una lista de clientes para notificar y manejar la lógica detrás de quién es notificado, cuándo y el contenido de la notificación. Los clientes se registrarán en ese Servicio cuando se inicien. Las notificaciones en sí se harían usando devoluciones de llamada como usted mencionó.

La razón detrás del uso de un servicio web completamente separado se debió al hecho de que todos nuestros servicios existentes requerían que las conexiones se establecieran y se interrumpieran en cada llamada. Con el Servicio Web de notificación, las conexiones deben mantenerse mientras los clientes se ejecuten.

Lo siento, no podría ser de mucha ayuda, ya que nosotros mismos estamos en el proceso de desarrollar un sistema así. También estoy interesado en obtener comentarios sobre este tema.

Answer 3

Esto se puede hacer con bastante facilidad con los contratos WCF y dúplex . Puede definir las operaciones que el cliente puede realizar en el servidor (como cualquier servicio web) y, además, puede definir las operaciones que el servidor puede realizar en el cliente (es decir, un servicio web inverso). Código sabio, ambos son simples llamadas de método. El cliente tiene métodos que llaman a las operaciones en el servidor y también debe proporcionar un objeto que implemente el contrato de devolución de llamada, que es una interfaz a la que el servidor puede llamar y el cliente debe proporcionar una implementación. WCF gestiona toda la serialización / deserialización de datos y mensajes y todas las operaciones de red de bajo nivel, por lo que no tendrá que preocuparse por ello.

WCF admite contratos dúplex utilizando dos enlaces (o ''protocolos''):

1. WSDualHttpBinding : esto implica dos escuchas HTTP basadas en SOAP, una en el servidor y otra en el cliente. Cuando el cliente desea contactar con el servidor, realiza una solicitud HTTP al servidor. Cuando el servidor desea contactar al cliente, realiza una solicitud HTTP al cliente. La ventaja de este enfoque es que cualquier conexión de red es fugaz y no se mantiene abierta (como en la mayoría de las conexiones HTTP), por lo que puede admitir un gran número de clientes concurrentes. La principal desventaja es que probablemente no funcione con la mayoría de las computadoras cliente a través de Internet, ya que generalmente están detrás de NAT (un problema que no se produce en las comunicaciones de servidor a servidor a través de Internet o cualquier tipo de comunicación dentro de una intranet o LAN) . Para más detalles, vea mi otra respuesta .

2. NetTcpBinding : esto básicamente abre un socket del cliente al servidor y lo mantiene abierto durante la sesión. Esto permite comunicaciones bidireccionales incluso a través de NAT, pero como las conexiones deben mantenerse abiertas, es un poco más una carga para el servidor y, por lo tanto, podrá admitir menos usuarios concurrentes (pero probablemente aún más que suficiente en la mayoría de los casos). Esta es mi forma preferida de hacer contratos dúplex en WCF, ya que es más fácil trabajar y es más confiable.

La ventaja de WCF es que puede cambiar entre los dos enlaces sin cambiar su código. Todo lo que se requiere es cambiar la configuración (archivo .config).

Cualquiera sea la forma que elija, podrá realizar una comunicación casi instantánea en ambas direcciones (por supuesto, si la latencia de la red lo permite). No veo la necesidad de SignalR cuando tiene a su disposición un marco tan rico, potente y fácil de usar como WCF. Si estuviera limitado al ejecutar un navegador, entonces SignalR tendría sentido. Ya que estás ejecutando en .NET, solo introduciría fricciones innecesarias.

Answer 4

Puede crear un servicio de wcf donde los clientes de wpf se registren a sí mismos en el inicio. Luego, cada wpf podría comunicarse con un servidor msmq o rabbitmq, donde sondearán su propia cola creada en función del nombre del cliente / id único. En el lado del servidor, puede tener un servicio que empujará los datos a las colas, ya que los datos están disponibles según las condiciones establecidas para cada cliente.

Answer 5

También estaba evaluando una forma ligera pero fácil de comunicar eventos a los clientes de WPF mediante un servicio de publicación / suscripción. No requerí una entrega de mensajes garantizada, por lo que soluciones como Massemploy o NServiceBus parecían demasiado pesadas, ya que requieren que haya colas disponibles (MSMQ o de otro tipo). También tenía el requisito de que la solución estuviera disponible como perfil de cliente .NET 4.0.

Una solución construida en WCF que parece funcionar es nvents . No estoy seguro si ese proyecto todavía está activo. Es fácil de usar y la implementación subyacente (WCF) está bien resumida. No se requiere configuración desagradable.

Otra solución que encontré en el Blog Per Brage es utilizar SignalR con extensiones reactivas. No he probado su implementación y no estoy seguro de si requiere un perfil completo, ¡pero es una buena lectura!

Answer 6

El punto de las tecnologías como SignalR es satisfacer la demanda de comunicación en tiempo real entre servidores y clientes web. Aprovechan las ventajas de WebSockets y el respaldo a los mecanismos de comunicación más antiguos / intrincados para los navegadores web más antiguos.

Si su entorno va a ser una LAN y su cliente una aplicación .NET, entonces podría usar un TCPServer y múltiples TCPClients. Cuando su servidor web tenga una actualización / mensaje que enviar, avise a su TCPServer (quizás colocando un mensaje en un bus de mensajes que está escuchando) que puede informar a los clientes conectados. Las tecnologías web en tiempo real son una excelente manera de hacer esto, pero realmente depende de cuáles son sus requisitos actuales y cuáles son sus planes para el futuro:

• ¿Quieres probar SignalR ? Si es así, entonces funcionará y probablemente te divertirás mucho. También puede ser útil para proyectos futuros y ser una buena cadena en tu arco. Si no, un enfoque de TCPClient y TCPServer puede ser súper simple y más rápido de hacer.
• ¿Tiene algún requisito para que otros tipos de clientes web puedan recibir las notificaciones en el futuro? - Sí, SignalR u otra tecnología web en tiempo real y auto hospedada más madura podría ser una mejor solución. No - TCPServer / Cliente
• ¿Planea distribuir los datos fuera de su LAN? Sí, una opción o evento alojado por uno mismo, una solución hospedada con bibliotecas .NET puede ser la solución, ya que eliminan la sobrecarga de mantenimiento (Descargo de responsabilidad: trabajo para Pusher, que ofrece un servicio como este) . No - auto alojado o TCPServer / Cliente.
• ¿Cuánto importa la velocidad? Si realmente importa, una conexión TCP sin ningún tipo de sobrecarga será la opción más rápida. Las segundas mejores opciones serán WebSockets, luego HTTP Streaming seguido de HTTP Long-Polling.

Nota: Aunque estoy diciendo que TCPServer / Client podría ser el enfoque más simple, me gustaría enfatizar que también podría no serlo. Los WebSockets son una tecnología realmente emocionante y en muchos aspectos son más accesibles que la tecnología TCPClient, por lo que podría convertirse en la tecnología dominante para la comunicación bidireccional entre cualquier servidor y cliente *

No puedo comentar sobre los contratos dúplex, pero entendí que la conexión que establecieron no se mantuvo, por lo que en realidad son una solución de sondeo, podría estar equivocado.