Quels sont les avantages d'utiliser un canal nommé plutôt qu'un tube non nommé?

51

Je passais en revue un ensemble de questions d’entrevue posées à un administrateur Unix; J'ai trouvé un sujet appelé "tube nommé".

J'ai googlé le sujet; dans une certaine mesure, j'ai pu le comprendre: - pipes nommées || FIFO

Mais j’ai quand même l’impression de ne pas savoir quand utiliser ce type de tuyau. Existe-t-il des situations spéciales dans lesquelles les tuyaux non nommés ne fonctionneraient pas?

pipe

— Ankit
source

Un autre lien sur le forum technique: writeulearn.com/category/inter-process-communicationipc

39

Les pipes nommées (fifo) ont ~~quatre~~ trois avantages auxquels je peux penser:

vous n'avez pas à démarrer les processus de lecture / écriture en même temps
vous pouvez avoir plusieurs lecteurs / écrivains qui n'ont pas besoin d'une ascendance commune
en tant que fichier, vous pouvez contrôler la propriété et les autorisations
~~ils sont bidirectionnels, les tuyaux sans nom peuvent être unidirectionnels~~ *

^{*) Pensez à un shell standard |pipeline qui est unidirectionnel, plusieurs coquilles ( ksh, zshet bash) offrent également coprocess qui permettent une communication bidirectionnelle. POSIX considère les pipes comme semi-duplex (chaque côté ne peut que lire ou écrire), l’ pipe()appel système renvoie deux descripteurs de fichier et il peut être nécessaire de traiter l’un en lecture seule et l’autre en écriture seule. Certains systèmes (BSD) prennent en charge la lecture et l’écriture simultanées (ce qui n’est pas interdit par POSIX), sur d’autres, vous aurez besoin de deux canaux, un pour chaque direction. Vérifiez votre pipe(), popen()et peut - être l' popen2()homme pages. Le caractère non directionnel peut ne pas dépendre de l’appellation du canal ou non, bien que sous Linux 2.6, il soit dépendant.}

(Mise à jour, grâce aux commentaires de Stéphane Chazelas )

Une tâche immédiatement évidente que vous ne pouvez pas réaliser avec un canal non nommé est une application client / serveur conventionnelle.

Le dernier point (touché) ci-dessus concernant les canaux unidirectionnels est pertinent sous Linux. POSIX (voir popen()) indique qu'un canal doit uniquement être lisible ou inscriptible , sous Linux ils sont unidirectionnels . Voir Comprendre le noyau Linux (3e éd. O'Reilly) pour plus de détails sur Linux (p787). Les autres systèmes d’exploitation proposent des tuyaux bidirectionnels (non nommés).

Par exemple, Nagios utilise un fifo pour son fichier de commandes . Divers processus externes (scripts CGI, contrôles externes, NRPE, etc.) écrivent des commandes / mises à jour dans ce fifo et celles-ci sont traitées par le processus persistant de Nagios.

Les canaux nommés ont des caractéristiques similaires aux connexions TCP, mais il existe des différences importantes. Etant donné qu'un fifo a un nom de système de fichiers persistant, vous pouvez y écrire même en l'absence de lecteur. Certes, les écritures seront bloquées (sans E / S asynchrone ni non bloquante), mais vous ne perdrez pas de données si le destinataire n'est pas connecté. démarré (ou en cours de redémarrage).

Pour référence, voir aussi les sockets de domaine Unix , et la réponse à cette question de Stackoverflow qui résume les principales méthodes IPC , et celle qui concernepopen()

— mr.spuratic
source

2

vous pouvez aussi avoir plusieurs lecteurs / écrivains avec des pipes sans nom. Sous Linux, ils ne sont pas plus bidirectionnels que les pipes sans nom. Il y a une fin d'écriture et une fin de lecture et les données circulent dans une seule direction. Lorsque vous ouvrez un fifo en mode écriture, vous obtenez la fin de l'écriture, en lecture, la fin de la lecture, en mode rw, vous écrivez en fin d'écriture et lisez à partir de la lecture. Cela diffère des pipes bidirectionnelles ou des sockets de domaine Unix, où vous avez en réalité deux flux de données distincts dans chaque direction.

— Stéphane Chazelas

@StephaneChazelas merci pour les commentaires, j'ai mis à jour la réponse pour qu'elle soit plus précise et clarifie (j'espère) les tuyaux et la direction.

— mr.spuratic

La communication vers un canal nommé implique-t-elle une entrée / sortie disque? Ou est-ce tout en mémoire? Qu'est-ce qui détermine l'enveloppe de performance de ces mécanismes IPC?

— CMCDragonkai

15

Les canaux sans nom ou anonymes permettent de communiquer interprocessus un à un et unidirectionnel entre différents processus liés soit par une relation parent-enfant, soit par les enfants d'un parent commun fournissant le canal, tel qu'un shell processus. Étant donné que les processus sont liés, l'association de descripteurs de fichier au canal peut être implicite et ne nécessite pas d'objet avec un nom externe aux processus. Un canal non nommé existe uniquement tant que la procédure qui l'utilise maintient des descripteurs de fichier ouverts dans le canal. Lorsque les processus se terminent et que le système d'exploitation ferme tous les descripteurs de fichier associés aux processus, le canal non nommé est fermé.

Les tubes nommés sont en fait des FIFO. Ce sont des objets persistants représentés par des nœuds dans le système de fichiers. Un canal nommé fournit une communication bidirectionnelle plusieurs à plusieurs entre un ou plusieurs processus qui ne sont pas nécessairement liés et qui ne doivent pas nécessairement exister en même temps. Le nom de fichier du canal sert d’adresse ou de contrat entre les processus de communication. Si un seul processus écrit sur un canal nommé et qu'un autre processus lit à partir du canal nommé, le canal nommé se comporte de la même manière qu'un canal non nommé entre les deux processus liés.

La réponse courte est donc qu'il vous faut un canal nommé pour la communication entre des processus non liés qui pourraient ne pas exister en même temps.

— Jonathan Ben-Avraham
source

+1 Je pense que les processus existent presque toujours au même moment (sinon le tuyau est un peu inutile - vous pouvez aussi bien laisser des éléments dans un fichier normal). Ces sockets et les sockets de domaine unix sont souvent utilisés par des services démons pouvant être contrôlés, par exemple à partir de la ligne de commande. Si vous regardez /runsur un système de bureau Linux, vous en trouverez probablement quelques-uns (nommés fifos et unix sockets). C'est une forme de CIP .

— goldilocks

2

@goldilocks: un canal nommé est couramment utilisé en tant que boîte aux lettres ad hoc résidant en mémoire entre des processus de systèmes intégrés, où les processus de communication sont de courte durée et n'existent pas en même temps. L'avantage est la simplicité de mise en œuvre par rapport à la mémoire partagée IPC et le fait que seule la RAM est utilisée. L'inconvénient est la non-persistance entre les bottes et la nature FIFO par canal du canal par rapport à la possibilité d'utiliser une structure avec une mémoire partagée.

— Jonathan Ben-Avraham

@ jonathan: +1, j'ai quelques doutes: - pourquoi nous référons les pipes nommées en tant que FIFO; Que sont les objets persistants?

— Ankit

@Ankit: Certaines personnes appellent un tube nommé une FIFO car il se comporte comme une structure de données FIFO, en particulier lorsqu'il est ouvert pour la lecture et l'écriture par un processus unique. Par "objet persistant", je voulais dire qu'un canal nommé est associé à un objet système de fichiers. En d’autres termes, il s’agit d’un type de fichier, avec un nom, qui conserve la même persistance que n’importe quel autre fichier stocké sur le support.

— Jonathan Ben-Avraham

4

Un avantage non mentionné ailleurs est qu'un canal nommé peut être utilisé dans des endroits où seul un fichier suffira.

Par exemple, certains clients de messagerie ont pour fonction d’ajouter le contenu de ~ / .signature à chaque message électronique. Si .signature était une option de ligne de commande ou si le client de messagerie était capable de remarquer que .signature était exécutable et de l'exécuter, vous n'auriez pas besoin d'un canal nommé. Mais si le client de messagerie n’est pas aussi sophistiqué, vous pouvez créer un canal nommé nommé .signature et exécuter une application qui génère une nouvelle signature à chaque lecture du fichier.

— Eyal
source

Intéressant. Avez-vous une telle application? Il semble qu'il faille surveiller au niveau du noyau pour savoir quand l'accès à la FIFO a été effectué.

— Wildcard

4

Les canaux nommés présentent un autre avantage: vous pouvez les utiliser sur différents systèmes . Supposons que vous souhaitiez une communication en temps réel de deux processus s'exécutant sur des machines différentes. Ensuite, partagez un dossier entre les deux, placez votre FIFO sur le dossier, et c'est parti. C'est beaucoup plus facile que de transformer une application conçue pour travailler sur des fichiers en un service d'écoute sur un port.

— MariusMatutiae
source