Existe-t-il un & # 8220; bien & # 8221; moyen de réassembler les multicasts de plusieurs sources?

Question

Je suis en train de retravailler notre code de wrapper de sockets propriétaire pour utiliser boost asio afin qu'il puisse faire le gros du travail pour nous. La partie la plus complexe de notre code existant est peut-être le code de traitement de multidiffusion. Le code permet à nos serveurs de niveau intermédiaire (parmi lesquels il peut y en avoir beaucoup dans un système) d’envoyer des multidiffusions aux boîtes clientes, qui les utilisent pour présenter les mises à jour aux utilisateurs du système.

Si le code est complexe et source d'erreurs, il utilise un certain nombre de mémoires tampon brutes pour réassembler les flux de multidiffusion en fonction de leur origine. Il semble que même avec Boost.Asio, je vais devoir gérer le même problème, alors avant de rester coincé, je pensais qu'il valait la peine de demander comment d'autres personnes ont géré cette situation.

Cela semble être un cas d'utilisation très courant. Y a-t-il quelque chose qui puisse m'aider à faire ce travail sans le genre de code que j'ai maintenant? Ou existe-t-il un modèle C ++ établi (Boost ou autre) pouvant effectuer ce type de travail?

Évidemment, je pourrais me simplifier la tâche et utiliser des conteneurs STL pour mettre en mémoire tampon les paquets au lieu des tableaux bruts, mais ce code doit être très performant. Sur les grandes installations, un grand nombre de paquets volent et il doit répondre le plus possible au temps réel.

Merci d'avance pour vos réflexions à ce sujet.

Jamie

Answer 1

Il ne semble pas que vous ayez fourni suffisamment d'informations pour obtenir des réponses détaillées, mais il existe quelques indications générales à prendre en compte pour le traitement en temps réel des données en multidiffusion.

• Si vous utilisez la multidiffusion UDP brute, vous effectuez probablement une séquence de protocole dans l’espace utilisateur afin de traiter les paquets perdus ou dupliqués. Quelles que soient les optimisations que vous souhaitez réaliser, résistez à la tentation de rompre la superposition entre votre application et votre couche de protocole.
• std :: vector , dans la plupart des cas, est identique à un tampon de caractères brut alloué dynamiquement. Ne pas hésiter à l'utiliser simplement parce que c'est une couche d'abstraction. Il y a deux cas où vous devriez l'éviter, cependant:
  • Si vous pouvez vous en sortir avec des tampons alloués de manière statique
  • Si vous devez transférer la propriété du tampon en aval (cependant, si vous concevez avec soin, swap () peut être suffisant)
• La préallocation est votre amie. Si vous pouvez disposer d’un ensemble de tampons lors de l’entrée de données, vous pouvez supprimer la plupart des allocations dynamiques du raccourci d’exécution.
• Réduisez les copies en mémoire. Si vous pouvez traiter des données dans une seule pile d'appels, vous pouvez éviter les copies. Si vous devez transmettre des données à un autre thread, vous pouvez être obligé de copier des données.
• Si votre application peut gérer les tampons fragmentés (plutôt que d'agréger toutes les données dans un seul tampon), recherchez writev et readv .

Je ne crois pas qu'une solution en boîte puisse résoudre vos problèmes. Boost ASIO, libevent , etc. gèrent les abstractions de socket pour vous, mais ce que vous faites avec vos données reste votre responsabilité, une fois qu'elles ont été livrées.