Diffusez comme UDP avec la fiabilité de TCP

Question

Je travaille sur une solution .net qui s'exécute entièrement au sein d'un seul réseau.Lorsque les utilisateurs apportent une modification au système, je souhaite lancer une annonce et que tout le monde l'entende et agisse en conséquence.Existe-t-il un moyen de diffuser des messages comme celui-ci (comme UDP vous le permet) tout en conservant une livraison garantie (comme TCP) ?

C'est sur un petit réseau (30 clients), si cela peut faire une différence.

Answer 1

Presque tous les jeux ont besoin des propriétés de réaction rapide (et dans une moindre mesure, des propriétés sans connexion) d'UDP et de la fiabilité de TCP.Ce qu'ils font, c'est construire leur propre protocole fiable au-dessus d'UDP.Cela leur donne la possibilité de diffuser les paquets n'importe où et éventuellement de les rendre également fiables.

Le système de paquets fiable est généralement un système simple de nouvelle tentative jusqu'à ce qu'il soit reconnu, plus simple que TCP, mais il existe des protocoles qui vont bien au-delà de ce que TCP peut offrir.

Votre situation semble très simple.Vous serez probablement en mesure de créer vous-même la solution la plus propre : demandez simplement à chaque client de renvoyer une réponse "Je vous ai entendu" et demandez au serveur de continuer à essayer jusqu'à ce qu'il l'obtienne (ou abandonne).

Si vous voulez quelque chose de plus, la plupart des bibliothèques de protocoles personnalisées sont en C++, donc je ne suis pas sûr de leur utilité.Cependant, mes connaissances ici datent de quelques années - peut-être que certains protocoles ont déjà été portés.Hmm...RakNet et enet sont deux bibliothèques C/C++ qui me viennent à l'esprit.

Answer 2

Jeter un coup d'œil à sctp qui a une combinaison de fonctionnalités TCP et UDP.Il y a une fenêtre mise en œuvre disponible.

Answer 3

Vous pourriez utiliser Propagé faire de la communication de groupe.

Answer 4

@epatel - J'appuie la suggestion SCTP (j'ai voté, mais je ne peux pas encore commenter, donc des éléments supplémentaires ici).

SCTP possède de nombreuses fonctionnalités et une flexibilité intéressantes.Vous pouvez subdiviser votre connexion en plusieurs flux, choisir la fiabilité de chacun et si elle est commandée ou non.Alternativement, avec le Fiabilité partielle extension, vous pouvez contrôler la fiabilité message par message.

Answer 5

La diffusion n'est pas ce que vous voulez.Puisqu'il pourrait y avoir et il y aura probablement des appareils connectés à ce réseau qui ne se soucient pas de votre message, vous devez utiliser la multidiffusion.Contrairement aux messages de diffusion, qui doivent être envoyés et traités par chaque client du réseau, les messages multidiffusion sont délivrés uniquement aux clients intéressés (c'est-à-dire ceux qui ont l'intention de recevoir ce type particulier de message et d'agir en conséquence).

Si vous faites évoluer ultérieurement ce système de manière à ce qu'il doive être acheminé sur un grand réseau, la multidiffusion peut s'adapter à cela, contrairement à la diffusion, vous bénéficiez donc d'un avantage d'évolutivité que vous apprécierez peut-être plus tard.Pendant ce temps, vous éliminez les surcharges inutiles dans les commutateurs et autres appareils qui n'ont pas besoin de voir ces messages « quelque chose a changé ».

Answer 6

Vous voudrez peut-être examiner RFC3208 "Spécification du protocole de transport fiable PGM".

Voici le résumé :

La multidiffusion générale pragmatique (PGM) est un transport de multidiffusion fiable
Protocole pour les applications qui nécessitent l'ordre ou non ordonné,
Livraison de données de multidiffusion sans double de plusieurs sources à
plusieurs récepteurs.PGM garantit qu'un récepteur du groupe reçoit tous les paquets de données des transmissions et des réparations, ou est en mesure de détecter une perte de paquets de données irrécouvrables.La PGM est spécifiquement destinée à une solution viable pour les applications de multidiffusion avec des exigences de fiabilité de base.Son objectif de conception central est la simplicité du fonctionnement en ce qui concerne l'évolutivité et l'efficacité du réseau.

Answer 7

Vous pouvez utiliser un courtier de messages, tel que ActiveMQ.
Publiez vos messages sur un sujet et demandez aux clients de s'abonner durablement au sujet, afin qu'ils ne manquent aucun message même s'ils ne sont pas en ligne.

Apache ActiveMQ est un courtier de messages écrit en Java avec un client JMS complet.Cependant, Apache ActiveMQ est conçu pour communiquer sur un certain nombre de protocoles tels que Stomp et OpenWire ainsi que la prise en charge d'un certain nombre de clients spécifiques à la langue différents.

La prise en charge de la plate-forme client inclut C# et .net

Answer 8

Vous pouvez implémenter votre propre comportement de type TCP au niveau de la couche application.

Ainsi, par exemple, vous enverriez la diffusion UDP, mais vous attendriez ensuite une réponse de chaque hôte.Si vous n'avez pas obtenu de réponse dans un délai de X secondes, envoyez-en une autre et ainsi de suite jusqu'à atteindre une sorte de seuil.Si le seuil est atteint (c'est-à-direl'hôte n'a pas répondu du tout), puis signaler une erreur.

Cependant, pour ce faire, vous auriez besoin d'une liste prédéfinie d'hôtes desquels attendre les réponses.

Answer 9

Créez un serveur TCP.Demandez à chaque client de se connecter.Dans votre protocole TCP avec les clients, créez chaque paquet avec un préfixe de 2 octets de la taille totale du message suivant.

Les clients appellent ensuite read(max_size=2) sur le socket pour déterminer la taille du prochain message, puis read(max_size=s) pour récupérer le message.

Vous obtenez des messages fiables, ordonnés, simples.Vous n'avez pas besoin d'un framework de messagerie pour celui-ci.

Answer 10

Vous auriez certainement je veux examiner Multidiffusion générale pragmatique:

Alors que TCP utilise des ACK pour accuser réception des groupes de paquets envoyés (ce qui serait peu rentable par rapport à la multidiffusion), PGM utilise le concept d'accusés de réception négatifs (NAK).

Pour de plus amples Plongée sous-marine, le terme que vous recherchez est multidiffusion fiable.Jetez également un oeil à TCP à chemins multiples.

Answer 11

Ce que vous pouvez faire, c'est qu'après la diffusion, le clients initiez les connexions TCP.Sinon, il vous suffit de conserver une liste de tous les clients et d'initier vous-même les connexions avec chaque client.

Answer 12

Je pense qu'il y a trois options, en gros :

1. Au lieu de diffuser UDP, vous pouvez créer une entité (un thread, un processus, un serveur, un service ou tout autre élément existant dans votre solution) qui conserve une liste d'abonnés et leur envoie des messages UDP en monodiffusion.
2. Utilisez la multidiffusion UDP, mais vous devrez écrire une sorte de mécanisme qui prendra en charge une livraison fiable pour vous (c'est-à-dire les tentatives, les délais d'attente, etc.).Cela signifie également que vous devez obtenir une réponse de vos clients.
3. Si vous n'avez pas peur des protocoles de transport expérimentaux, vous pourriez regarder ici pour des suggestions.,

Answer 13

Vous devriez jeter un œil à la spécification Norm (NACK-Oriented Reliable Multicast).Tu peux trouver informations sur Norm ici.

Le protocole de norme est conçu pour fournir un transport fiable de bout en bout des objets de données en vrac ou des flux par rapport aux services de routage et de transfert de multidiffusion génériques IP.Norm utilise un mécanisme sélectif et négatif de reconnaissance (NACK) pour la fiabilité du transport et propose des mécanismes de protocole supplémentaires pour mener des séances de multidiffusion fiables avec une coordination "a priori" limitée entre les expéditeurs et les récepteurs

C'est un peu très connu dans le monde militaire.

Spécifications normatives.

Source de la norme

Answer 14

Pourquoi créer quelque chose à partir de zéro si vous pouvez utiliser une bibliothèque ?Surtout pour un si petit projet ?

Essayez d'utiliser Emcaster qui utilise lui-même une messagerie multicast fiable - PGM, est écrit en .NET et avec des sources complètes.Vous obtiendrez un joli moteur de pub/sub avec un filtrage de sujets facilement disponible.Ou vous pouvez apprendre du code comment le faire et baser votre propre extension dessus.

Answer 15

Je pense que la caractéristique la plus irritante de TCP dans ces scénarios est la capacité/la manière de trier les paquets entrants selon leur ordre d'origine - le concept de flux.Vous ne pouvez pas lire un octet avant son arrivée.

Si vous pouvez vous en passer, vous avez votre chance d'avoir votre protocole, rapide et fiable, mais pas pour commander des paquets !Il est tout simplement impossible de gérer les deux, car vous ne pouvez pas trier vos octets tant que vous n'avez pas reçu une autre copie d'un paquet perdu, c'est le principal compromis.

Answer 16

faire une multidiffusion RDP.