¿Qué usa cuando necesita UDP confiable?

Si tiene una situación en la que una conexión TCP es potencialmente demasiado lenta y una 'conexión' UDP es potencialmente demasiado poco confiable, ¿qué usa? Existen varios protocolos UDP estándar confiables, ¿qué experiencias tiene con ellos?

Por favor, discuta un protocolo por respuesta y si alguien más ya mencionó el que usted usa, considere votarlo y usar un comentario para explicarlo si es necesario.

Estoy interesado en las diversas opciones aquí, de las cuales TCP está en un extremo de la escala y UDP en el otro. Hay varias opciones UDP confiables disponibles y cada una trae algunos elementos de TCP a UDP.

Sé que, a menudo, TCP es la elección correcta, pero tener una lista de alternativas suele ser útil para llegar a esa conclusión. Cosas como Enet, RUDP, etc.que se basan en UDP tienen varios pros y contras, ¿las ha usado, cuáles son sus experiencias?

Para evitar dudas, no hay más información, esta es una pregunta hipotética y esperaba que obtuviera una lista de respuestas que detallara las diversas opciones y alternativas disponibles para alguien que necesita tomar una decisión.

Es difícil responder a esta pregunta sin alguna información adicional sobre el dominio del problema. Por ejemplo, ¿qué volumen de datos está utilizando? ¿Con qué frecuencia? ¿Cuál es la naturaleza de los datos? (por ejemplo, ¿es único, datos puntuales? ¿O es un flujo de datos de muestra? etc.) ¿Para qué plataforma está desarrollando? (por ejemplo, escritorio / servidor / integrado) Para determinar qué quiere decir con "demasiado lento", ¿qué medio de red está utilizando?

Pero en términos (¡muy!) Generales, creo que tendrás que esforzarte mucho para vencer a tcp en velocidad, a menos que puedas hacer algunas suposiciones sobre los datos que estás tratando de enviar.

Por ejemplo, si los datos que está intentando enviar son tales que puede tolerar la pérdida de un solo paquete (por ejemplo, datos muestreados regularmente donde la frecuencia de muestreo es muchas veces mayor que el ancho de banda de la señal), probablemente pueda sacrifique cierta confiabilidad de la transmisión al asegurarse de que puede detectar la corrupción de datos (por ejemplo, mediante el uso de una buena crc)

Pero si no puede tolerar la pérdida de un solo paquete, entonces tendrá que comenzar a introducir los tipos de técnicas de confiabilidad que ya tiene tcp. Y, sin poner una cantidad razonable de trabajo, es posible que empiece a integrar esos elementos en una solución de espacio de usuario con todos los problemas de velocidad inherentes que la acompañan.

¿Qué pasa con SCTP ? Es un protocolo estándar del IETF (RFC 4960)

Tiene capacidad de fragmentación que podría ayudar a aumentar la velocidad.

Actualización: una comparación entre TCP y SCTP muestra que los rendimientos son comparables a menos que se puedan usar dos interfaces.

Actualización: un buen artículo introductorio .

ENET - http://enet.bespin.org/

Trabajé con ENET como un protocolo UDP confiable y escribí una versión compatible con sockets asíncronos para un cliente mío que lo está usando en sus servidores. Funciona bastante bien, pero no me gusta la sobrecarga que el ping peer to peer agrega a las conexiones inactivas; cuando tienes muchas conexiones, hacer ping a todas ellas regularmente es un trabajo muy intenso.

ENET le brinda la opción de enviar múltiples 'canales' de datos y que los datos enviados no sean confiables, confiables o estén secuenciados. También incluye el ping peer to peer mencionado anteriormente que actúa como un mantener vivo.

Tenemos algunos clientes de la industria de defensa que utilizan UDT (transferencia de datos basada en UDP) (consulte http://udt.sourceforge.net/ ) y están muy contentos con él. Veo que también tiene una licencia BSD amigable.

RUDP - Protocolo de datagramas de usuario confiable

Esto proporciona:

• Reconocimiento de paquetes recibidos
• Control de ventanas y congestión
• Retransmisión de paquetes perdidos
• Overbuffering (más rápido que la transmisión en tiempo real)

Parece un poco más configurable con respecto a mantener vivo que ENet, pero no le brinda tantas opciones (es decir, todos los datos son confiables y están secuenciados, no solo los bits que usted decide que deben ser). Parece bastante sencillo de implementar.

Como han señalado otros, su pregunta es muy general, y si algo es 'más rápido' que TCP depende mucho del tipo de aplicación.

TCP es generalmente lo más rápido posible para la transmisión confiable de datos de un host a otro. Sin embargo, si su aplicación realiza una gran cantidad de pequeñas ráfagas de tráfico y espera respuestas, UDP puede ser más apropiado para minimizar la latencia.

Hay un término medio fácil. El algoritmo de Nagle es la parte de TCP que ayuda a garantizar que el remitente no abrume al receptor de un gran flujo de datos, lo que resulta en congestión y pérdida de paquetes.

Si necesita la entrega confiable y en orden de TCP, y también la respuesta rápida de UDP, y no necesita preocuparse por la congestión al enviar grandes flujos de datos, puede deshabilitar el algoritmo de Nagle:

int opt = -1;
if (setsockopt(sock_fd, IPPROTO_TCP, TCP_NODELAY, (char *)&opt, sizeof(opt)))
  printf("Error disabling Nagle's algorithm.\n");

Cualquiera que decida que la lista anterior no es suficiente y que quiere desarrollar su PROPIO UDP confiable definitivamente debería echar un vistazo a la especificación QUIC de Google, ya que cubre muchos casos complicados y posibles ataques de denegación de servicio. No he jugado con una implementación de esto todavía, y es posible que no desee o necesite todo lo que proporciona, pero vale la pena leer el documento antes de embarcarse en un nuevo diseño UDP "confiable".

Un buen punto de partida para QUIC está aquí , en el Blog de Chromium.

El documento de diseño QUIC actual se puede encontrar aquí .

Si tiene una situación en la que una conexión TCP es potencialmente demasiado lenta y una 'conexión' UDP es potencialmente demasiado poco confiable, ¿qué usa? Existen varios protocolos UDP estándar confiables, ¿qué experiencias tiene con ellos?

La palabra clave en su oración es "potencialmente". Creo que realmente necesita demostrarse a sí mismo que TCP es, de hecho, demasiado lento para sus necesidades si necesita confiabilidad en su protocolo.

Si desea obtener confiabilidad de UDP, entonces básicamente volverá a implementar algunas de las características de TCP además de UDP, lo que probablemente hará que las cosas sean más lentas que simplemente usar TCP en primer lugar.

El protocolo DCCP, estandarizado en RFC 4340 , "Protocolo de control de congestión de datagramas" puede ser lo que está buscando.

Parece implementado en Linux .

Puede que RFC 5405 , "Pautas de uso de Unicast UDP para diseñadores de aplicaciones", le resulte útil.

¿Consideró comprimir sus datos?

Como se indicó anteriormente, carecemos de información sobre la naturaleza exacta de su problema, pero comprimir los datos para transportarlos podría ayudar.

RUDP . Muchos servidores de socket para juegos implementan algo similar.

La mejor manera de lograr confiabilidad usando UDP es construir la confiabilidad en el programa de aplicación en sí (por ejemplo, agregando mecanismos de reconocimiento y retransmisión)