Servidor de socket asíncrono frente a síncrono para la aplicación en tiempo real

Question

Actualmente estoy desarrollando un servidor de socket C# que necesita enviar y recibir comandos para un proceso en tiempo real. El cliente es un dispositivo Android. Actualmente, los requisitos en tiempo real son "suaves", sin embargo, en el futuro pueden surgir requisitos de temporización más estrictos. Digamos que en el futuro podría ser enviar comandos a una grúa que podría ser potencialmente peligrosa.

El servidor está funcionando, y aparentemente muy bien con mi diseño actual servidor de socket sincrónico. Tengo hilos separados para recibir y enviar datos. Me pregunto si habría alguna razón para intentar un enfoque de socket de servidor asíncrono. ¿Podría proporcionar más estabilidad y/o un rendimiento más rápido?

Answer 1

voy a pasar por alto la definición de tiempo real y dicen que tomas asíncronos no hará que el cuerpo del proceso de solicitud más rápido, pero aumentará la concurrencia (el número de solicitudes se puede tomar en cualquier momento). Si todos los procesadores están ocupados procesando algo, no obtendrás ninguna ganancia. Esto solo le da ganancia en la situación en la que un procesador se habría sentado esperando que un socket reciba algo.

Sólo una nota en tiempo real, si sus requerimientos de tiempo real son algo como la necesidad de garantizar una respuesta en tiempo x, entonces C# y .NET no le dará esas garantías. Esto, sin embargo, depende de sus definiciones actuales y futuras de "soft". Puede ocurrir que ocurra obteniendo buenos tiempos de respuesta, pero no lo confunda con sistemas reales en tiempo real.

Answer 2

Si va a dudar de la utilidad de algo asíncrona en sus aplicaciones, entonces definitivamente debe leer sobre this. Se le da una idea clara de lo que las soluciones asíncronas podrían agregar a sus aplicaciones

Answer 3

No creo que se va a conseguir más estabilidad o rendimiento más rápido. Si realmente es un sistema en "tiempo real", entonces debería ser sincrónico. Si puede tolerar "casi en tiempo real" y hay operaciones de computación costosas o de larga ejecución, entonces podría considerar un enfoque asincrónico. Sin embargo, no agregaría la complejidad si no fuera necesario.

Answer 4

Si es en tiempo real, a continuación, a pesar de todo quiere que sus comunicaciones a ser respaldados por una cola para que pueda demostrar lógica temporal en esa cola. Esto es lo que le proporciona nio/io-completion-ports/async. Si está utilizando una programación sincrónica, está desperdiciando su CPU al copiar datos de la RAM a la tarjeta de red.

Además, significa que su servidor es absolutamente único subproceso. Puede tener un solo hilo incluso con asincronización, pero aún así poder atender miles de solicitudes.

Digamos, por ejemplo, que un cliente quería realizar un ataque de DOS. Se conectaría y enviaría un byte de datos. Su aplicación ahora no podrá recibir más comandos por el tiempo de espera de esa conexión, que podría ser bastante grande. Con la función asincrónica, ACK devolverá el paquete SYN, pero su código no estaría esperando la transmisión completa.