prueba de conectividad de servidor de inserción WCF. Silbido()?

Question

Usando técnicas como insinuado en:

http://msdn.microsoft.com /en-us/library/system.servicemodel.servicecontractattribute.callbackcontract.aspx

Me estoy poniendo en práctica una configuración ServerPush para mi API para obtener notificaciones en tiempo real desde un servidor de eventos (sin sondeo). Básicamente, el servidor tiene un método RegisterMe () y UnregisterMe () y el cliente tiene un método de devolución de llamada llama Anuncio (mensaje de cadena) que, a través de los mecanismos CallbackContract en WCF, el servidor puede llamar. Esto parece funcionar bien.

Por desgracia, en esta configuración, si el servidor llegara a fallar o es de otro modo disponible, el cliente no sabe ya que sólo está a la escucha de mensajes. Silencio en la línea podría significar no hay anuncios o podría significar que el servidor no está disponible.

Desde mi objetivo es reducir de votación en lugar de inmediatez, no me importa la adición de un método vacío Ping () en el servidor junto RegisterMe () y UnregisterMe () que sólo existe para probar la conectividad de al servidor. Periódicamente pruebas de este método aseguraría, creo que todavía estamos conectados (y también que no hay anuncios han dejado caer por el transporte, ya que este es TCP)

Pero es el método ping () es necesario o de lo contrario esta prueba de conectividad disponible como parte de WCF por defecto - como serverProxy.IsStillConnected () o algo así. Como yo lo entiendo, el estado del canal sólo volvería Faulted o cerrado después de un fallido Ping (), pero no en lugar de ella.

2) Desde una perspectiva más amplia, es sólido este método de devolución de llamada? Esto no es para http o ajax - el número de clientes conectados será pocos (decenas de clientes, como máximo). ¿Hay serios problemas con este enfoque? Como esto parece ser un riesgo leve, ¿cómo puedo limitar a un cliente lento / malicioso de bloqueo del servidor en el procesamiento no es cola de devolución de llamada lo suficientemente rápido? ¿Hay una especie de tiempo de espera específico para la devolución de llamada que pueda establecer sin afectar a otras operaciones?

Answer 1

Su enfoque parece razonable, aquí hay algunos enlaces que pueden o no pueden ayudar (no son exactamente muy relacionadas):

La detección de la muerte de cliente en los contratos de WCF Dúplex http://tomasz.janczuk.org/2009/ 08 / rendimiento-of-http-polling-duplex.html

Tener un poco de control de salud integrado en su protocolo de aplicación tiene sentido.

Si usted está preocupado acerca de los clientes maliciosos, a continuación, añadir la autorización.

El segundo enlace compartí anteriormente tiene un servidor pub / sub muestra, es posible que pueda utilizar este código. Un par de cosas a tener en cuenta - considere empujando las notificaciones a través de llamadas asíncronas o en un hilo separado. Y establecer el SendTimeout sobre la unión del TCP.

HTH

Answer 2

Me escribió una aplicación WCF y me encontré con un problema similar. Mis clientes del servidor controladas no habían 'plug tirado' enviando periódicamente un ping a ellos. El método de envío real (que era asíncrono siendo un servidor) tenía un tiempo de espera de 30 segundos. El cliente simplemente comprueba que reciben los datos cada 30 segundos, mientras que el servidor podría capturar una excepción si se alcanza el tiempo de espera.

La autorización se requiere para conectarse al servidor (mediante el uso de la característica incorporada de WCF que obligan a la persona que se conecta a llamar a un método en particular en primer lugar) por lo que desde la perspectiva del cliente malicioso fácilmente se podría añadir el código para comprobar y prohibir su cuenta si hacen algo sospechoso, mientras que desconectar los usuarios que no se autentican.

Como el servidor que escribí fue asincrónica, no había ninguna manera de bloquear realmente. Supongo que aborda su último punto, como los incendios método Send asíncronos fuera de la mesa de ping (y cualquier otro envío de datos) y devuelve inmediatamente. En el método SendEnd sería detectar la excepción de tiempo de espera (en ocasiones múltiples para el cliente) y desconectarlos, sin ningún tipo de bloqueo o congelación del servidor.

Espero que ayude.

Answer 3

Se puede usar un servicio de editor / suscriptor similar a la sugerida por Juval: http://msdn.microsoft.com/en-us/magazine/cc163537. aspx

Esto le permitiría a persistir los abonados si perder el servidor es un escenario típico. El método de publicar en este ejemplo también se llama a cada uno de abonados en un hilo separado, por lo que unos pocos abonados muertos no bloqueará otros ...