Écrire un système multicast fiable et totalement commandé en Python

Question

Je dois écrire un système de multidiffusion fiable et totalement commandé à partir de zéro en Python. Je ne peux utiliser aucune bibliothèque externe. Je suis autorisé à utiliser un séquenceur central.

Il semble y avoir deux approches immédiates:

1. écrire un système efficace, en joignant un identifiant unique à chaque message multicast, avoir les numéros de séquence de multidiffusion du séquenceur pour l'identifiant de message qu'il reçoit, et l'envoi en retour des ACK et des NACK.
2. écrire un système d’inondation inefficace, où chaque multicaster renvoie simplement chaque message qu’il reçoit une fois (sauf s’il a été envoyé par ce multicaster particulier.)

J'ai le droit d'utiliser la deuxième option et je suis enclin à le faire.

Je suis en train de multidiffuser des messages UDP (ce qui semble être la seule option possible), mais cela signifie que certains messages risquent de se perdre. Cela signifie que je dois être capable d'identifier de manière unique chaque message UDP envoyé, afin qu'il puisse être renvoyé conformément à # 2. Devrais-je vraiment générer des numéros uniques (par exemple en utilisant l'adresse de l'expéditeur et un compteur) et les intégrer dans chaque message UDP envoyé? Comment pourrais-je m'y prendre? Et comment puis-je recevoir un seul message UDP en Python et non un flux de données (c'est-à-dire socket.recv )?

Answer 1

L’approche par inondation peut aggraver une mauvaise situation. Si les messages sont supprimés en raison d'une charge réseau élevée, le fait d'avoir chaque nœud à renvoyer chaque message ne fera qu'aggraver la situation.

La meilleure approche à adopter dépend de la nature des données que vous envoyez. Par exemple:

1. Données multimédias: aucune tentative, un paquet abandonné est une image perdue, ce qui importera peu de savoir quand la prochaine image y parviendra de toute façon.
2. Données de période fixe: le nœud destinataire conserve une minuterie qui est réinitialisée chaque fois qu'une mise à jour est reçue. Si le délai expire, il demande la mise à jour manquante du nœud maître. Les tentatives peuvent être en envoi individuel vers le noeud demandeur.

Si aucune de ces situations ne se produit (chaque paquet doit être reçu par chaque nœud et que la synchronisation des paquets est imprévisible, les destinataires ne peuvent donc pas détecter eux-mêmes les paquets manqués), vos options sont les suivantes:

1. ACK explicite de chaque nœud pour chaque paquet. L'expéditeur essaie (unicast) tout paquet qui n'est pas ACKed.
2. L’approche de la grille basée sur TCP, dans laquelle chaque noeud répète manuellement les paquets reçus aux noeuds voisins, en s’appuyant sur les mécanismes TCP pour assurer la livraison.

Vous pourriez peut-être compter sur les destinataires pour noter un paquet manqué lors de la réception d'un paquet avec un numéro de séquence ultérieur, mais cela oblige l'expéditeur à conserver le paquet jusqu'à ce qu'au moins un paquet supplémentaire ait été envoyé. Exiger des ACK positifs est plus fiable (et prouvable).

Answer 2

Votre approche dépendra beaucoup de la nature des données que vous envoyez, de l’ampleur de votre réseau et de la quantité de données que vous envoyez. En particulier, cela dépendra du nombre de cibles auxquelles chacun de vos nœuds est connecté.

Si vous vous attendez à ce que cela s’adapte à un grand nombre de cibles pour chaque nœud et à une grande quantité de données, vous constaterez peut-être que l’ajout d’un ACK / NAK à chaque paquet suffit à limiter le débit de façon défavorable. , en particulier lorsque vous ajoutez des retransmissions dans le mix.

Comme l’a déclaré Frank Szczerba, les données multimédias ont l’avantage de pouvoir récupérer des paquets perdus. Si vous avez un quelconque contrôle sur les données que vous envoyez, vous devriez essayer de concevoir les charges utiles de manière à minimiser la susceptibilité aux paquets perdus.

Si les données que vous envoyez ne peuvent pas tolérer les paquets perdus et que vous essayez d’adapter à une utilisation intensive de votre réseau, il se peut que le protocole udp ne soit pas le meilleur protocole à utiliser. La mise en œuvre d'une série de serveurs proxy TCP (où chaque nœud retransmet, en monodiffusion, à tous les autres nœuds connectés - semblable à votre idée d'inondation) constituerait un mécanisme plus fiable.

Cela dit, avez-vous envisagé d'utiliser le véritable multicast pour cette application?

Je viens de voir le "devoir" " tag ... ces suggestions pourraient ne pas convenir à un problème de devoirs.