socket de domaine unix VS tubes nommés?


122

Après avoir regardé un socket nommé unix et j'ai pensé qu'ils étaient nommés tubes. J'ai regardé les tuyaux de nom et je n'ai pas vu beaucoup de différence. J'ai vu qu'ils étaient initialisés différemment mais c'est la seule chose que je remarque. Les deux utilisent la fonction d'écriture / lecture C et fonctionnent de la même manière AFAIK.

Quelle est la différence entre les sockets de domaine Unix et les tubes nommés? Quand devrais-je choisir l'un sur l'autre? Lequel dois-je utiliser par défaut (comme comment utiliser le vecteur par défaut en C ++ plutôt que d'utiliser deque, list ou quoi que ce soit d'autre si j'ai des besoins)?

c  linux 

1
@GregHewgill: malheureusement, cette question concerne plus "qu'est-ce que l'IPC" plutôt que la différence que je demande: /. J'ai vu cela avant de publier, aurais-je dû créer un lien et dire que c'était lié? (ça ne m'a pas aidé)

1
@acid: Oui, lier des questions connexes et expliquer quelle question vous avez encore est toujours une bonne idée.
Ben Voigt

3
Cet article l'a assez bien résumé. Démystifier les sockets de domaine Unix: thomasstover.com/uds.html
Cong Ma

Réponses:


106

Les sockets de domaine UNIX sont généralement plus flexibles que les canaux nommés. Certains de leurs avantages sont:

  • Vous pouvez les utiliser pour plus de deux processus de communication (par exemple, un processus serveur avec potentiellement plusieurs processus clients se connectant);
  • Ils sont bidirectionnels;
  • Ils prennent en charge la transmission d'informations d'identification UID / GID vérifiées par le noyau entre les processus;
  • Ils prennent en charge la transmission de descripteurs de fichiers entre les processus;
  • Ils prennent en charge les modes paquet et paquet séquencé.

Pour utiliser un grand nombre de ces fonctionnalités, vous devez utiliser la send()/ recv()famille d'appels système plutôt que write()/ read().


11
D'un autre côté, il faut peut-être dire que les tubes de noms ont l'avantage de pouvoir être "connectés à" via des open(2)appels ordinaires , ce qui les rend plus adaptés à la construction de pipelines ad hoc entre des programmes qui ne prennent normalement que des arguments de nom de fichier.
Dolda2000

66

Une différence est que les canaux nommés sont à sens unique, vous devrez donc en utiliser deux pour établir une communication bidirectionnelle. Les prises sont bien sûr bidirectionnelles. Il semble un peu plus compliqué d'utiliser deux variables au lieu d'une (c'est-à-dire deux tubes au lieu d'un socket).

En outre, l'article de wikipedia est assez clair sur le point suivant : «Les sockets de domaine Unix peuvent être créés sous forme de flux d'octets ou de séquences de datagrammes, tandis que les tubes sont uniquement des flux d'octets.


Les canalisations nommées sont en fait bidirectionnelles mais semi-duplex . Cela signifie que la communication peut aller soit de l'extrémité A à l'extrémité B, soit de B à A, mais jamais les deux en même temps.


1
hmm intéressant +1. Savez-vous par hasard quelle est la différence entre bytestream et datagram? Peut-être un exemple dans une sentance ou deux comme vous l'avez déjà fait pour cette question?

7
@acidzombie: Un tube ou une socket en mode datagramme maintient les limites, de sorte qu'un writeappel produit un readappel. En mode flux, les données peuvent être concaténées ensemble dans un long flux, de sorte que de nombreuses écritures peuvent être lues à la fois, ou vice versa. (Windows a des tuyaux de datagramme, selon la réponse de jtoberon, Unix n'a pas)
Ben Voigt

1
@BenVoigt bien, la livraison de paquets de socket de datagramme n'est pas fiable, donc une écriture ne générera pas nécessairement un appel de lecture. Peut-être pour les prises locales, mais ce n'est pas clair dans votre commentaire. Donc, peu importe, il a des problèmes.
xaxxon le

3
@xaxxon: Les tubes et les sockets de domaine Unix sont locaux, donc sans perte, le récepteur vide du tout ses files d'attente.
Ben Voigt

6
Oui, contrairement à UDP, les sockets de domaine Unix datagramme sont garantis , livraison dans l'ordre.
jtchitty
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.