Lecture de la même socket par plusieurs programmes

Bonjour, j'ai un léger souci de programmation socket en C
Je vais essayer d'en simplifier la description au maximum afin que cela soit simple à comprendre.

J'ai une application client serveur en UDP.
J'ai 1 client (ip 192.168.1.2) et 1 serveur (ip 192.168.1.1).
Le serveur envoie des trames au client sur le port 10000.

Le client utilise une application très simple : cette application écoute sur le port 10000, et affiche ce qu'elle reçoit sur la sortie standard.

Là où ca se complique un peu, c'est que mon client peut éventuellement lancer plusieurs applications en même temps. Et là, je n'ai qu'un seul client qui m'affiche la trame envoyée par le serveur (en général le dernier client lancé)

Comment faire pour que tous les clients recoivent le message (impossible d'utiliser le broadcasting) puisque l'ordinateur ne dispose que d'une interface réseau.

J'ai pensé à faire une sorte d'application extérieure au client qui se chargerait de récupérer les infos de la socket et des les dispatcher aux différentes instances du programmes, mais cela me parait très lourd à gérer.

Y a t'il un moyen de faire une sorte d'écoute en parallèle sur un port, afin que chaque client puisse recevoir l'ensemble des messages? faut-il plutôt utiliser TCP/IP ?

Merci

Citation:

---

Envoyé par agrosjea

...Le serveur envoie des trames au client sur le port 10000.

Le client utilise une application très simple : cette application écoute sur le port 10000, et affiche ce qu'elle reçoit sur la sortie standard.

---

Je crois qu'il y a une petite confusion entre les termes client et serveur, ce que tu décrit là, c'est un serveur. Un serveur écoute sur un socket.

Ce que tu semble décrir, c'est un serveur UDP qui lance d'autre serveurs UDP. Essaye dans ce cas pour tous les serveur d'utiliser l'option SO_REUSEADDR sur la socket (avec setsockopt()).

Ceci dit, j'ai un peu de mal à comprendre pourquoi un serveur a besoin de créer un autre serveur (même en UDP), il y a peut être un problème d'architecture.

Normallement, il n'existe qu'un seul serveur et celui ci peut éventuellement créer des processus fils au fur et a mesure que des connexions arrivent sur la socket à l'écoute.

Tout d'abord, je signale que je n'y connais pas grand chose en réseau.

Si j'ai utilisé le mot client, c'est parce que dans mon appli, la connexion que je décris dans mon premier post est secondaire.
Je ne l'avais pas mentionné afin de mettre le focus sur le problème.

Ainsi pour décrire un peu plus en détail :
- Mes clients envoient en permanence des flux de données au serveur, qui centralise et retraite les données des différents clients.

- Parfois, il arrive que le serveur ordonne à l'ensemble des clients de changer l'un de leur paramètres, il utilise alors une socket dédiée sur laquelle les clients écoutent (celle dont je parlais dans le premier post).

- Pour illustrer le principe, imagine une application client qui en se lancant affiche une fenêtre noire. On lance n instances de cette application, on a donc n fenêtres noires à l'écran, chacune d'elle (en plus d'envoyer des données au serveur) attendant des ordres du serveur.
Le serveur envoie aux clients "bleu" dans la socket, toutes les fenêtres deviennent bleues.
Actuellement, avec SO_REUSEADDR, c'est la dernière application client lancée qui prend la main sur la socket et donc elle-seule qui change de couleur.

Du coup ma question était y a t'il un moyen (une option sur les socket, une architecture...) qui me permette de rendre bleues toutes les instances de la fenêtre ?

Voilà j'espère que ca ne te semblera pas complétement débile... :mrgreen:

Ça s'appelle du multicast et il faut, pour cela, passer certaines options au socket, comme pour SO_REUSEADDR, mais au niveau du protocole IP, donc IPPROTO_IP.

Tout est décrit dans man 7 ip :

Citation:

---

Envoyé par man 7 ip

IP_MULTICAST_TTL
Fixe ou consulte la valeur du champs Time-To-Live des paquets multicast sortant sur cette socket. Il est très importants pour les paquets multicast de fixer le TTL le plus petit possible. La valeur par défaut est 1, ce qui signifie que les paquet multicast ne quittent pas le réseau local à moins que le programme de l'utilisateur ne le réclame explicitement. L'argument est un entier.
IP_MULTICAST_LOOP
Lit ou écrit un entier booléen indiquant si les paquets multicast doivent être renvoyés en boucle aux sockets locales concernées.
IP_ADD_MEMBERSHIP
Rejoindre un groupe multicast. L'argument est une structure struct ip_mreqn.


struct ip_mreqn {
struct in_addr imr_multiaddr; /* Adresse IP du groupe multicast */
struct in_addr imr_address; /* Adresse IP de l'interface locale */
int imr_ifindex; /* Numéro d'interface */
};

imr_multiaddr contient l'adresse du groupe multicast que l'application veut rejoindre ou quitter. Il doit s'agir d'une adresse multicast valide. imr_address est l'adresse de l'interface locale avec laquelle le système doit joindre le groupe multicast. Si elle est égale à INADDR_ANY, une interface appropriée est choisie par le système. imr_ifindex est le numéro de l'interface pour rejoindre ou quitter le groupe imr_multiaddr, ou zéro pour indiquer n'importe quelle interface.
Pour la compatibilité, l'ancienne structure ip_mreq est encore supportée. Elle diffère de ip_mreqn seulement par l'absence du membre imr_ifindex. Uniquement valide pour setsockopt(2).
IP_DROP_MEMBERSHIP
Quitter un groupe multicast. L'argument est une structure ip_mreqn ou ip_mreq comme pour IP_ADD_MEMBERSHIP.
IP_MULTICAST_IF
Fixer le périphérique local pour une socket multicast. L'argument est une structure ip_mreqn ou ip_mreq comme pour IP_ADD_MEMBERSHIP.
Lorsqu'une option de socket invalide est fournie, ENOPROTOOPT est renvoyée.

---

Ça demande de s'y pencher un peu, cela dit.


ATTENTION : sois sûr de ce que tu veux faire. Il y a de nombreux développeurs qui, y compris professionnellement, utilisent le réseau à de mauvaises fins. Par exemple, on a déjà vu des applications ouvrant un port TCP simplement pour signaler que l'application tourne et pour pouvoir communiquer avec. Sous Unix, cela se fait typiquement avec un socket UNIX et un nom local, et ça ne va pas se promener sur le réseau. Les gens qui ont écrit cette application n'avaient pas prévu que nous utiliserions des serveurs Unix centralisés exploités par des Thin Clients. Moralité : dès qu'une personne avait ouvert l'application, plus personne d'autre ne pouvait le faire. Il s'agissait d'un outil … de travail collaboratif en laboratoire !

Merci, pour cette réponse. Ca semble en effet pouvoir fonctionner avec le multicast, mais ca nécessite que je réécrive ma classe Socket, qui me simplifiait bien la vie :roll:

Sinon, ce système ne devrait pas vraiment poser de problème. En effet l'application sera utilisée sur des installations dédiées, du coup nous contrôlons l'ensemble des aspects logiciels.

Je m'y remet demain, en espèrant que ca va fonctionner correctement...

Citation:

---

Envoyé par agrosjea

Merci, pour cette réponse. Ca semble en effet pouvoir fonctionner avec le multicast, mais ca nécessite que je réécrive ma classe Socket, qui me simplifiait bien la vie :roll:

---

Ou que tu la complètes.

Si tu utilises une « classe Socket », c'est que tu travailles vraissemblablement en C++ et, dans ce cas, il y a des chances qu'une lib les encapsule déjà pour toi. Regarde si Boost ne saurait pas le faire, par exemple.

Citation:

---

Sinon, ce système ne devrait pas vraiment poser de problème. En effet l'application sera utilisée sur des installations dédiées, du coup nous contrôlons l'ensemble des aspects logiciels.

---

Ce n'est pas une raison, et certainement pas une habitude à prendre. L'environnement, ça change avec le temps, aussi bien au niveau logiciel que matériel d'ailleurs. Si le logiciel que tu écris est bon pour la poubelle à la moindre variation du cahier des charges, ce n'est pas un investissement. Mais surtout, un logiciel mal conçu risque d'engendrer pas mal d'effets de bords qui peuvent rendre la vie pénible aux autres programmeurs.

Par exemple : qui te dit qu'une autre équipe n'a pas déjà écrit un soft qui utilise déjà le port 10000 ?

Bon c'est ok ca fonctionne nickel avec le multicast, j'ai juste eu a rajouter 3 lignes dans mon code !

Concernant la pérennité du logiciel, au risque de me répéter, le soft est utilisé sur des installations dont nous maitrisons tous les aspects, c'est à dire que nous livrons des PC où le logiciel est installé et fonctionnel et sur lesquels le client ne dispose d'aucun accès, que ce soit physique ou réseau.
Ensuite, dans tous les cas, nous ne perdons jamais de vue que notre application doit être flexible et utilisons des fichiers textes pour configurer les ports , les ip...