TCP multicast et multithread

Question

Je dois trouver des clients qui peuvent être diffusés en multidiffusion vers d'autres clients de manière fiable. Cela implique que je vais utiliser TCP pour se connecter de manière fiable entre les clients au sein d'un groupe de multidiffusion. Cela ne vient-il pas à n^2 nombre de connexions? Cela me semble un peu idiot. N'y aurait-il/devrait-il pas y avoir un moyen de multicast plus facilement avec la fiabilité?

EDIT: UNIX/C

EDIT: Je ne l'ai pas préciser comment multithreading entre en jeu. mais si je devais ouvrir n^2 connexions, je me suis dit, je serais multithread et c'est encore plus de complication que je voudrais.

Answer 1

Il existe plusieurs solutions de multidiffusion fiables.

• DDS (service de distribution des données)
• Norm Protocol
• PGM

J'ai essayé les deux premiers.

Norm est simple, fonctionne comme une multidiffusion udp standard mais incorpore des nacks ... excellent si vous n'avez pas besoin de plus. Certaines implémentations prennent également en charge l'adaptation de bande passante et d'autres améliorations.

DDS est un pas en avant. C'est vraiment génial (je connais la mise en œuvre de RTI et ça marche très bien) et il y a beaucoup de capacités ainsi qu'un très bon design. Il est basé sur une tolérance fiable et la tolérance aux pannes et il y a un open implementation. D'ailleurs, au moins, DDS et NORM ne nécessitent pas de connexions n^2. Ils fonctionnent comme UDP de multidiffusion.

Answer 2

Bien sûr, il existe un moyen plus efficace - vous restez en utilisant UDB et vous réimplémentez un envoi fiable. Pas trivial, cependant. Mais au moins vous avez seulement besoin de garder les paquets envoyés une fois sur le site d'envoi. La multidiffusion et le TCP sont mutuellement exclusifs.

Answer 3

La mise en œuvre d'une livraison fiable sur UDP est une opération complexe. Personne ne le fait depuis les années 1980 et il est impossible de faire aussi bien que n'importe quelle pile TCP bon marché, en termes de performances et de frais généraux BW. Correction: parfois, c'est fait manuellement, mais seulement sur des transports exotiques, comme des tuyaux extrêmement longs ou étroits.

N^2 connexions n'est pas très stupide. Une connexion avec keepalives 1Hz ne coûte pas cher. Quels sont les coûts du trafic. C'est ce sur quoi votre design doit se concentrer.

Answer 4

En fonction de votre plate-forme cible ....

Vous pouvez jeter un oeil à Pragmatic General Multicast. C'est, si je comprends bien, ce que Microsoft MSMQ et Tibco Rendezvous utilisent et il est accessible via Winsock (voir: http://msdn.microsoft.com/en-us/library/ms740125(VS.85).aspx).

Answer 5

PGM est une option, comme mentionné ci-dessus. Le problème que nous avions avec cela est que si un client n'arrive pas à lire les données entrantes, il est déconnecté. Comme nous n'avons jamais pu garantir des clients 'assez rapides', nous avons implémenté notre propre protocole de fiabilité en plus de la multidiffusion UDP. L'implémentation n'est pas entièrement générique en ce qui concerne les connexions/déconnexions dynamiques, mais cela pourrait fonctionner pour vous. Vous trouverez ici la mise en œuvre:

http://www.equalizergraphics.com/cgi-bin/viewvc.cgi/trunk/src/lib/net/rspConnection.h?view=markup http://www.equalizergraphics.com/cgi-bin/viewvc.cgi/trunk/src/lib/net/rspConnection.cpp?view=markup

Answer 6

Juste une pensée, mais que votre travail doit être fait avec un protocole de mise en réseau. Vous pouvez également envisager de l'implémenter avec un service de messagerie, avec un modèle basé sur publish-subscribe.

Si vous avez besoin de réseau, alors vous devrez faire face à beaucoup de connexions, ou en assurer vous-même la livraison. Assurez-vous de vos besoins avant de prendre cette route.

Answer 7

Vous devez jeter un oeil à 0MQ qui est un système de messagerie à grande vitesse qui a pour fonction de multicast fiable en utilisant le Pragmatic General Multicast (PGM) en utilisant OpenPGM.

Il y avait un article sur récemment dans lwn.net:

0MQ: A new approach to messaging