.net - type - tcp vs udp ventajas y desventajas
Transmitir como UDP con la fiabilidad de TCP (16)
¿Por qué construir algo desde cero si puedes usar la biblioteca? Especialmente para un proyecto tan pequeño?
Intente utilizar Emcaster que a su vez utiliza mensajes confiables de multidifusión - PGM, está escrito en .NET y con fuente completa. 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.
Estoy trabajando en una solución .net que se ejecuta completamente dentro de una sola 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 se realiza en una red pequeña (30 clientes), si eso marca la diferencia.
@epatel: secundo la sugerencia de SCTP (voté a favor, pero aún no puedo comentar, así que hay más cosas 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 Parcially Reliability , puede controlar la confiabilidad mensaje por mensaje.
Casi todos los juegos necesitan 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, por lo general, un sistema simple de reintento hasta que sea reconocido más simple que TCP, pero hay protocolos que van más allá de lo que TCP puede ofrecer.
Tu situación suena 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 desea algo más, la mayoría de las bibliotecas de protocolos personalizados están en C ++, por lo que no estoy seguro de cuánto usarán. 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.
Crea 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.
A continuación, los clientes llaman a read(max_size=2) en el socket para determinar el tamaño del siguiente mensaje, y luego read(max_size=s) para recopilar el mensaje.
Obtiene mensajes confiables y ordenados, simples. No necesita un marco de mensajería para este.
Creo que hay tres opciones, en términos generales:
- En lugar de transmitir UDP, podría crear una entidad (un hilo, proceso, servidor, servicio o lo que sea que exista en su solución) que mantenga una lista de suscriptores y les envíe mensajes UDP de unidifusión.
- 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.
- Si no tiene miedo de los protocolos de transporte experimentales, puede buscar here sugerencias.
Creo que la característica más irritante del TCP en estos escenarios es la capacidad / forma de clasificar los paquetes entrantes a su orden original: el concepto de una transmisión. No puede leer un byte hasta el byte antes de que llegue.
Si puedes vivir sin él, tienes la oportunidad de tener tu protocolo, rápido y confiable, ¡pero no para pedir 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.
Deberías echarle un vistazo a la especificación Norm (Multicast confiable confiable orientada a NACK). Puede encontrar información sobre Norm aquí .
El protocolo NORM está diseñado para proporcionar un transporte fiable de extremo a extremo de objetos de datos a granel o flujos a través de servicios genéricos de encaminamiento y reenvío de multidifusión IP. NORM utiliza un mecanismo de reconocimiento negativo selectivo (NACK) para la confiabilidad del transporte y ofrece mecanismos de protocolo adicionales para llevar a cabo sesiones de multidifusión confiables con coordinación "a priori" limitada entre remitentes y receptores
Es algo muy bien conocido en el mundo militar.
Eche un vistazo a sctp que tiene una combinación de características tcp y udp. Hay una implementation Windows disponible.
Es posible que desee consultar RFC 3208 "PGM Reliable Transport Protocol Specification".
Aquí está el resumen:
Pragmatic General Multicast (PGM) es un transporte de multidifusión confiable
protocolo para aplicaciones que requieren ordenados o desordenados,
entrega de datos multicast sin duplicados desde 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 puede detectar la pérdida irrecuperable de paquetes de datos. PGM está específicamente diseñado como una solución viable para aplicaciones de multidifusión con requisitos básicos de confiabilidad. Su objetivo central de diseño es la simplicidad de operación con la debida consideración de la escalabilidad y la eficiencia de la red.
La difusión 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 más adelante amplía este sistema para que tenga que ser enrutado 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".
Lo que puede hacer es que después de la transmisión, los clientes inicien las conexiones de tcp. De lo contrario, solo tiene que mantener una lista de todos los clientes e iniciar las conexiones a cada cliente usted mismo.
Podría implementar su propio comportamiento similar al TCP en la capa de aplicación.
Entonces, 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.
Sin embargo, para hacer esto, necesitaría una lista predefinida de hosts de los que esperar las respuestas.
Podría usar Spread para hacer comunicación grupal.
Puede usar un Message Broker, como ActiveMQ .
Publique sus mensajes en 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 JMS completo. Sin embargo, Apache ActiveMQ está diseñado para comunicarse a través de una serie de protocolos, como Stomp y OpenWire, junto con el soporte de varios clientes específicos del idioma.
La compatibilidad de la plataforma cliente incluye c # y .net
hacer una multidifusión RDP.
Definitivamente querrías ver Pragmatic General Multicast :
Mientras que TCP usa ACK para reconocer los grupos de paquetes enviados (algo que sería antieconómico con respecto a la multidifusión ), PGM usa el concepto de Reconocimientos Negativos (NAK).
Para más G-diving , el término que buscas es multidifusión confiable . También eche un vistazo a Multipath TCP .