Práctica recomendada para el cliente WCF Duplex

Question

No puedo negar el beneficio de rendimiento de una llamada asíncrona dúplex, pero algunas cosas me hacen sentir cauteloso.

Mi preocupación es que dado un objeto de cliente instanciado, ¿WCF podrá decir qué instancia de servicio de cliente particular recibirá el argumento de devolución de llamada?

¿Alguien me puede decir si esta es una buena idea? ¿Si no, porque no?

new DuplexChannelFactory<IServerWithCallback>(
    new ClientService(), 
    new NetTcpBinding(), 
    new EndpointAddress("net.tcp://localhost:1234/"+Guid.NewGuid())) 

1. Si la ruta de acceso virtual anterior está reservado cómo puede ser descartada. Quiero que la vida útil del servicio al cliente sea bastante corta. IE realiza una solicitud y recibe una respuesta, y cuando termine de recibirla, mátala. Qué tan grave es la penalización del rendimiento al hacer que el servicio al cliente sea corto en comparación con agruparlo y mantenerlo con vida por más tiempo.

   La idea es evitar el problema del tiempo de espera. Cuando termine de recibir, enviar, desechar lo antes posible. Por convención: no puede pasar los servicios del cliente. Si necesita información, cree una nueva, simple, como EF/L2S, etc.

2. Desde dentro del servicio WCF, ¿cómo puedo matar la sesión con el cliente? es decir. No quiero que el cliente finalice la sesión; sé que puedo decorar mi operación en consecuencia, pero quiero que el servicio se termine programáticamente cuando se cumplan ciertas condiciones.

3. Puedo fijar el puerto y reenviar en consecuencia para resolver cualquier problema del firewall, pero lo que me preocupa es si el cliente se sentara detrás de un equilibrador de carga. ¿Cómo sabría el servicio qué servidor particular llamar?

Answer 1

Creo que, al final, los servicios Duplex son simplemente otra arquitectura fallida de Microsoft. Esta es una de esas cosas que se veían muy bien en el papel, pero simplemente se desmorona al examinarla más de cerca.

Hay demasiados puntos débiles:

1) La dependencia de la sesión para establecer oyente cliente por el servidor.Esta es la información de la sesión que se almacena en la memoria. Por lo tanto, el servidor en sí no puede cargarse equilibrado. O si tiene equilibrio de carga, debe activar la afinidad IP, pero ahora, si uno de los servidores es bombardeado, no puede simplemente agregar otro y esperar que todas estas sesiones migren automágicamente al nuevo servidor.

2) Para cada cliente sentado detrás de un enrutador/firewall/loadbalancer, es necesario crear un nuevo punto final con un puerto específico. De lo contrario, el enrutador no podrá enrutar correctamente los mensajes de devolución de llamada al cliente apropiado. Una alternativa es tener un enrutador que permita la programación personalizada para redirigir la ruta específica a un servidor en particular. Otra vez una orden difícil. O bien, otra forma es que el cliente con la devolución de llamada pueda alojar su propia base de datos y compartir datos a través de una base de datos < - Podría funcionar en algunas situaciones donde las tarifas de licencia no son un problema ... pero introduce mucha complejidad y es oneroso el cliente más combina la capa de aplicaciones y servicios (lo que podría ser aceptable en algunas situaciones excepcionales, pero no en el costo de instalación)

3) Todo esto básicamente dice que el dúplex es prácticamente inútil. Si necesita una devolución de llamada, será mejor que configure un host wcf en el extremo del cliente. Será más simple y mucho más escalable. Además, hay menos acoplamiento entre el cliente y el servidor.

La mejor solución dúplex para arquitectura escalable al final no la usa.

Answer 2

1. Dependerá de lo corta que necesita los clientes new'd y cuánto tiempo durarán. La agrupación no sería una opción si necesita específicamente un cliente nuevo cada vez, pero si los clientes siguen haciendo lo mismo, por qué no tienen un grupo de ellos esperando para ser utilizados, si fallan, recreen ese mismo cliente nuevamente.

2. En realidad, en un escenario de devolución de llamada si el servicio llama al cliente (realmente llama a una función en el cliente) para pasar información, el servicio ahora es el cliente y viceversa. Puede tener el servicio que realiza la devolución de llamada. Cerrar() la conexión, pero estará abierta hasta que el GC pueda deshacerse de ella, según mi experiencia, puede llevar más tiempo de lo esperado. En resumen, el cliente debe ser responsable (el cliente es el que realiza la llamada a algo) para desconectarse o desconectarse, el servicio solo debe devolver respuestas o tomar datos de un cliente.

3. En devoluciones de llamada dúplex, el servicio que vuelve a llamar al cliente obtendrá la dirección del cliente abstraída detrás de duplexchannelfactory. Si el servicio no puede devolver la llamada al cliente, no creo que haya mucho que se pueda hacer, debe asegurarse de que el puerto al que llaman sus clientes esté abierto para recibir devoluciones de llamadas, supongo.