TCP vs UDP confiable

Question

Estoy escribiendo una aplicación donde el lado del cliente cargará datos al servidor a través de un enlace inalámbrico.

La conexión debe ser muy confiable. Se espera que el enlace se interrumpa muchas veces y que haya muchos clientes conectados al servidor.

No sé si usar TCP o UDP confiable.

Por favor, comparta sus ideas.

Gracias.

Answer 1

RUDP no es, por supuesto, un estándar formal, y no hay forma de saber si encontrará implementaciones existentes que pueda usar. Dada la opción entre rodar esto desde cero y simplemente volver a hacer conexiones TCP, elegí TCP.

Answer 2

Para estar seguro, me gustaría ir con TCP solo porque es un protocolo confiable y estándar. RUDP tiene la desventaja de no ser un estándar establecido (aunque ha sido mencionado en varias discusiones de IETF).

¡Buena suerte con su proyecto!

Answer 3

Si no está seguro, lo más probable es que deba usar TCP. Por un lado, es seguro que será parte de la pila de red para cualquier cosa que soporte IP. El "UDP confiable" rara vez se admite de forma inmediata, por lo que tendrá un trabajo de soporte adicional para sus clientes.

Answer 4

Es probable que tanto sus enlaces TCP como RUDP se rompan en su entorno, por lo que es poco probable que el hecho de que esté utilizando RUDP ayude; es probable que haya ocasiones en que ningún datagrama pueda pasar ...

Lo que realmente necesita asegurarse es que a) puede manejar la cantidad de clientes conectados, b) el protocolo de su aplicación puede detectar razonablemente rápidamente cuando Ha perdido la conectividad con un cliente (o servidor) yc) puede manejar la reconexión necesaria y el mantenimiento del estado de la sesión de conexión cruzada para los clientes.

Mientras se ocupen de b) yc) en realidad no importa si la conexión se sigue rompiendo. Asegúrese de diseñar su protocolo de aplicación para que pueda hacer las cosas en lotes cortos; entonces, si está cargando archivos, asegúrese de enviar bloques pequeños y de que el protocolo de la aplicación pueda reanudar una transferencia interrumpida hasta la mitad; no desea obtener el 99% del camino a través de una transferencia de 2 gb y perder la conexión y tener que comenzar de nuevo.

Para que esto funcione su servidor necesita algún tipo de caché de estado de sesión de cliente donde puede mantener el estado lógico de la conexión de un cliente más allá de la duración de la conexión. Diseñe desde el principio para esperar que una sesión determinada incluya múltiples conexiones separadas. El estado de la sesión posiblemente tenga algún tipo de tiempo de espera, por lo que si el cliente se va por mucho tiempo no continúa consumiendo recursos en el servidor, pero para ser honesto, puede ser simplemente un caso de guardar el estado en el disco después de Un rato.

En resumen, no creo que la elección del transporte importe e intente con TCP al menos para empezar. Lo que realmente importará es poder administrar el estado de la sesión de su cliente en el servidor y lidiar con el hecho de que los clientes se conectarán y desconectarán regularmente.