Discussion :

[Amnael]

Hello,


je voudrais savoir s'il est possible de faire communiquer un serveur et un client en local sur une même machine en utilisant des pipes.

Par exemple, lorsque mon serveur reçoit une demande de connexion, il va créer un thread qui lui permettra d'exécuter un traitement avec le client.
L'intérêt de la chose étant de pouvoir gérer plusieurs clients à la fois avec le serveur et non simplement un utilisateur...


Mais je ne sais pas si c'est possible et encore moins comment on peut faire ça =)

[supersnail]

Bonjour,

Il vaut mieux pour cela s'orienter vers ses sockets UNIX (qui fonctionnent à peu près comme des sockets "réseau" mais utilisant un fichier comme point de "rendez-vous"). Si tu es sous windows, tu peux te tourner vers les "named pipes" (qui contrairement à ce que le nom indique, sont plus équivalents à des sockets UNIX qu'à des pipes unidirectionnels).

Sinon en utilisant des pipes, je doutes que ce soit possible (ou alors très complexe ).

[Obsidian]

Hello,

je voudrais savoir s'il est possible de faire communiquer un serveur et un client en local sur une même machine en utilisant des pipes.

Par exemple, lorsque mon serveur reçoit une demande de connexion, il va créer un thread qui lui permettra d'exécuter un traitement avec le client.
L'intérêt de la chose étant de pouvoir gérer plusieurs clients à la fois avec le serveur et non simplement un utilisateur...

Bonjour,

Il vaut mieux pour cela s'orienter vers ses sockets UNIX (qui fonctionnent à peu près comme des sockets "réseau" mais utilisant un fichier comme point de "rendez-vous"). Si tu es sous windows, tu peux te tourner vers les "named pipes" (qui contrairement à ce que le nom indique, sont plus équivalents à des sockets UNIX qu'à des pipes unidirectionnels).

+1 pour supersnail puisque les sockets UNIX servent effectivement à ça. L'avantage est que si tu as déjà un serveur écrit sous UNIX utilisant les sockets pour accepter les connexions depuis le réseau et qu'il fonctionne, alors il te suffit simplement de changer le nom et la famille de l'adresse d'écoute (avant bind()) pour que ton programme fasse directement ce que tu cherches à faire (si tu traitais également les adresses des clients entrants, il faudra également mettre cela à jour, bien sûr, mais ça reste des adaptations mineures).

Juste un détail : il faudra penser aussi à effacer à la main le nom du socket sur le système de fichier, qui deviendra orphelin une fois que le serveur aura cessé d'être à l'écoute, ce qui diffère un peu des tubes nommés UNIX habituels (exploités notamment par lp). Donc avec unlink() en C, en pensant à faire le ménage avant de sortir mais également en entrant si nécessaire puisque ton serveur peut éventuellement se faire tuer avec un kill avant qu'il ait eu le temps de récupérer ses petites affaires.

[Amnael]

Bonjour,

Il vaut mieux pour cela s'orienter vers ses sockets UNIX (qui fonctionnent à peu près comme des sockets "réseau" mais utilisant un fichier comme point de "rendez-vous"). Si tu es sous windows, tu peux te tourner vers les "named pipes" (qui contrairement à ce que le nom indique, sont plus équivalents à des sockets UNIX qu'à des pipes unidirectionnels).

Sinon en utilisant des pipes, je doutes que ce soit possible (ou alors très complexe ).

Merci pour votre réponse à tous les deux.

Je m'en doutais un peu que le plus logique c'était de passer par des socket...mais c'était dans le cadre d'un projet qu'on m'a donné en cours C ou il fallait faire appel au parallélisme directement avec des tubes nommés, pas vraiment le choix

Mais bon, au vu de votre réaction, j'ai bien fais de faire l'impasse sur cette partie de projet






Par contre pour continuer la discussion; que peu on transférer avec les socket ? Jusqu'à maintenant j'ai toujours utilisé des write et read pour faire passer des chaines de caractères; mais ça doit quand même être possible de faire passer des signaux ou ce genre de chose ?

Mais du coup on ne peut plus utiliser write et read pour ce genre d’interaction.

[Obsidian]

Merci pour votre réponse à tous les deux.

Je m'en doutais un peu que le plus logique c'était de passer par des socket...mais c'était dans le cadre d'un projet qu'on m'a donné en cours ou il fallait faire appel au parallélisme directement avec des tubes nommés, pas vraiment le choix
Mais bon, au vu de votre réaction, j'ai bien fais de faire l'impasse sur cette partie de projet

Pas forcément (à part sur l'aspect temporel). Ça aurait pu être très intéressant. Par contre, un pipe est unidirectionnel. Je ne suis pas sûr que le projet en question te demande forcément de gérer plusieurs connexions simultanées, dans ce cas. L'utilisation d'un tube nommé sert justement à mettre en relation deux processus qui ne sont pas lancés au même moment par la même instance, ni l'un par l'autre. C'est typiquement le cas du dæmon de l'imprimante.

Par contre pour continuer la discussion; que peu on transférer avec les socket ? Jusqu'à maintenant j'ai toujours utilisé des write et read pour faire passer des chaines de caractères; mais ça doit quand même être possible de faire passer des signaux ou ce genre de chose ? Mais du coup on ne peut plus utiliser write et read pour ce genre d’interaction.

Non, c'est bien une connexion de type flux, comme un fichier, un tube ou un port série. La philosophie UNIX est d'ailleurs « tout est fichier » et l'idée est de ramener autant que possible tout ce qui peut l'être à la même interface, ce qui permet non seulement de les gérer facilement, mais aussi d'être compatibles avec toutes les commandes shell. Enfin, ça l'était, parce que les nombreux projets qui ont vu le jour depuis, notamment sous Linux, ne cessent de mettre à mal ce principe.

L'exemple du port série RS/232 d'ailleurs, même si on ne l'utilise pour ainsi dire plus depuis l'USB, est bien le plus approprié puisqu'il sert à établir une liaison point-à-point physique entre deux ordinateurs, soit directement, soit par l'intermédiaire d'un modem ou de tout « équipement terminal de transmission de données ». Mais dès qu'un octet est présenté sur le buffer de sortie, il est directement émis bit à bit sur le canal de sortie et l'interface homologue fait le processus inverse : quand elle a accumulé suffisamment de bits, elle indique qu'un octet est disponible. C'est ton système qui se charge d'envoyer l'octet suivant du buffer ou d'accumuler ceux qui arrivent, et le tout t'est présenté sous la forme de du fichier spécial « /dev/cua1 » ou « /dev/ttyS1 » sous Linux, et COM1 dans le monde DOS/Windows.

Par contre, dès lors qu'une transmission est établie, rien ne t'empêche d'utiliser un protocole de communication qui t'est propre et qui, lui, va transporter des données ou d'autres types d'informations. C'est la raison d'être de PPP (Point-to-Point Protocol) qui servait justement à faire transiter du trafic réseau à travers une connexion à deux extrémités. C'est la raison pour laquelle on l'utilise (et le configure) quand on se connecte à Internet par modem analogique et que l'on n'a pas d'ADSL : on lance en fait un dæmon qui d'un côté se déclare comme une interface réseau virtuelle, généralement « ppp0 », à laquelle on peut associer une adresse et, de l'autre, se charge de faire transiter tout ce qui lui parvient à travers la connexion en question, et faire quelques contrôles comme la validité des paquets reçus ou la bonne arrivée à destination de ceux qui sont émis.

Dans le même esprit, tu pourrais tout-à-fait faire passer du TCP/IP over socket, même si ça n'a pas beaucoup de sens puisque le TCP/IP est géré directement par le système, au niveau même de ces sockets.