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 à la fin du serveur d’une instance de canal nommé.

Dès que le serveur de canal crée une instance de canal, un client de canal peut se connecter à celui-ci en appelant la fonction CreateFile ou CallNamedPipe. Si une instance de canal est disponible, CreateFile retourne un handle à la fin du client de l’instance de canal. 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é à une instance de canal en appelant la fonction ConnectNamedPipe. Si le handle de canal est en mode d’attente bloquant, ConnectNamedPipe ne retourne pas tant qu’un client n’est pas connecté.

Les clients et serveurs de canal peuvent appeler l’une des fonctions ( 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 de type message.
• Les fonctions ReadFileEx et WriteFileEx peuvent être utilisées avec des canaux de type octet ou de type message si le handle de canal a été ouvert pour les opérations superposées.
• 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 pouvez également retourner des informations supplémentaires sur l’instance de canal.
• 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 sur le mode de lecture de message. La fonction écrit un message de demande et lit un message de réponse dans une seule opération, améliorant ainsi les performances réseau.

Le serveur de canal ne doit pas effectuer d’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 lors de l’initialisation du code, tel que celui de la bibliothèque runtime C, doit verrouiller et examiner les handles hérités.

Lorsqu’un client et un serveur se terminent à l’aide d’une instance de canal, le serveur doit d’abord appeler la fonction FlushFileBuffers, pour vous 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 à l’instance de canal. 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 et le nombre maximal d’instances de canal pouvant être créées. Le GetNamedPipeHandleState des rapports de fonction sur 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 lecture et les modes d’attente d’un handle de canal. Pour les clients de canal communiquant avec un serveur distant, la fonction contrôle également le nombre maximal d’octets à collecter ou le temps maximal d’attente avant de transmettre un message (en supposant que le handle du client n’a pas été ouvert avec le mode d’écriture directe activé).