Todo lo que he leído sobre sockets en .NET dice que el patrón asíncrono ofrece un mejor rendimiento (especialmente con el nuevo SocketAsyncEventArgs que ahorra en la asignación).Sincronización vs. Async Sockets Performance en .NET
Creo que esto tiene sentido si estamos hablando de un servidor con muchas conexiones de clientes donde no es posible asignar un hilo por conexión. Luego puedo ver la ventaja de utilizar los subprocesos de ThreadPool y obtener devoluciones de llamada asíncronas.
Pero en mi aplicación, soy el cliente y solo necesito escuchar a un servidor que envía datos de marcas del mercado a través de una conexión tcp. En este momento, creo un único hilo, establezco la prioridad en Más Alto y llamo a Socket.Receive() con él. Mi hilo bloquea en esta llamada y se despierta una vez que llegan nuevos datos.
Si tuviera que cambiar esto a un patrón asincrónico de modo que consiga una devolución de llamada cuando no hay nuevos datos, veo dos problemas
Los hilos ThreadPool tendrá prioridad por defecto por lo que parece que será estrictamente peor que mi propio hilo, que tiene la más alta prioridad.
Todavía tendré que enviar todo a través de un único hilo en algún momento. Digamos que obtengo N devoluciones de llamada casi al mismo tiempo en N subprocesos de subprocesos diferentes que me notifican que hay nuevos datos. Las matrices de N byte que entregan no se pueden procesar en los subprocesos de subprocesos porque no hay garantía de que representen N mensajes de datos de mercado únicos porque TCP se basa en secuencias. Tendré que bloquear y poner los bytes en una matriz de todos modos y señalar algún otro hilo que pueda procesar lo que hay en la matriz. Así que no estoy seguro de qué es lo que tiene N hilos de rosca me está comprando.
¿Estoy pensando en esto mal? ¿Hay alguna razón para usar el patrón Async en mi caso específico de un cliente conectado a un servidor?
ACTUALIZACIÓN:
Así que creo que era malentendidos en el patrón asincrónico (2) anterior. Me gustaría recibir una devolución de llamada en un hilo de trabajo cuando había datos disponibles. Entonces comenzaría otra recepción asíncrona y recibiría otra devolución de llamada, etc. No obtendría N devoluciones de llamada al mismo tiempo.
La pregunta sigue siendo la misma. ¿Hay alguna razón por la cual las devoluciones de llamada serían mejores en mi situación específica donde soy el cliente y solo estoy conectado a un servidor?
Gracias por su respuesta. Tienes razón, miraba mal este ejemplo. Así que empiezo y recibo una devolución de llamada en algún subproceso de subprocesos cuando hay datos. Entonces lo proceso y puedo decidir que quiero seguir escuchando por más y obtener otra devolución de llamada. Pero incluso si este es el caso, no veo cómo esto podría ser más rápido que solo tener un hilo de alta prioridad dedicado a hacer el Receive(). –
En primer lugar, evitaría establecer la prioridad de los hilos. Estoy bastante seguro de que generalmente no es recomendable. Es mejor dejar que todos los hilos que tienen trabajo que hacer obtengan igual acceso a la CPU. En segundo lugar, mi punto es que * * no * será más rápido. El valor de las API asíncronas es que le permiten evitar bloquear un hilo (un recurso costoso debido al tamaño de una pila de llamadas) en espera pura, y si solo tiene una conexión y un hilo, y nada que hacer hasta que usted recuperar los datos, entonces realmente no hay un gran costo en la vinculación de un hilo. La excepción es si usa Silverlight, ya que solo tiene asincrónico. –
"Más rápido" es casi completamente discutible en este escenario, porque este tipo de opciones se perderán en el ruido en comparación con el costo de la comunicación de la red en sí.Literalmente, no se gana nada en el rendimiento cambiando entre estas técnicas. –