Investigación de soluciones para notificar a los clientes de WPF desde el servidor

Question

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

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

Nunca he tenido este requisito antes y estoy investigando soluciones. Mi primer pensamiento fue utilizar SignalR con el .NET client. Todavía no he trabajado con SignalR, pero parece que podría ser una solución. Soy consciente de que se trata de una abstracción de los eventos enviados por el servidor y WebSockets de larga duración, según lo que esté disponible.

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

Answer 1

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 mantenerse al tanto de las acciones realizadas por los otros clientes.

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

La razón detrás del uso de un servicio web completamente separado se debe al hecho de que todas nuestras conexiones existentes existentes se establecen y se eliminan en cada llamada. Con el servicio web de notificación, las conexiones deben mantenerse siempre que los clientes se ejecuten.

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

Answer 2

Esto se puede hacer bastante fácilmente con WCF y duplex contracts. 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). En cuanto al código, ambas son simples llamadas a métodos. El cliente tiene métodos que llaman a operaciones en el servidor y también debe proporcionar un objeto que implementa el contrato de devolución de llamada, que es una interfaz que el servidor puede llamar y para la cual el cliente debe proporcionar una implementación. Toda la serialización/deserialización de datos y mensajes y todas las operaciones de red de bajo nivel están a cargo de WCF, por lo que no tendrá que preocuparse por ello.

WCF apoya contratos dúplex mediante dos fijaciones (o 'protocolos'):

1. WSDualHttpBinding - Esto implica dos oyentes HTTP basados ​​en SOAP, una en el servidor y uno en el cliente. Cuando el cliente desea contactarse 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 con 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 para 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 other answer.

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 por NAT, pero como las conexiones deben mantenerse abiertas, es algo más una carga para el servidor y, por lo tanto, será capaz de 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 el código. Todo lo que se requiere es cambiar la configuración (archivo .config).

De cualquier forma que elija, podrá realizar comunicaciones casi instantáneas en ambas direcciones (latencia de red lo permite, por supuesto). No veo la necesidad de SignalR cuando tienes un marco tan rico, potente y fácil de usar como WCF a tu disposición. Si tuviera problemas al ejecutar en un navegador, entonces SignalR tendría sentido. Como estás ejecutando en .NET, solo introduciría una fricción innecesaria.

Answer 3

Debería consultar WebSync de Frozen Mountain. Lo he usado en el pasado con excelentes resultados. Hace todo lo que necesita. Incluso ofrecen un servicio alojado 'WebSync on Demand'. También ofrecen un producto gratis (pero hasta 10 usuarios concurrentes). Es un producto comercial. Si no quiere hacer todas las conexiones, WebSync le ofrece aplicaciones listas para usar que puede comenzar a utilizar y ponerse en marcha rápidamente. He oído/leído sobre SignalR, todavía no lo he usado, pero SignalR parece estar en alpha/beta, mientras que WebSync está muy maduro.

Answer 4

Puede crear un servicio wcf donde los clientes wpf se registren en el inicio. Entonces, 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/identificación única. En el lado del servidor, puede tener un servicio que envíe datos a las colas, ya que los datos están disponibles en función de las condiciones establecidas para cada cliente.

Answer 5

El objetivo de tecnologías como SignalR es satisfacer la demanda de comunicación en tiempo real entre servidores y clientes web. Aprovechan WebSockets y recurren a mecanismos de comunicación más viejos/piratas para 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 para enviar, dígale a su TCPServer (tal vez poniendo un mensaje en un bus de mensajes que está escuchando) que puede informar al cliente (s) conectado (s). tecnologías web en tiempo real son una gran manera de hacer esto pero realmente depende de lo que sus requisitos actuales son y cuáles son sus planes para el futuro son:

• ¿Quieres probar SignalR - Si es así, entonces es Trabajaré y probablemente te diviertas mucho. También podría ser útil para proyectos futuros y ser una buena cadena en tu arco. Si no, un enfoque TCPClient y TCPServer podría ser super simple y más rápido de hacer.
• ¿Tiene algún requisito para que otros tipos de clientes web puedan recibir notificaciones en el futuro? - sí, SignalR u otra más madura self hosted realtime web technology podría ser una solución mejor.No - TCPServer/Cliente
• ¿Piensa distribuir los datos fuera de su LAN? Sí - una opción alojada o un evento a hosted solution con bibliotecas .NET puede ser el camino a seguir, ya que eliminan la sobrecarga de mantenimiento (Descargo de responsabilidad: yo trabajo para Pusher que ofrecen un servicio como este). No - autohospedado o TCPServer/Cliente.
• ¿Cuánto cuesta la velocidad? Si realmente importa , la opción más rápida será una conexión TCP sin gastos generales. La segunda mejor opción será WebSockets, luego HTTP Streaming seguido de HTTP Long-Polling.

Nota: A pesar de que estoy diciendo TCPServer/cliente podría ser el enfoque más simple que me gustaría hacer hincapié en que también podría no ser. WebSockets son una tecnología muy emocionante y son en muchos aspectos más accesible que la tecnología TCPClient así podría convertirse en la tecnología dominante para la comunicación bidireccional entre cualquier servidor y el cliente *

No puedo comentar sobre los contratos Dúplex pero mi entendimiento estaba que la conexión que establecen no se mantuvo, por lo que en realidad son una solución de votación; podría estar equivocado.

Answer 6

También estaba evaluando una forma ligera pero fácil de comunicar eventos a clientes WPF utilizando un servicio pub/sub. No exigí la entrega garantizada de mensajes, por lo que las soluciones como MassTransit o NServiceBus parecían demasiado pesadas porque requieren que haya filas disponibles (MSMQ u otras). También tuve el requisito de que la solución esté disponible como .NET 4.0 Client Profile.

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

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