tcp - comandos - Métodos para implementar UDP multicast confiable

clusvcadm (2)

Cada cliente envía acuse de recibo de esos paquetes (usando TCP)

Enviar un ACK para cada paquete y usar TCP para hacerlo, no es escalable para una gran cantidad de receptores. Usar un esquema basado en NACK es más eficiente.

Cada paquete enviado desde el servidor debe tener un número de secuencia asociado. A medida que los clientes los reciben, realizan un seguimiento de los números de secuencia que se perdieron. Si se pierden paquetes, un mensaje NACK puede enviarse al servidor a través de UDP. Este NACK se puede formatear como una lista de números de secuencia o un mapa de bits de números de secuencia recibidos / no recibidos.

Si el servidor se da cuenta de que no todos reciben paquetes, reenvía multidifusión o unicast a un cliente en particular

Cuando el servidor recibe un NACK, no debe volver a enviar inmediatamente los paquetes que faltan, sino esperar durante un período de tiempo, generalmente un múltiplo del GRTT (Tiempo de ida y vuelta del grupo - el mayor tiempo de ida y vuelta entre el receptor). Eso le da tiempo para acumular NACK de otros receptores. Luego, el servidor puede enviar por multidifusión los paquetes faltantes para que los clientes que no los tengan puedan recibirlos.

Si este esquema se usa para transferir archivos en lugar de transmitir datos, el servidor puede enviar alternativamente los datos del archivo en pases. El archivo completo se envía en la primera pasada, durante la cual se acumulan los NACK que se reciben y se marcan los paquetes que deben reenviarse. Luego, en pases posteriores, solo se envían retransmisiones. Esto tiene la ventaja de que los clientes con menores tasas de pérdida tendrán la oportunidad de terminar de recibir el archivo, mientras que los receptores de alta pérdida pueden seguir recibiendo retransmisiones.

El problema es que puede haber un cliente que generalmente pierde paquetes y obliga al servidor a volver a enviar.

Para clientes con pérdidas muy altas, el servidor puede establecer un umbral para el porcentaje máximo de paquetes perdidos. Si un cliente devuelve NACKs en exceso de ese umbral una o más veces (cuántas veces depende del servidor), el servidor puede eliminar ese cliente y no aceptar sus NACK o enviar un mensaje a ese cliente informándole que fue caído.

Hay una serie de protocolos que implementan estas características:

RFCs relevantes:

Me estoy preparando para mi examen de la universidad y una de las preguntas del año pasado fue "cómo hacer confiable la multidifusión UDP" (como tcp, retransmisión de paquetes perdidos)

Pensé en algo como esto:

El servidor envía multidifusión usando UDP
Cada cliente envía acuse de recibo de esos paquetes (usando TCP)
Si el servidor se da cuenta de que no todos reciben paquetes, reenvía multidifusión o unicast a un cliente en particular

El problema es que puede haber un cliente que generalmente pierde paquetes y obliga al servidor a volver a enviar.

Esta bien ?

Para que UDP sea confiable, debe manejar algunas cosas (es decir, implementarlo usted mismo).

Manejo de la conexión: la conexión entre el proceso de envío y recepción puede disminuir. La mayoría de las implementaciones confiables generalmente envían mensajes Keep-Alive para mantener la conexión entre los dos extremos.

Secuenciación: los mensajes deben dividirse en fragmentos antes de enviarlos.

Acuse de recibo: después de recibir cada mensaje, se debe enviar un mensaje ACK al proceso de envío. Estos mensajes de ACK también se pueden enviar a través de UDP, no tiene que ser a través de UDP. El proceso de recepción podría darse cuenta de que ha perdido un mensaje. En este caso, dejará de entregar los mensajes de la cola de retención (cola de mensajes que contiene los mensajes recibidos, es como una sala de espera para los mensajes) y la solicitud de una retransmisión del mensaje faltante.

Control de flujo: acelere el envío de datos en función de las capacidades del proceso de recepción para entregar los datos.

Por lo general, hay un líder de un grupo de procesos. Cada uno de estos grupos normalmente tiene un líder y una vista de todo el grupo. Esto se llama sincronía virtual.