.net - poner - ¿Cómo restablezco automáticamente un canal dúplex si falla?
que va en etiquetas de youtube (4)
Estoy desarrollando una aplicación cliente / servidor en .Net 3.5 usando WCF. Básicamente, un servicio de cliente de larga ejecución (en varias máquinas) establece una conexión dúplex con el servidor a través de un netTcpBinding. Luego, el servidor usa el contrato de devolución de llamada del cliente para realizar ciertas oraciones a pedido, a las cuales el cliente responde de manera asíncrona (creo que es bastante estándar). Subclases la clase DuplexClientBase para manejar la mayor parte de la comunicación.
Desafortunadamente, cuando algo sale mal en cualquiera de los extremos (como una falla de la red, una excepción inesperada, etc.), el canal recibe una falla / se interrumpe y todas las operaciones posteriores fallan. He superado esta limitación en canales no dúplex al crear una clase RecoveringClientBase que se activa automáticamente cuando el cliente ha fallado y vuelve a intentar la operación.
Entonces mi pregunta es, ¿existe una forma establecida de determinar cuándo ha fallado un canal dúplex? ¿Dónde debo verificar esto, en el servidor o el cliente? En su defecto, ¿qué opciones tengo para garantizar que la conexión se restablezca?
Actualización: estoy buscando algún consejo específico para los canales dúplex, donde el servidor podría tratar de usar un canal de devolución de llamada que tuvo una falla. Por lo tanto, necesito algo que se vuelva a conectar / volver a suscribir inmediatamente cuando algo le pase al canal. En este momento, estoy escuchando el evento de cierre del canal y lo recreé si el estado no es Cerrado. Funciona de cierta manera, pero se siente raro ...
Nicolas Allen, del equipo WCF tiene sugerencias para esto:
http://blogs.msdn.com/drnick/archive/2007/11/05/custom-transport-retry-logic.aspx
Su sugerencia es manejar esto a nivel de canal. El nivel de canal es un poco más agradable, ya que puedes conectarlo a la pila de cualquier enlace a través de comportamientos en lugar de requerir una clase base de cliente personalizada.
He tenido algunos problemas similares, y para mí parece que estas llamadas de larga duración son más o menos incompatibles.
WCF parece estar diseñado para ser utilizado para llamadas de corta duración. Los servicios, que se llaman, hacen algunas cosas pequeñas y terminan.
Refactoré mis aplicaciones en pequeños artículos de trabajo. Entonces, en lugar de un artículo de larga ejecución, ahora tengo muchos artículos más pequeños. Por supuesto, a veces esto no es posible de lograr. Luego tuve que orar por conexiones de red estables (se pueden detectar excepciones, por lo que creo que las fallas no son realmente un problema).
He experimentado escamas en sesiones de larga duración (minutos-horas). No puedo estar seguro de que sea WCF, estoy bastante seguro de su nivel de red.
Estoy pensando en eliminar completamente el dúplex. Es una verdadera molestia intentar administrar el estado de la conexión.
Estoy pensando en alojar un punto final de servicio en el cliente para las operaciones que actualmente forman parte del contrato de devolución de llamada. El cliente se pondría en contacto con el servidor con los detalles del punto final, el servidor puede almacenarlos en algún lugar (persistente o donde sea). Cuando el servidor necesita contactar al cliente, abre una conexión con el cliente a través de los detalles del punto final oculto. Básicamente, convertir la conexión dúplex en 2 conexiones cliente-servidor.
No responde tu pregunta, pero siento tu dolor.
Creo que deberías escuchar un evento fallado. Puedes escucharlo en ambos extremos, el extremo del cliente creo que ya lo estás manejando, el final del servidor es OperationContext.Current.Channel.events.
No he encontrado una forma de reenviar un mensaje automáticamente porque su canal de devolución de llamada ya tiene una falla y aún no conoce el nuevo canal de devolución de llamada, pero necesita mantener estas llamadas en algún lugar del servidor hasta que el cliente se vuelva a conectar.
Los clientes recibirán una falla eventualmente y deben volver a realizar el protocolo de enlace con el servidor, que es el punto que el servidor debe enviar llamadas no enviadas.
Básicamente, la única forma de recuperarse de un canal con falla / cerrado es reemplazarlo por uno nuevo, sin embargo, la parte más importante es que realmente debes detectar la desconexión a la HORA, he encontrado que habilitar la sesión confiable levantará el evento fallado a tiempo. caso. Alternativamente, puede enviar mensajes de latido en ambos extremos para "probar" el canal con fallas.