Partager via


Opérations de canal nommé

La première fois que le serveur de canal appelle la fonction CreateNamedPipe , il utilise le paramètre nMaxInstances pour spécifier le nombre maximal d’instances du canal qui peuvent exister simultanément. Le serveur peut appeler CreateNamedPipe à plusieurs reprises pour créer des instances supplémentaires du canal, tant qu’il ne dépasse pas le nombre maximal d’instances. Si la fonction réussit, chaque appel retourne un handle à l’extrémité du serveur d’un canal nommé instance.

Dès que le serveur de canal crée un canal instance, un client de canal peut s’y connecter en appelant la fonction CreateFile ou CallNamedPipe. Si un instance de canal est disponible, CreateFile retourne un handle à l’extrémité cliente du canal instance. Si aucune instance du canal n’est disponible, un client de canal peut utiliser la fonction WaitNamedPipe pour attendre qu’un canal devienne disponible.

Un serveur de canal peut déterminer quand un client de canal est connecté à un canal instance en appelant la fonction ConnectNamedPipe. Si le handle de canal est en mode d’attente bloquant, ConnectNamedPipe ne retourne pas de données tant qu’un client n’est pas connecté.

Les clients et serveurs de canal peuvent appeler l’une des fonctions suivantes ( en plus de CallNamedPipe ) pour lire et écrire dans un canal nommé. Le comportement de ces fonctions dépend du type de canal et des modes en vigueur pour le handle de canal spécifié, comme suit :

  • Les fonctions ReadFile et WriteFile peuvent être utilisées avec des canaux de type octet ou message.
  • Les fonctions ReadFileEx et WriteFileEx peuvent être utilisées avec des canaux de type octet ou message si le handle de canal a été ouvert pour les opérations qui se chevauchent.
  • La fonction PeekNamedPipe peut être utilisée pour lire sans supprimer le contenu d’un canal de type octet ou d’un canal de type message. PeekNamedPipe peut également retourner des informations supplémentaires sur le canal instance.
  • La fonction TransactNamedPipe peut être utilisée avec des canaux duplex de type message si le handle de canal vers le processus appelant est défini en mode lecture de message. La fonction écrit un message de demande et lit un message de réponse en une seule opération, ce qui améliore les performances du réseau.

Le serveur de canal ne doit pas effectuer une opération de lecture bloquante tant que le client de canal n’a pas démarré. Sinon, une condition de concurrence peut se produire. Cela se produit généralement lorsque le code d’initialisation, tel que celui de la bibliothèque runtime C, doit verrouiller et examiner les handles hérités.

Lorsqu’un client et un serveur terminent d’utiliser un canal instance, le serveur doit d’abord appeler la fonction FlushFileBuffers pour s’assurer que tous les octets ou messages écrits dans le canal sont lus par le client. FlushFileBuffers ne retourne pas tant que le client n’a pas lu toutes les données du canal. Le serveur appelle ensuite la fonction DisconnectNamedPipe pour fermer la connexion au client de canal. Cette fonction rend le handle du client non valide, s’il n’a pas déjà été fermé. Toutes les données non lues dans le canal sont ignorées. Une fois le client déconnecté, le serveur appelle la fonction CloseHandle pour fermer son handle au canal instance. Le serveur peut également utiliser ConnectNamedPipe pour permettre à un nouveau client de se connecter à cette instance du canal.

Un processus peut récupérer des informations sur un canal nommé en appelant la fonction GetNamedPipeInfo , qui retourne le type du canal, la taille des mémoires tampons d’entrée et de sortie, ainsi que le nombre maximal d’instances de canal pouvant être créées. La fonction GetNamedPipeHandleState indique les modes de lecture et d’attente d’un handle de canal, le nombre actuel d’instances de canal et des informations supplémentaires pour les canaux qui communiquent sur un réseau. La fonction SetNamedPipeHandleState définit le mode de lecture et les modes d’attente d’un handle de canal. Pour les clients de canal qui communiquent avec un serveur distant, la fonction contrôle également le nombre maximal d’octets à collecter ou le temps d’attente maximal avant de transmettre un message (en supposant que le handle du client n’a pas été ouvert avec le mode d’écriture directe activé).