2011-06-02 14 views
14

Soy nuevo en la programación del zócalo (como ya entendiste por mi pregunta tonta), pero manteniendo mi vergüenza a un lado, estoy escribiendo un programa usando TCP posix. Mi restricción es la siguiente: el mensaje que se enviará del cliente al servidor se debe leer como transmisión de bytes y, aunque mi aplicación no es de alto rendimiento, el mensaje se debe entregar lo antes posible. Escribí una clase de cliente TCP con la intención de hacer lo siguiente: 1 conectar - muchos enviar - y 1 cerrar al final de la transmisión. El problema es que los mensajes no se entregan casi en tiempo real (supongo que espera tener un paquete más grande para un mejor rendimiento de ) Después de investigar un poco en línea, descubrí que si bien se puede desactivar el algoritmo Nagle (NA), es una muy mala idea hacerlo. Como soy nuevo en la programación de socket, no quiero desactivar funciones que no entiendo completamente. Así que me quedo con dos malas (?) Opciones:N * (conectar + enviar + cerrar) vs (Nagle desactivar + conectar + N * enviar + cerrar), N> 1

  1. Connect - Enviar- cerca por mensaje
  2. 1 Connect - enviar varias veces y hacer 1 cerrar al final con la AN discapacitados. Mientras leo las consecuencias de deshabilitar el NA, me parece que abrir y cerrar un socket cada vez solo para enviar un mensaje es un precio caro para pagar también.

¿Hay otras soluciones sin dejar zócalos?

Gracias.

+7

+1 por hacer una buena investigación antes de preguntar. – Nemo

Respuesta

12

En su caso, deshabilitar Nagle es exactamente lo que desea hacer.

Solo recuerde que cada llamada para escribir() va a transmitir sus datos de inmediato. Así que asegúrese de empacar todo su mensaje y luego llamar a write() (o writev()) una vez cuando esté listo para enviar; no llame a write() repetidamente con pequeñas cargas porque eso será lento.

Situaciones como la suya son exactamente la razón por la que le permiten desactivar Nagle.

+0

Estoy de acuerdo. Deshabilitar Nagle es mucho mejor que hacer un manojo de manos adicionales de tres vías, más paquetes FIN adicionales. –

2

@Nemo ha dado excelentes consejos para TCP.

Pero sugiero que mire UDP en su lugar. TCP puede introducir un retardo arbitrario durante la pérdida de paquetes, y la "equidad TCP" funciona para forzar la pérdida de paquetes. No es ideal para transferencias de baja latencia. Querer inhabilitar Nagle es un fuerte signo de que está utilizando el protocolo incorrecto.

+0

Esa fue mi reacción inicial, pero la restricción que me alejó del UDP es la información de datos. Datum tiene que llegar en orden y corregir ... de lo contrario, la aplicación no tendrá sentido. – Armando

+1

@Armando: si quiere oportuna Y correcta, su elección parece ser FEC. Un simple "enviar copias múltiples de cada paquete" debería ser suficiente. Con los números de secuencia, puede descartar los duplicados y garantizar el orden correcto. Si varias copias de cada paquete desperdiciarían demasiado ancho de banda, puede usar algún código de corrección de errores, cuya paridad es la más simple (nota, ejecútelo en paquetes, ya que es probable que un paquete completo desaparezca de inmediato). –

+1

FEC = Corrección de error de reenvío, por cierto, enviando más información por adelantado para que se pueda corregir una cantidad significativa de errores de transmisión del lado del receptor. Esto mejora la latencia a costa del ancho de banda. La recuperación de errores de TCP implica reenviar los datos, lo que optimiza el ancho de banda en lugar de la latencia. – MSalters