protocols - pim - ¿Cuál es el protocolo más eficiente para multidifusión confiable?
protocolo pim (7)
Cuando un remitente necesita multidifundir un volumen relativamente grande de datos (por ejemplo, varios megabytes por segundo) de manera confiable a través de Ethernet a un número modesto de receptores (por ejemplo, menos de una docena) en la misma subred, ¿cuál es el protocolo más eficiente? Por confiable, quiero decir que si se pierde un paquete, el protocolo garantiza que se reenvíe de tal manera que no haya pérdida de datos en ningún receptor. El término eficiente es mucho más difícil de definir, pero digamos que queremos maximizar el rendimiento y minimizar el ancho de banda de la red con un uso moderado de la CPU en ambos extremos. Todavía no es una definición clara, pero es lo mejor que se me ocurre. Sería aceptable un protocolo orientado a la transmisión o orientado a mensajes.
Apreciaría ejemplos del mundo real y con mucho gusto aceptaré respuestas subjetivas, es decir, cuál es su protocolo de multidifusión favorito, si puede explicar sus ventajas y desventajas.
¿Podría sugerir UFTP . Se utiliza un mecanismo basado NAK para determinar qué paquetes a retransmitir y tiene una opción, ya sea para una velocidad de transmisión fija o control de la congestión usando TFMCC .
Cada archivo se envía en pases, donde el primer pase transmite el archivo completo, mientras que las pasadas subsiguientes sólo envían retransmisiones. Cada cliente mantiene un registro de qué paquetes que recibió y cuáles se perdió. En puntos de control particulares (y al final de una pasada), si el receptor perdió algún paquete desde el último punto de control, enviará un NAK con una lista de los paquetes que se perdieron. Esto tiene la ventaja de que los receptores de baja pérdida terminarán antes que los receptores de alta pérdida. UFTP también se puede configurar para eliminar receptores cuyo porcentaje de NAK supera un determinado umbral.
Al limitar NAK sólo a los receptores que han mostrado la pérdida se reduce el riesgo de colapso de congestión, que es el emisor conseguir abrumado por la retroalimentación del receptor.
Divulgación: autor de la UFTP.
BitTorrent!
No en serio. Es posible que desee leer sobre él .
UDP es útil para la multidifusión, pero no proporciona las garantías que está buscando. BitTorrent requerirá que transmita más de una copia completa de la fuente original, pero sigue siendo bastante eficiente y proporciona garantías útiles, especialmente considerando la cantidad de suma de comprobación. Se realiza en cada "trozo" de datos transmitidos a lo largo.
Creo que tal vez debería echar un vistazo a protocolo de transmisión de control de tren como alternativa a la UDP / multidifusión si realmente quieres fiable transmisión simultánea a varios clientes.
Ejemplo del mundo real: TIBCO Rendezvous.
Los datos se envían a través de multidifusión con un número de secuencia. Un cliente que detecta un número de secuencia faltante envía un mensaje al grupo de multidifusión "hey, perdí el paquete 12345". El servidor vuelve a realizar la multidifusión de esos datos. El servidor tiene una cantidad configurable de datos para almacenar en búfer en caso de que un cliente lo solicite.
El problema:
Imagine tener un solo cliente que descargue la mitad de sus paquetes y 100 clientes saludables. Este cliente envía una solicitud de retransmisión para cada otro paquete. El servidor comienza a causar suficiente carga en uno de los clientes sanos, por lo que comienza a eliminar paquetes y solicitar retransmisiones. La carga adicional de eso hace que otro cliente saludable comience a solicitar retransmisiones. Y así. Se produce un colapso por congestión.
Tibco proporciona una solución alternativa para eliminar un suscriptor que envía demasiadas solicitudes de retransmisión. Esto hace que sea más difícil para un solo suscriptor causar un colapso por congestión.
La otra solución para limitar el riesgo de colapso por congestión es limitar la cantidad de datos que un servidor está dispuesto a retransmitir.
Tibco también debe proporcionar heurísticas en el cliente y el servidor en cuanto a si se debe realizar una multidifusión o unidifusión de la solicitud de retransmisión y la retransmisión en sí misma. Ellos no (Para el servidor, puede enviar unidifusión la retransmisión si solo un cliente la solicitó en una ventana de tiempo determinada; para el servidor puede unicast la solicitud de retransmisión si el servidor le ha dicho, en el paquete retransmitido, que usted es el único que solicita retransmisiones y por favor unicast las solicitudes en el futuro)
Fundamentalmente, tendrá que decidir entre la fuerza con la que quiere garantizar que los clientes reciban los datos contra el riesgo de colapso de congestión. Tendrá que hacer conjeturas sobre dónde se dejó caer un paquete y si la retransmisión se envía de manera más eficiente de unidifusión o multidifusión. Si el servidor entiende los datos y puede decidir no enviar una retransmisión si de todos modos se envían datos actualizados (lo que hace que la retransmisión sea irrelevante), usted está en una posición mucho mejor que un marco como el de Tibco RV.
A veces, comprender los datos puede llevar a suposiciones erróneas. Por ejemplo, datos de mercado: a primera vista puede parecer OK no retransmitir una cotización cuando hay una cotización actualizada. Pero más adelante, puede descubrir que un suscriptor estaba manteniendo un historial de cotizaciones, no solo tratando de hacer un seguimiento de la cotización actual. Quizás tenga diferentes requisitos dependiendo del suscriptor, y algunos clientes preferirán unicast TCP en lugar de multidifusión.
En algún momento tendrá que tomar decisiones arbitrarias en el servidor de la cantidad de datos que se almacenarán en caso de retransmisiones o clientes lentos.
Esta es una pregunta de investigación abierta; existen soluciones comerciales disponibles, pero que son prohibitivamente caros. Buena suerte.
Siguiendo con TIBCO, el protocolo PGM es una multidifusión confiable, abierta y estándar, con muchas optimizaciones para trabajar de manera eficiente a escalas muy grandes con la aceleración de elementos de red. PGM fue desarrollado por TIBCO y CISCO y es un protocolo opcional debajo de TIBCO Rendezvous, el protocolo predeterminado es TRDP que es muy similar en diseño.
Puede calcular las eficiencias teóricas, como se enumeran aquí para PGM,
http://code.google.com/p/openpgm/wiki/PgmPerformance
Desafortunadamente, los elementos de red del mundo real, las NIC y las arquitecturas de computadora en general tienen un rendimiento mucho menor que los máximos teóricos.