Transmitir como UDP con la confiabilidad de TCP

Question

Estoy trabajando en una solución .NET que se ejecuta completamente dentro de una única red. Cuando los usuarios hacen un cambio en el sistema, quiero lanzar un anuncio y hacer que todos los demás lo escuchen y actúen en consecuencia. ¿Hay alguna manera de que podamos transmitir mensajes como este (como UDP le permitirá hacerlo) mientras se mantiene la entrega garantizada (como TCP)?

Esto es en una red pequeña (clientes de 30ish), si eso hiciera la diferencia.

Answer 1

Casi todos los juegos necesitan las propiedades de reacción rápida (y, en menor medida, las propiedades sin conexión) de UDP y la fiabilidad de TCP. Lo que hacen es construir su propio protocolo confiable sobre UDP. Esto les da la capacidad de reventar paquetes donde quiera y, opcionalmente, hacerlos confiables también.

El sistema de paquetes confiable es generalmente un sistema simple de reintento hasta confirmado más simple que TCP, pero hay protocolos que van más allá de lo que TCP puede ofrecer.

Su situación es muy simple. Probablemente podrá hacer la solución más limpia usted mismo, simplemente haga que cada cliente envíe una respuesta "Te escuché" y haz que el servidor siga intentándolo hasta que lo recupere (o se dé por vencido).

Si quieres algo más, la mayoría de las bibliotecas de protocolos personalizadas están en C++, por lo que no estoy seguro de cuánto usarán para ti. Sin embargo, mi conocimiento aquí es de hace unos años, tal vez algunos protocolos ya se hayan transferido. Hmm ... RakNet y enet son dos bibliotecas C/C++ que se me ocurren.

Answer 2

hacer una multidifusión RDP.

Answer 3

Lo que puede hacer es que después de la transmisión, los clientes inicien las conexiones tcp. De lo contrario, solo tiene que mantener una lista de todos los clientes e iniciar las conexiones a cada cliente usted mismo.

Answer 4

Creo que hay tres opciones, a grandes rasgos:

1. En lugar de UDP de difusión, se podría crear una entidad (un hilo, proceso, servidor, servicio, o lo que sea el caso es que existe en su solución) que mantiene una lista de suscriptores y les envía mensajes UDP de unidifusión.
2. Utilice la multidifusión UDP, pero tendrá que escribir algún tipo de mecanismo que se encargue de la entrega confiable para usted (es decir, reintentos, tiempos de espera, etc.). Esto también significa que debe obtener una respuesta de sus clientes.
3. Si no tienes miedo de protocolos de transporte experimentales, lo podría hacer here para sugerencias.,

Answer 5

Usted podría utilizar Spread hacer la comunicación de grupo.

Answer 6

Puede implementar su propio comportamiento de tipo TCP en la capa de aplicación.

Por ejemplo, enviaría la transmisión UDP, pero luego esperaría una respuesta de cada host. Si no obtuvo una respuesta dentro de X segundos, envíe otra y así sucesivamente hasta llegar a algún tipo de umbral. Si se alcanza el umbral (es decir, el host no respondió en absoluto), informe un error.

Para hacer esto, necesitaría una lista predefinida de hosts de los que esperar las respuestas.

Answer 7

Eche un vistazo a sctp que tiene una combinación de características tcp y udp. Hay una ventana implementation disponible.

Answer 8

Yoy debería echar un vistazo a la especificación Norm (NAC-Confiable Multidifusión confiable). Puede encontrar information about Norm here.

El protocolo de la norma está diseñado para proporcionan de extremo a extremo de transporte fiable de objetos de datos a granel o corrientes sobre de encaminamiento de multidifusión IP genérica y servicios de expedición. NORMA utiliza un acuse de recibo negativo mecanismo selectiva, (NACK) para el transporte fiabilidad y ofrece mecanismos de protocolo adicionales para llevar a cabo sesiones de multidifusión confiable con coordinación limitada "a priori", entre emisores y receptores

Es un tanto muy conocido en el mundo militar.

Norm specs.

Norm Source

Answer 9

@epatel - Secundo la sugerencia SCTP (I votaron, pero no puede hacer comentarios todavía cosas por lo adicional aquí).

SCTP tiene muchas características excelentes y flexibilidad. Puede subdividir su conexión en varias transmisiones y elegir la confiabilidad de cada una y si está ordenada o no. Alternativamente, con la extensión Partially Reliability, puede controlar la fiabilidad mensaje por mensaje.

Answer 10

Broadcast no es lo que quieres. Dado que podría haber, y probablemente habrá, dispositivos conectados a esta red que no se preocupan por su mensaje, debe usar la multidifusión. A diferencia de los mensajes de difusión, que deben ser enviados y procesados ​​por cada cliente en la red, los mensajes de multidifusión se entregan solo a los clientes interesados ​​(es decir, aquellos que tienen alguna intención de recibir este tipo particular de mensaje y actuar sobre él).

Si posteriormente escala este sistema para que se lo enrute a través de una red grande, la multidifusión puede escalar a eso, mientras que la difusión no lo hará, por lo que obtendrá un beneficio de escalabilidad que podrá apreciar más adelante. Mientras tanto, elimina la sobrecarga innecesaria en conmutadores y otros dispositivos que no necesitan ver estos mensajes "algo cambiado".

Answer 11

Es posible que desee consultar RFC 3208 "PGM Reliable Transport Protocol Specification".

Aquí está el resumen:

multidifusión general pragmática (PGM) es un transporte de multidifusión fiable
protocolo para aplicaciones que requieren ordenado o no ordenado,
, datos de multidifusión sin duplicados de entrega de múltiples fuentes a
receptores múltiples. PGM garantiza que un receptor en el grupo recibe todos los paquetes de datos de transmisiones y reparaciones, o es capaz de detectar datos irrecuperables pérdida de paquetes.PGM es específicamente pensado como una solución viable para las aplicaciones de multidifusión con los requisitos básicos de confiabilidad . Su objetivo de diseño central es la simplicidad del funcionamiento con la debida consideración de la escalabilidad y la eficiencia de la red.

Answer 12

¿Por qué construir algo desde cero si se puede usar la biblioteca? Especialmente para un proyecto tan pequeño?

uso Try Emcaster que a su vez a través de mensajes de multidifusión confiable - PGM, está escrito en .NET y con código fuente completo. Obtendrá un buen motor de publicación/publicación con filtrado de temas disponible. O puede aprender del código cómo hacerlo y basar su propia extensión en él.

Answer 13

creo que la característica más irritante de TCP en estos escenarios es la capacidad/forma de ordenar los paquetes entrantes a su orden original - el concepto de un arroyo. No puedes leer un byte hasta el byte antes de que llegue.

Si se puede vivir sin ella, que tenga su oportunidad de tener su protocolo, rápido y fiable, pero no para la ordenación de los paquetes! Simplemente es imposible administrarlos a ambos, porque no puedes ordenar tus bytes hasta que recibas otra copia de un paquete perdido, esa es la compensación principal.

Answer 14

Crear un servidor TCP. Haga que cada cliente se conecte. En su protocolo TCP con los clientes, cree cada paquete con un prefijo de 2 bytes del tamaño total del siguiente mensaje.

Los clientes luego llaman al read(max_size=2) en el zócalo para determinar el tamaño del siguiente mensaje, y luego read(max_size=s) para recoger el mensaje.

Se obtiene confiable, ordenada mensajes, simple. No necesita un marco de mensajería para este.

Answer 15

Se puede usar un Message Broker, como ActiveMQ.
Publique sus mensajes a un tema y haga que los clientes registren suscripciones duraderas al tema, para que no pierdan ningún mensaje, incluso si no están en línea.

Apache ActiveMQ es un intermediario de mensajes escrito en Java junto con un cliente completo JMS. Sin embargo, Apache ActiveMQ es diseñado para comunicarse a través de un número de protocolos como Stomp y OpenWire junto con un número de clientes de idioma diferente .

soporte de plataforma de cliente incluye C# y .NET

Answer 16

te había definitivamente que desee ver en Pragmatic General Multicast:

Mientras que utiliza TCP ACK para reconocer grupos de paquetes enviados (algo que haría ser antieconómico sobre multidifusión), PGM utiliza el concepto de Agradecimientos Negativos (NAK).

Para más G-diving, el término que estás buscando es reliable multicast. También echa un vistazo a Multipath TCP.