Sockets vs tubes nommés pour IPC local sous Windows?

Question

Y a-t-il des raisons de privilégier les pipes nommées sur les sockets pour IPC local (toutes deux utilisant win-api), l'efficacité-wize, resource-wize ou autre, puisque les deux se comportent très bien (et probablement d'une interface similaire)), dans une application qui est susceptible d'utiliser déjà des sockets à des fins de réseau?

Je peux nommer au moins le problème d'adressage: les numéros de port pour les sockets contre les noms de fichiers pour les tubes. De plus, les tubes nommés (AFAIK) n'alerteront pas le pare-feu (boîte de dialogue de blocage/déblocage), bien que les applications bloquées puissent toujours communiquer via des sockets localement. Autre chose à prendre en compte?

Dans le cas de l'utilisation de sockets, y a-t-il des paramètres/flags de winsock qui sont recommandés lors de l'utilisation de sockets localement?

Answer 1

Quelques différences subtiles:

Sockets ne fonctionnera pas pour IPC local si vous ne disposez pas d'un adaptateur fonctionnement. Est-il courant d'avoir un PC sans adaptateur fonctionnel? Eh bien, j'ai été mordu quand quelqu'un a essayé de montrer notre logiciel à un client sur un ordinateur portable qui n'était pas branché sur un réseau ou une alimentation électrique (le système d'exploitation a désactivé la carte réseau pour économiser l'énergie). l'utilisateur d'ordinateur portable n'a pas utilisé sans fil). Vous pouvez contourner cela en installant un adaptateur de bouclage mais ce n'est pas idéal.

Un logiciel de pare-feu peut entraîner des problèmes lors de l'établissement de connexions TCP/IP. Ce n'est pas censé être un problème pour IPC local, mais je ne suis pas convaincu. Named pipes can have firewalls too.

Vous pouvez rencontrer des problèmes en raison des privilèges requis pour créer des canaux nommés ou pour créer de nouvelles instances de canaux nommés. Par exemple, je courais plusieurs serveurs utilisant le même canal nommé (probablement pas une bonne idée, mais c'était pour tester) et certains ont échoué dans CreateNamedPipe parce que le premier serveur pour créer le canal était en mode Administrateur (parce qu'il était lancé depuis Visual Studio en mode Administrateur) tandis que le reste a été lancé à partir de la ligne de commande avec le niveau UAC normal. Bien que l'article mentionné par Rubens traite principalement de l'IPC sur un réseau, il fait remarquer que "les canaux nommés locaux s'exécutent en mode noyau et sont extrêmement rapides".

Answer 2

Une autre solution que vous pouvez envisager est une région de mémoire partagée nommée. C'est un peu de travail parce que vous devez vous-même établir un protocole de contrôle de flux, mais je l'ai utilisé avec succès dans le passé où la vitesse était la chose la plus importante.