Protocole & Bibliothèque Réseau

[Jimbooo]

Bonjour,

Problématique :
Nos produits sont des cartes électroniques équipées de PC embarqué avec OS (non définit) que nous connectons (maximum 48) à un PC de supervision (OS W7) afin de former un réseau local privé. Le PC de supervisions doit être capable d’échanger des informations avec chacune des cartes, qui elles n’échangent pas entre eux.
Master GbE <=> Switch <=> 48 x Slaves GbE
Nous avons le besoin de transférer des grosses quantités d’information (>3Go) depuis le PC de supervision sur ces cibles le plus rapidement possible et avec une intégrité des données totale. Le transfert peut se faire sur une seule cible, sur un groupe de N cibles ou bien sur toutes les cibles.

Solution envisagée :
Protocole TCP/IP pour les échanges individuels : Master <=> 1 x Slave
Protocole UDP/IP pour l’envoi de donnée sur un groupe de cible (avec ouverture d’un port d’écoute en amont) en utilisant du broadcast : Master <=> N x Slaves. Une couche de contrôle devant être rajoutée afin de s’assurer de l’intégrité des données et d’avoir bien la totalité.

Questions :
Pensez vous que les protocoles prévues sont les plus adaptés aux besoins (intégrité & performance) ?
Actuellement développeur langage C embarqué (µContrôleur), je n’ai pas d’expérience sur les devs sur OS . Je cherche donc des conseils sur des bibliothèques réseau performante ?


Merci d'avance.

[gangsoleil]

Bonjour,

Vous devez pouvoir envoyer 3Gb vers une ou plusieurs cartes. Mais comment definissez-vous le groupe de receveurs ? Est-ce que celui-ci est fixe au demarrage (fichier de conf par exemple) ou bien evolue-t-il au cours du temps (a midi j'envoie a 10 machines, a 16h j'envoie a 32 machines dont 3 des precedentes, ...) ? Et comment les machines receveuses savent-elles qu'elles doivent, ou non, recevoir les donnees ?

Pour l'envoie du serveur vers une seule machine, pas de soucis, c'est du classique.

Pour la suite, ca depend des reponses : On peut par exemple imaginer un fichier de conf qui serait pousse depuis le serveur vers tous les receveurs (les 48 donc), en brodcast. Ce fichier de configuration contiendrait la liste des machines devant s'abonner a un flux multicast pour recevoir les donnees.
Ensuite, on laisse le temps aux machines de se connecter (mettons 5 secondes pour etre large), puis le serveur envoie le fichier de 3Gb en multicast, a tous les destinataires.

Bien sur, si la liste des destinataires peut changer pendant l'envoie du fichier et que les clients doivent s'en apercevoir dynamiquement, cette option n'est pas valable.

Donne-nous tes contraites, on verra ce qu'on trouve comme idee

[Jimbooo]

Bonjour

Envoyé par gangsoleil

Vous devez pouvoir envoyer 3Gb vers une ou plusieurs cartes.

3 Goctets ou 3GBytes pour être exact !

Envoyé par gangsoleil

Mais comment definissez-vous le groupe de receveurs ? Est-ce que celui-ci est fixe au demarrage (fichier de conf par exemple) ou bien evolue-t-il au cours du temps (a midi j'envoie a 10 machines, a 16h j'envoie a 32 machines dont 3 des precedentes, ...) ? Et comment les machines receveuses savent-elles qu'elles doivent, ou non, recevoir les donnees ?

Le ou les groupes de receveurs ne sont pas fixes, ils peuvent évoluer au cours du temps. Un receveur peut créer un groupe, ou bien adhérer a un groupe existant. Lors de la phase d'envoi des données, nous prévoyons d'envoyer via TCP à toutes les cibles d'un groupe un numéro du port d'écoute UDP. Puis d'envoyer les données via UDP sur ce port. Ainsi, uniquement le groupe concerné recevra les données.

Envoyé par gangsoleil

Pour la suite, ca depend des reponses : On peut par exemple imaginer un fichier de conf qui serait pousse depuis le serveur vers tous les receveurs (les 48 donc), en brodcast. Ce fichier de configuration contiendrait la liste des machines devant s'abonner a un flux multicast pour recevoir les donnees.
Ensuite, on laisse le temps aux machines de se connecter (mettons 5 secondes pour etre large), puis le serveur envoie le fichier de 3Gb en multicast, a tous les destinataires.

Bien sur, si la liste des destinataires peut changer pendant l'envoie du fichier et que les clients doivent s'en apercevoir dynamiquement, cette option n'est pas valable.

Une fois la transaction démarrée, un groupe ne peut pas évoluer, il faut attendre la fin du transfert. Donc pas de ré-assignement dynamique.
Mes connaissances en réseaux étant assez basiques : la gestion du multicast est-elle compliquée à mettre en œuvre ? La gestion se fait au niveau des switchs, existe t il des bibliothèques pour les gérer ?
En revanche je ne vois pas ce qu'apporte ta proposition par rapport à ce que nous avons prévu ? Ah si, le switch dupliquera les trames uniquement sur les ports nécessaires et pas sur tout le réseau ! D'autres points ?


Merci

[gangsoleil]

Bonjour,

Le multicast est proche de la solution que vous avez imagine : dans un cas (le votre), le serveur envoie un port d'ecoute aux clients, et c'est a eux de se brancher sur ce port. Dans le cas du multicast, tu envoies une adresse d'ecoute aux clients, et c'est a eux de se brancher sur cette adresse.
Je reviens sur les avantages et les inconvenients plus loin.

Votre solution semble pas mal, a un detail pres : pourquoi UDP ?? Pourquoi est-ce que vous n'enverriez pas un port a ecouter en TCP ? Ainsi, vous n'avez pas a gerer la coherence (et donc la retransmission des paquets) a la main.

L'inconvenient de votre solution est que le serveur doit envoyer les 3GB autant de fois qu'il y a de clients, ce qui lui fait donc faire le travail N fois.
Si vous utilisez le multicast, l'envoi ne se fait qu'une fois de la part du serveur, et vous gagnez ainsi du temps
L'inconvenient que je peux voir est la saturation du switch : comme vous n'avez qu'un serveur, il ne pourra pas alimenter plus de 2 ou 3 clients a un taux de transfert acceptable, et donc le switch suivra probablement (si c'est un bon).
Alors qu'en multicast, si vous envoyez vers 48 clients en parallele, le switch risque de faire la gueule - mais il faudrait faire le test pour en etre sur, ce qui voudrait dire implementer les deux solutions, ce qui n'est pas forcement raisonnable.

Edit : Le multicast n'est pas tres complexe a mettre en oeuvre, du moins pas plus que de la programmation reseau (avancee) standard.

[Jimbooo]

Bonjour,

Envoyé par gangsoleil

Votre solution semble pas mal, a un detail pres : pourquoi UDP ?? Pourquoi est-ce que vous n'enverriez pas un port a ecouter en TCP ? Ainsi, vous n'avez pas a gerer la coherence (et donc la retransmission des paquets) a la main.

UDP afin de pouvoir broadcaster et ainsi optimiser le flux, et donc les perfs !

Envoyé par gangsoleil

L'inconvenient de votre solution est que le serveur doit envoyer les 3GB autant de fois qu'il y a de clients, ce qui lui fait donc faire le travail N fois.

Pas en utilisant le broadcast !

Envoyé par gangsoleil

Si vous utilisez le multicast, l'envoi ne se fait qu'une fois de la part du serveur, et vous gagnez ainsi du temps
L'inconvenient que je peux voir est la saturation du switch : comme vous n'avez qu'un serveur, il ne pourra pas alimenter plus de 2 ou 3 clients a un taux de transfert acceptable, et donc le switch suivra probablement (si c'est un bon).
Alors qu'en multicast, si vous envoyez vers 48 clients en parallele, le switch risque de faire la gueule - mais il faudrait faire le test pour en etre sur, ce qui voudrait dire implementer les deux solutions, ce qui n'est pas forcement raisonnable.

Le multicast semble aussi utiliser le protocole UDP. Le seul avantage que je vois à utiliser le multicast étant le fait que le switch ne dupliquera pas les trames sur les ports non concernés, d’où une charge inférieure du réseau. En revanche il semble beaucoup plus compliqué à mettre en œuvre qu'un simple broadcast (de mon point de vue).

Envoyé par gangsoleil

Le multicast n'est pas tres complexe a mettre en oeuvre, du moins pas plus que de la programmation reseau (avancee) standard.

Existe-t-il des outils ou des libs facilitant la mise en œuvre du multicast ? Gerant l'IGMP par exemple ?


Merci.