Que sont les tuyaux nommés?

Réponses:

153

Tant sur les systèmes Windows que POSIX, les canaux nommés fournissent un moyen de communication inter-processus entre les processus exécutés sur la même machine. Ce que vous offre les canaux nommés, c'est un moyen d'envoyer vos données sans avoir la pénalité de performances d'impliquer la pile réseau.

Tout comme vous avez un serveur écoutant une adresse IP / un port pour les demandes entrantes, un serveur peut également configurer un canal nommé qui peut écouter les demandes. Dans les deux cas, le processus client (ou la bibliothèque d'accès à la base de données) doit connaître l'adresse spécifique (ou le nom du canal) pour envoyer la demande. Il existe souvent une valeur par défaut standard couramment utilisée (tout comme le port 80 pour HTTP, le serveur SQL utilise le port 1433 dans TCP / IP; \\. \ Pipe \ sql \ query pour un canal nommé).

En configurant des canaux nommés supplémentaires, vous pouvez exécuter plusieurs serveurs de base de données, chacun avec ses propres écouteurs de demande.

L'avantage des canaux nommés est qu'ils sont généralement beaucoup plus rapides et libèrent des ressources de pile réseau.

- BTW, dans le monde Windows, vous pouvez également avoir des tubes nommés vers des machines distantes - mais dans ce cas, le tube nommé est transporté via TCP / IP, vous perdrez donc des performances. Utilisez des canaux nommés pour la communication avec la machine locale.

Constructeur de jouets
la source
1
Quel est le désavantage?
lindhe
2
@lindhe Pas d'opérabilité automatique sur le réseau. Généralement plus difficile à mettre en place dans la pratique. Implémentation différente sous Windows que dans les systèmes de type Unix / Unix. Ils sont cool, mais je ne dérangerais pas à moins que la performance ne soit un must.
sudo
43

Unix et Windows ont tous deux des choses appelées "tubes nommés", mais ils se comportent différemment. Sous Unix, un tube nommé est une rue à sens unique qui n'a généralement qu'un seul lecteur et un écrivain - l'écrivain écrit et le lecteur lit, vous comprenez?

Sous Windows, la chose appelée "canal nommé" est un objet IPC plus comme une socket TCP - les choses peuvent circuler dans les deux sens et il y a des métadonnées (vous pouvez obtenir les informations d'identification de la chose à l'autre bout, etc.).

Les tubes nommés Unix apparaissent sous la forme d'un fichier spécial dans le système de fichiers et sont accessibles avec les commandes normales d'E / S de fichiers, y compris le shell. Ceux de Windows ne le font pas et doivent être ouverts avec un appel système spécial (après quoi ils se comportent principalement comme un handle win32 normal).

Encore plus déroutant, Unix a quelque chose qui s'appelle un "socket Unix" ou un socket AF_UNIX, qui fonctionne plus comme (mais pas complètement comme) un "tube nommé" win32, étant bidirectionnel.

MarkR
la source
23

Linux Pipes
First In First Out (FIFO) mécanisme de communication interproccess.

Tubes sans nom
Sur la ligne de commande, représentés par un "|" entre deux commandes.

Tuyaux nommés
Un fichier spécial FIFO. Une fois créé, vous pouvez utiliser le tube comme un fichier normal (ouvrir, fermer, écrire, lire, etc.).

Pour créer un tube nommé, appelé "myPipe", à partir de la ligne de commande ( page de manuel ):

mkfifo myPipe  

Pour créer un tube nommé à partir de c, où «chemin» est le nom que vous souhaitez que le tube ait et «mode» contient les autorisations que vous voulez que le tube ait ( page de manuel ):

#include <sys/types.h>
#include <sys/stat.h>
int mkfifo(const char *pathname, mode_t mode);
John Mulder
la source
2
"vous pouvez utiliser le tube comme un fichier normal" - pas tout à fait vrai. Vous ne pouvez ni tell()positionner ni seek()dans un tuyau.
nyov
19

Selon Wikipedia :

[...] Un tube traditionnel est "sans nom" car il existe de manière anonyme et ne persiste que tant que le processus est en cours d'exécution. Un tube nommé est persistant dans le système et existe au-delà de la durée de vie du processus et doit être «dissocié» ou supprimé une fois qu'il n'est plus utilisé. Les processus s'attachent généralement au canal nommé (apparaissant généralement sous forme de fichier) pour exécuter IPC (communication inter-processus).

Jonathan Lonowski
la source
12

Comparer

echo "test" | wc

à

mkdnod apipe p
wc apipe

wc bloquera jusqu'à ce que

echo "test" > apipe

exécute

John Nilsson
la source
7

Les tuyaux sont un moyen de diffuser des données entre les applications. Sous Linux, je l'utilise tout le temps pour diffuser la sortie d'un processus dans un autre. Ceci est anonyme car l'application de destination n'a aucune idée d'où vient ce flux d'entrée. Il n'en a pas besoin.

Un tube nommé est juste un moyen de se connecter activement à un tube existant et d'aspirer ses données. C'est pour les situations où le fournisseur ne sait pas quels clients mangeront les données.

Oli
la source
6

Ceci est un extrait de Technet (donc je ne sais pas pourquoi la réponse marquée dit que les tuyaux nommés sont plus rapides ??):

Tuyaux nommés et sockets TCP / IP

Dans un environnement de réseau local (LAN) rapide, les sockets TCP / IP (Transmission Control Protocol / Internet Protocol) et les clients Named Pipes sont comparables en termes de performances. Cependant, la différence de performances entre les sockets TCP / IP et les clients de canaux nommés devient apparente avec des réseaux plus lents, tels que les réseaux étendus (WAN) ou les réseaux commutés. Ceci est dû aux différentes façons dont les mécanismes de communication interprocessus (IPC) communiquent entre pairs.

Pour les canaux nommés, les communications réseau sont généralement plus interactives. Un pair n'envoie pas de données jusqu'à ce qu'un autre pair les demande à l'aide d'une commande de lecture. Une lecture réseau implique généralement une série de messages de canaux nommés avant de commencer à lire les données. Ceux-ci peuvent être très coûteux dans un réseau lent et entraîner un trafic réseau excessif , qui à son tour affecte d'autres clients du réseau.

Il est également important de clarifier si vous parlez de tuyaux locaux ou de tuyaux de réseau. Si l'application serveur s'exécute localement sur l'ordinateur qui exécute une instance de SQL Server, le protocole local Named Pipes est une option. Les tubes nommés locaux fonctionnent en mode noyau et sont très rapides.

Pour les sockets TCP / IP, les transmissions de données sont plus rationalisées et ont moins de frais généraux. Les transmissions de données peuvent également tirer parti des mécanismes d'amélioration des performances des sockets TCP / IP tels que le fenêtrage, les accusés de réception différés, etc. Cela peut être très utile dans un réseau lent. Selon le type d'applications, ces différences de performances peuvent être importantes.

Les sockets TCP / IP prennent également en charge une file d'attente de backlog. Cela peut fournir un effet de lissage limité par rapport aux canaux nommés qui pourraient entraîner des erreurs de canal occupé lorsque vous essayez de vous connecter à SQL Server.

Généralement, TCP / IP est préféré dans un réseau LAN, WAN ou commuté lent, tandis que les canaux nommés peuvent être un meilleur choix lorsque la vitesse du réseau n'est pas le problème, car il offre plus de fonctionnalités, de facilité d'utilisation et d'options de configuration.

Ness
la source
5

Communication inter-processus (principalement) pour les applications Windows. Similaire à l'utilisation de sockets pour communiquer entre les applications sous Unix.

MSDN

Ken
la source
4
Les tubes nommés sont apparus dans V6 ou AT&T Unix vers 1975.
dmckee --- ex-moderator chaton
Doh! C'est un peu avant Microsoft. Autant que je sache, ils ne sont pas souvent utilisés dans les applications Unix / Linux. Vrai?
Ken
J'utilise un tube nommé pour mon générateur de signature aléatoire - puisque les applications mail et usenet s'attendent à ce qu'un fichier nommé $ HOME / .signature ait votre signature, mon programme crée .signature en tant que tube nommé et y écrit des citations aléatoires.
Paul Tomblin
3

Les tubes nommés dans un contexte unix / linux peuvent être utilisés pour faire communiquer deux shells différents car un shell ne peut tout simplement rien partager avec un autre.

De plus, un script instancié deux fois dans le même shell ne peut rien partager via les deux instances. J'ai trouvé une utilisation des tubes nommés lors du codage d'un démon contenant les fonctions start () et stop (), et je voulais utiliser le même script pour effectuer les deux actions.

Sans tubes nommés (ou tout type de sémaphore), démarrer le script en arrière-plan n'est pas un problème. Le problème, c'est que lorsque cela se termine, vous ne pouvez tout simplement pas accéder à l'instance en arrière-plan.

Donc, quand vous voulez lui envoyer la commande stop, vous ne pouvez tout simplement pas: exécuter le même script sans tubes nommés et appeler la fonction stop () ne fera rien puisque vous exécutez en fait une autre instance.

La solution était d'implémenter deux tubes, un READ et l'autre WRITE lorsque vous démarrez le démon. Puis faites-lui, parmi ses autres tâches, écouter le tube READ. Ensuite, la fonction Stop () contient une commande qui écrira un message dans le tube, qui sera gérée par le script en arrière-plan qui exécutera une sortie 0. De cette façon, notre deuxième instance du même script n'a qu'une tâche à faire: dites à la première instance d'arrêter.

De cette façon, un et un seul script peut démarrer et s'arrêter.

Bien sûr, vous avez différentes manières de le faire en déclenchant l'arrêt via une touche par exemple. Mais celui-ci est agréable et intéressant à coder.

Nicolas Mas
la source
1

Named pipes est un système Windows pour la communication inter-processus. Dans le cas d'un serveur SQL, si le serveur est sur la même machine que le client, il est alors possible d'utiliser des canaux nommés pour transférer les données, par opposition à TCP / IP.

eulerfx
la source
Ce n'est pas uniquement Windows, comme votre réponse le fait apparaître. Comme d'autres l'ont déjà noté, les tubes nommés existent depuis les années 70 sous UNIX, généralement avec l'apparence d'un fichier spécial. A voté quand même, mais corrigez votre réponse.
Chris Charabaruk