.\" -*- coding: UTF-8 -*- .\" SPDX-License-Identifier: Linux-man-pages-1-para .\" .\" This man page is Copyright (C) 1999 Andi Kleen , .\" Copyright (C) 2008-2014, Michael Kerrisk , .\" and Copyright (C) 2016, Heinrich Schuchardt .\" .\" Modified, 2003-12-02, Michael Kerrisk, .\" Modified, 2003-09-23, Adam Langley .\" Modified, 2004-05-27, Michael Kerrisk, .\" Added SOCK_SEQPACKET .\" 2008-05-27, mtk, Provide a clear description of the three types of .\" address that can appear in the sockaddr_un structure: pathname, .\" unnamed, and abstract. .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH UNIX 7 "15 juin 2024" "Pages du manuel de Linux 6.9.1" .SH NOM unix – Sockets pour communications locales entre processus .SH SYNOPSIS .nf \fB#include \fP \fB#include \fP .P \fIunix_socket\fP\fB = socket(AF_UNIX, type, 0);\fP \fIerror\fP\fB = socketpair(AF_UNIX, type, 0, int *\fP\fIsv\fP\fB);\fP .fi .SH DESCRIPTION La famille de sockets \fBAF_UNIX\fP (aussi connue sous le nom de \fBAF_LOCAL\fP) sert à communiquer efficacement entre processus sur la même machine. Traditionnellement, les sockets de domaine UNIX peuvent ne pas être nommés ou bien être liés à un chemin d'accès de système de fichiers, lequel sera marqué comme étant de type socket. Linux gère également un espace de noms abstrait, indépendant du système de fichiers. .P Les types de sockets valables dans le domaine UNIX sont\ : \fBSOCK_STREAM\fP pour un socket orienté flux et \fBSOCK_DGRAM\fP pour un socket orienté datagramme qui préserve les limites entre messages (comme sur la plupart des implémentations UNIX, les sockets datagramme de domaine UNIX sont toujours fiables et ne réordonnent pas les datagrammes), et (depuis Linux 2.6.4) \fBSOCK_SEQPACKET\fP pour un socket orienté connexion, préservant les limites entre messages et délivrant les messages dans l'ordre où ils ont été envoyés. .P Les sockets de domaine UNIX prennent en charge la transmission de descripteurs de fichier ou d'accréditations d'un processus à l'autre en utilisant des données annexes. .SS "Formats d'adresse" Une adresse de socket de domaine UNIX est représentée dans la structure suivante : .P .in +4n .EX .\" #define UNIX_PATH_MAX 108 .\" struct sockaddr_un { sa_family_t sun_family; /* AF_UNIX */ char sun_path[108]; /* Chemin d’accès */ }; .EE .in .P The \fIsun_family\fP field always contains \fBAF_UNIX\fP. On Linux, \fIsun_path\fP is 108 bytes in size; see also BUGS, below. .P Various system calls (for example, \fBbind\fP(2), \fBconnect\fP(2), and \fBsendto\fP(2)) take a \fIsockaddr_un\fP argument as input. Some other system calls (for example, \fBgetsockname\fP(2), \fBgetpeername\fP(2), \fBrecvfrom\fP(2), and \fBaccept\fP(2)) return an argument of this type. .P Trois types d’adresse sont remarquables dans la structure \fIsockaddr_un\fP : .TP pathname a UNIX domain socket can be bound to a null\-terminated filesystem pathname using \fBbind\fP(2). When the address of a pathname socket is returned (by one of the system calls noted above), its length is .IP .in +4n .EX offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1 .EE .in .IP et \fIsun_path\fP contient le chemin avec un octet NULL final. (Dans Linux, l’expression ci\-dessus \fBoffsetof\fP() est égale à la même valeur que \fIsizeof(sa_family_t)\fP, mais quelques autres implémentations incluent d’autres champs avant \fIsun_path\fP, aussi l’expression \fBoffsetof\fP() plus portable décrit la taille de la structure d’adresse.) .IP Pour plus de détails sur les sockets chemin, voir ci\-après. .TP unnamed .\" There is quite some variation across implementations: FreeBSD .\" says the length is 16 bytes, HP-UX 11 says it's zero bytes. A stream socket that has not been bound to a pathname using \fBbind\fP(2) has no name. Likewise, the two sockets created by \fBsocketpair\fP(2) are unnamed. When the address of an unnamed socket is returned, its length is \fIsizeof(sa_family_t)\fP, and \fIsun_path\fP should not be inspected. .TP abstract an abstract socket address is distinguished (from a pathname socket) by the fact that \fIsun_path[0]\fP is a null byte (\[aq]\[rs]0\[aq]). The socket's address in this namespace is given by the additional bytes in \fIsun_path\fP that are covered by the specified length of the address structure. (Null bytes in the name have no special significance.) The name has no connection with filesystem pathnames. When the address of an abstract socket is returned, the returned \fIaddrlen\fP is greater than \fIsizeof(sa_family_t)\fP (i.e., greater than 2), and the name of the socket is contained in the first \fI(addrlen \- sizeof(sa_family_t))\fP bytes of \fIsun_path\fP. .SS "Sockets chemin d’accès" Lors de la liaison d’un socket à un chemin, quelques règles doivent être observées pour une portabilité maximale et une facilité de codage : .IP \- 3 Le chemin dans \fIsun_path\fP doit être terminé par un octet NULL ; .IP \- La taille du chemin, y compris l’octet NULL final, ne doit pas excéder la taille de \fIsun_path\fP ; .IP \- L’argument \fIaddrlen\fP décrivant la structure enfermant \fIsockaddr_un\fP doit avoir une valeur d’au moins : .IP .in +4n .EX offsetof(struct sockaddr_un, sun_path)+strlen(addr.sun_path)+1 .EE .in .IP ou, plus simplement, \fIaddrlen\fP peut être indiqué comme \fIsizeof(struct\ sockaddr_un)\fP. .P .\" Linux does this, including for the case where the supplied path .\" is 108 bytes Il y a quelques variations dans la façon dont les implémentations gèrent les adresses de socket de domaine UNIX qui ne suivent pas les règles ci\-dessus.Par exemple, quelques implémentations (mais pas toutes) ajoutent un octet NULL final si aucun n’est présent dans le \fIsun_path\fP fourni. .P .\" HP-UX .\" Modern BSDs generally have 104, Tru64 and AIX have 104, .\" Solaris and Irix have 108 Lors du codage d’applications portables, il faut penser que certaines implémentations ont un \fIsun_path\fP aussi court que 92 octets. .P .\" Divers appels système (\fBaccept\fP(2), \fBrecvfrom\fP(2), \fBgetsockname\fP(2), \fBgetpeername\fP(2)) renvoient les structures d’adresse de socket. Lorsque appliqué à des sockets de domaine UNIX, l’argument « value\-result » \fIaddrlen\fP fourni à l’appel devrait être initialisé comme ci\-dessus. Au renvoi, l’argument est réglé pour indiquer la taille \fIréelle\fP de la structure d’adresse. L’appelant devrait vérifier la valeur renvoyée dans cet argument. Si la valeur de sortie excède la valeur d’entrée, alors il n’y a aucune garantie qu’un octet NULL final soit présent dans \fIsun_path\fP. (Consultez BOGUES.) .SS "Permissions et appartenance des sockets chemin d’accès" Dans l’implémentation de Linux, les sockets chemin d'accès respectent les permissions du répertoire dans lequel ils sont. La création d’un nouveau socket échoue si le processus n’a pas les permissions d’écriture et de recherche (exécution) dans le répertoire où le socket est créé. .P Dans Linux, la connexion à un objet de socket flux nécessite la permission en écriture sur ce socket. De même, l’envoi d’un datagramme à un socket datagramme nécessite la permission en écriture sur ce socket. POSIX ne fait aucune déclaration sur les effets des permissions sur un fichier de socket, et sur certains systèmes (par exemple, les BSD anciens) les permissions de socket sont ignorées. Les programmes portables ne devraient pas se fier à cette fonctionnalité pour la sécurité. .P Lors de la création d’un nouveau socket, le propriétaire et le groupe d’un fichier de socket sont définis selon les règles habituelles. Le fichier de socket a toutes les permissions activées, autres que celles désactivées par le processus \fBumask\fP(2). .P .\" However, fchown() and fchmod() do not seem to have an effect .\" Le propriétaire, le groupe et les permissions d’un socket chemin d'accès peuvent être modifiés (avec \fBchown\fP(2) et \fBchmod\fP(2)). .SS "Sockets abstraits" Les permissions de socket n’ont aucun sens pour les sockets abstraits : le processus \fBumask\fP(2) n’a aucun effet lors de la liaison d’un socket abstrait et modifier le propriétaire et les permissions de l’objet (avec \fBfchown\fP(2) et \fBfchmod\fP(2)) n’a aucun effet sur l’accessibilité du socket. .P Les sockets abstraits disparaissent automatiquement quand toutes les références de socket ouvertes sont refermées. .P .\" L’espace de noms de sockets abstraits est une extension non portable de Linux. .SS "Options de socket" Pour des raisons historiques, les options de ces sockets sont indiquées avec un type \fBSOL_SOCKET\fP même si elles sont spécifiques à \fBAF_UNIX\fP. Elles peuvent être définies avec \fBsetsockopt\fP(2) et lues avec \fBgetsockopt\fP(2) en indiquant \fBSOL_SOCKET\fP comme famille de sockets. .TP \fBSO_PASSCRED\fP Activer cette option de socket provoque la réception des accréditations du processus émetteur dans un message \fBSCM_CREDENTIALS annexe\fP dans chaque message reçu ultérieur. Les accréditations renvoyées sont celles indiquées par l’émetteur en utilisant \fBSCM_CREDENTIALS\fP ou celles par défaut qui incluent le PID, l’ID utilisateur réel et l’ID groupe réel de l’émetteur si celui\-ci ne précise pas les données auxiliaires \fBSCM_CREDENTIALS\fP. .IP Lorsque cette option est active et le socket non encore connecté, un nom unique dans l'espace de noms abstrait sera généré automatiquement. .IP La valeur donnée comme argument pour \fBsetsockopt\fP(2) et renvoyée comme résultat de \fBgetsockopt\fP(2) est un indicateur booléen entier. .TP \fBSO_PASSSEC\fP Activer la réception de l’étiquette de sécurité SELinux du socket pair dans un message annexe de type \fBSCM_SECURITY\fP (voir ci\-dessous). .IP La valeur donnée comme argument pour \fBsetsockopt\fP(2) et renvoyée comme résultat de \fBgetsockopt\fP(2) est un indicateur booléen entier. .IP .\" commit 877ce7c1b3afd69a9b1caeb1b9964c992641f52a .\" commit 37a9a8df8ce9de6ea73349c9ac8bdf6ba4ec4f70 L’option \fBSO_PASSSEC\fP est gérée par les sockets datagramme de domaine UNIX depuis Linux 2.6.18. La prise en charge pour les sockets flux de domaine UNIX a été ajoutée dans Linux 4.2. .TP \fBSO_PEEK_OFF\fP Consulter \fBsocket\fP(7). .TP \fBSO_PEERCRED\fP This read\-only socket option returns the credentials of the peer process connected to this socket. The returned credentials are those that were in effect at the time of the call to \fBconnect\fP(2), \fBlisten\fP(2), or \fBsocketpair\fP(2). .IP L’argument de \fBgetsockopt\fP(2) est un pointeur vers une structure \fIucred\fP. Est définie la macro de test de fonctionnalité \fB_GNU_SOURCE\fP pour obtenir la définition de cette structure à partir de \fI\fP. .IP L’utilisation de cette option est possible seulement pour les sockets flux \fBAF_UNIX\fP connectés et pour les pairs de sockets flux et datagramme \fBAF_UNIX\fP créés en utilisant \fBsocketpair\fP(2). .TP \fBSO_PEERSEC\fP Cette option de socket en lecture exclusivement renvoie le contexte de sécurité du socket pair connecté à ce socket. Par défaut, cela sera le même que le contexte de sécurité du processus ayant créé le socket pair à moins qu’il ne soit écrasé par la politique ou par un processus ayant les permissions requises. .IP L’argument de \fBgetsockopt\fP(2) est un pointeur vers un tampon de la longueur indiquée en octets dans lequel la chaîne de contexte de sécurité sera copiée. Si la taille du tampon est inférieure à celle de la chaîne du contexte de sécurité, alors \fBgetsockopt\fP(2) renvoie \fB\-1\fP, définit \fIerrno\fP à \fBERANGE\fP et renvoie la taille requise à l’aide de \fIoptlen\fP. L’appelant doit allouer initialement au moins \fBNAME_MAX\fP octets pour le tampon, bien que cela ne soit pas garanti d'être suffisant. Redimensionner le tampon à la taille renvoyée et réessayer peuvent être nécessaires. .IP La chaîne de contexte de sécurité peut inclure un octet NULL final dans la taille renvoyée, mais il n’est pas garanti que ce soit fait : un contexte de sécurité « abc » peut être représenté soit par {'a','b','c'} de taille 3, ou {'a','b','c','\e0'} de taille 4, qui sont considérés comme interchangeables. La chaîne peut être affichée, mais ne contient pas d’octet NULL final, et elle est dans un encodage non précisé (en particulier, il n’est pas garanti que ce soit ASCII ou UTF\-8). .IP .\" commit 0b811db2cb2aabc910e53d34ebb95a15997c33e7 .\" L’utilisation de cette option pour les sockets dans la famille d’adresses \fBAF_UNIX\fP est prise en charge depuis Linux 2.6.2 pour les sockets flux connectés et aussi, depuis Linux 4.18, pour les pairs de socket flux et datagramme créés en utilisant \fBsocketpair\fP(2). .SS "Fonctionnalité d'autolien (« autobind »)" .\" i.e., sizeof(short) If a \fBbind\fP(2) call specifies \fIaddrlen\fP as \fIsizeof(sa_family_t)\fP, or the \fBSO_PASSCRED\fP socket option was specified for a socket that was not explicitly bound to an address, then the socket is autobound to an abstract address. The address consists of a null byte followed by 5 bytes in the character set \fI[0\-9a\-f]\fP. Thus, there is a limit of 2\[ha]20 autobind addresses. (From Linux 2.1.15, when the autobind feature was added, 8 bytes were used, and the limit was thus 2\[ha]32 autobind addresses. The change to 5 bytes came in Linux 2.3.15.) .SS "API des sockets" Les paragraphes suivants décrivent des détails spécifiques aux domaines et des fonctionnalités de l'API des sockets de domaine UNIX non prises en charge sous Linux. .P Les sockets de domaine UNIX ne prennent pas en charge la transmission de données hors\-bande (l'indicateur \fBMSG_OOB\fP de \fBsend\fP(2) et \fBrecv\fP(2)). .P L'indicateur \fBMSG_MORE\fP de \fBsend\fP(2) n'est pas pris en charge sur les sockets de domaine UNIX. .P .\" commit 9f6f9af7694ede6314bed281eec74d588ba9474f Avant Linux 3.4, l'utilisation de \fBMSG_TRUNC\fP dans le paramètre \fIflags\fP de \fBrecv\fP(2) n'était pas prise en charge par les sockets de domaine UNIX. .P L'option \fBSO_SNDBUF\fP de socket a un effet pour les sockets de domaine UNIX, mais l’option \fBSO_RCVBUF\fP n'en a pas. Pour les sockets datagramme, la valeur \fBSO_SNDBUF\fP impose une limite supérieure à la taille des datagrammes sortants. Cette limite est calculée comme le double de la valeur de l'option, moins 32 octets utilisés par le surdébit. .SS "Messages annexes" Les données annexes sont envoyées et reçues en utilisant \fBsendmsg\fP(2) et \fBrecvmsg\fP(2). Pour des raisons historiques, les messages annexes listés ci\-dessous sont indiqués avec un type \fBSOL_SOCKET\fP même s'ils sont spécifiques \fBAF_UNIX\fP. Pour les envoyer, définissez le champ \fIcmsg_level\fP de la structure \fIcmsghdr\fP à \fBSOL_SOCKET\fP et le champ \fIcmsg_type\fP au type. Pour plus de détails, consultez \fBcmsg\fP(3). .TP \fBSCM_RIGHTS\fP Envoyer ou recevoir un jeu de descripteurs de fichier ouverts d’un autre processus. La partie données contient un tableau d’entiers de descripteurs de fichier. .IP Couramment, cette opération est appelée « passage d’un descripteur de fichier » à un autre processus. Cependant, plus précisément, ce qui a été passé est une référence à une description de fichier ouvert (consultez \fBopen\fP(2)), et, dans le processus récepteur, il est probable qu’un numéro différent de descripteur de fichier sera utilisé. Sémantiquement, cette opération est équivalente à dupliquer (\fBdup\fP(2)) un descripteur de fichier dans une table de descripteurs de fichier d’un autre processus. .IP Si le tampon utilisé pour recevoir les données annexes contenant les descripteurs de fichier est trop petit (ou absent), alors les données annexes sont tronquées (ou ignorées) et les descripteurs de fichier en excès sont automatiquement clos dans le processus récepteur. .IP Si le nombre de descripteurs de fichier reçus dans les données annexes conduit le processus à dépasser la limite de ressources \fBRLIMIT_NOFILE\fP (consultez \fBgetrlimit\fP(2)), les descripteurs de fichier en excès sont automatiquement clos dans le processus récepteur. .IP .\" commit bba14de98753cb6599a2dae0e520714b2153522d The kernel constant \fBSCM_MAX_FD\fP defines a limit on the number of file descriptors in the array. Attempting to send an array larger than this limit causes \fBsendmsg\fP(2) to fail with the error \fBEINVAL\fP. \fBSCM_MAX_FD\fP has the value 253 (or 255 before Linux 2.6.38). .TP \fBSCM_CREDENTIALS\fP Envoyer ou recevoir les accréditations UNIX. Cela peut servir à l'authentification. Les accréditations sont passées en message annexe \fIstruct\ ucred\fP. Cette structure est définie dans \fI\fP comme ceci : .IP .in +4n .EX struct ucred { pid_t pid; /* PID processus émetteur */ uid_t uid; /* UID processus émetteur */ gid_t gid; /* GID processus émetteur */ }; .EE .in .IP Depuis la glibc 2.8, la macro de test de fonctionnalités \fB_GNU_SOURCE\fP doit être définie (avant d'inclure \fItout\fP fichier d'en\(hytête) afin d'obtenir la définition de cette structure. .IP Les accréditations que l'émetteur envoie sont vérifiées par le noyau. Un processus privilégié est autorisé à indiquer des valeurs qui ne correspondent pas aux siennes. L'émetteur doit indiquer son propre PID (sauf s'il a la capacité \fBCAP_SYS_ADMIN\fP), auquel cas le PID de n’importe quel processus existants peut être indiqué, son ID utilisateur réel, son ID utilisateur effectif ou son « saved set\-user\-ID » (sauf s'il a la capacité \fBCAP_SETUID\fP) et son ID groupe réel, son ID groupe effectif ou son « saved set\-group\-ID » (sauf s'il a la capacité \fBCAP_SETGID\fP). .IP Pour recevoir un message \fIstruct\ ucred\fP, l’option \fBSO_PASSCRED\fP doit être activée sur le socket. .TP \fBSCM_SECURITY\fP Recevoir le contexte de sécurité SELinux (l’étiquette de sécurité) du socket pair. Les données annexes reçues sont une chaîne terminée par un octet NULL final contenant le contexte de sécurité. Le récepteur doit au moins allouer \fBNAME_MAX\fP octets dans la partie données du message annexe pour ces données. .IP Pour recevoir le contexte de sécurité, l’option \fBSO_PASSSEC\fP doit être activée sur le socket (voir ci\-dessus). .P Lors de l’envoi des données annexes avec \fBsendmsg\fP(2), seul un élément de chacun des types ci\-dessus peut être inclus dans le message envoyé. .P Au moins un octet des données réelles doit être envoyé lors de l’envoi des données annexes. Sur Linux, cela est nécessaire pour envoyer avec succès les données annexes sur un socket flux de domaine UNIX. Lors de l’envoi des données annexes à travers un socket datagramme de domaine UNIX, il n’est pas nécessaire sur Linux d’envoyer en accompagnement une donnée quelconque réelle. Cependant, les applications portables devraient aussi inclure au moins un octet des données réelles lors de l’envoi de données annexes à travers un socket datagramme. .P Lors de la réception à partir d’un socket flux, les données annexes forment une sorte de barrière pour les données reçues. Par exemple, en supposant que l’émetteur transmet comme suit : .P .RS .PD 0 .IP (1) 5 \fBsendmsg\fP(2) de quatre octets sans données annexes. .IP (2) \fBsendmsg\fP(2) d’un octet avec données annexes. .IP (3) \fBsendmsg\fP(2) de quatre octets sans données annexes. .PD .RE .P En supposant que le récepteur réalise maintenant des appels \fBrecvmsg\fP(2) avec chacun une taille de tampon de 20 octets, le premier appel recevra 5 octets de données, avec les données annexes envoyées par le second appel \fBsendmsg\fP(2). Le prochain appel recevra les 4 octets de données restants. .P .\" Si l’espace alloué pour recevoir les données annexes entrantes est trop petit, alors ces données sont tronquées au nombre d’en\-têtes qui peuvent loger dans le tampon fourni (ou, dans le cas de liste de descripteurs de fichier \fBSCM_RIGHTS\fP, cette liste peut être tronquée). Si aucun tampon n’est fourni pour les données annexes entrantes (c’est\-à\-dire si le champ \fImsg_control\fP de la structure \fImsghdr\fP fourni à \fBrecvmsg\fP(2) est NULL), alors les données annexes entrantes sont ignorées. Dans les deux cas, l’indicateur \fBMSG_CTRUNC\fP sera réglé dans la valeur \fImsg.msg_flags\fP renvoyée par \fBrecvmsg\fP(2). .SS Ioctls Les appels \fBioctl\fP(2) suivants renvoient des informations dans \fIvalue\fP. La syntaxe correcte est\ : .P .RS .nf \fBint\fP\fI value\fP\fB;\fP \fIerror\fP\fB = ioctl(\fP\fIunix_socket\fP\fB, \fP\fIioctl_type\fP\fB, &\fP\fIvalue\fP\fB);\fP .fi .RE .P \fIioctl_type\fP peut être\ : .TP \fBSIOCINQ\fP .\" FIXME . https://www.sourceware.org/bugzilla/show_bug.cgi?id=12002, .\" filed 2010-09-10, may cause SIOCINQ to be defined in glibc headers .\" SIOCOUTQ also has an effect for UNIX domain sockets, but not .\" quite what userland might expect. It seems to return the number .\" of bytes allocated for buffers containing pending output. .\" That number is normally larger than the number of bytes of pending .\" output. Since this info is, from userland's point of view, imprecise, .\" and it may well change, probably best not to document this now. Pour les sockets \fBSOCK_STREAM\fP, cet appel renvoie la quantité de données non lues dans le tampon de réception. Le socket ne doit pas être dans l'état LISTEN, sinon l'erreur \fBEINVAL\fP est renvoyée. \fBSIOCINQ\fP est défini dans \fI\fP. Une alternative est d'utiliser le synonyme \fBFIONREAD\fP défini dans \fI\fP. Pour les sockets \fBSOCK_DGRAM\fP, la valeur renvoyée est la même que pour les sockets datagramme de domaine Internet. Consultez \fBudp\fP(7). .SH ERREURS .TP \fBEADDRINUSE\fP L'adresse locale indiquée est déjà utilisée ou l'objet de socket de système de fichiers existe déjà. .TP \fBEBADF\fP Cette erreur peut survenir pour \fBsendmsg\fP(2) lors de l’envoi d’un descripteur de fichier pour des données annexes au travers d’un socket de domaine UNIX (consultez la description de \fBSCM_RIGHTS\fP ci\-dessus) et indique que le numéro de descripteur de fichier envoyé n’est pas valable (par exemple, ce n’est pas un descripteur de fichier ouvert). .TP \fBECONNREFUSED\fP L'adresse distante indiquée par \fBconnect\fP(2) n'était pas un socket en écoute. Cette erreur peut également se produire si le nom de chemin cible n'est pas un socket. .TP \fBECONNRESET\fP Le socket distant a été fermé de manière inattendue. .TP \fBEFAULT\fP Adresse mémoire utilisateur incorrecte. .TP \fBEINVAL\fP Argument passé non valable. Une cause habituelle est que la valeur de \fBAF_UNIX\fP n'était pas indiquée dans le champ \fIsun_type\fP des adresses passées ou que le socket était dans un état non valable pour l'opération appliquée. .TP \fBEISCONN\fP \fBconnect\fP(2) a été appelée sur un socket déjà connecté ou l'adresse cible a été indiquée sur un socket connecté. .TP \fBENFILE\fP La limite du nombre total de fichiers ouverts pour le système entier a été atteinte. .TP \fBENOENT\fP Le chemin de l'adresse distante indiquée à \fBconnect\fP(2) n'existait pas. .TP \fBENOMEM\fP Plus assez de mémoire. .TP \fBENOTCONN\fP L'opération nécessite une adresse cible, mais le socket n'est pas connecté. .TP \fBEOPNOTSUPP\fP Opération de flux appelée sur un socket non orienté flux ou tentative d'utiliser une option de données hors\-bande. .TP \fBEPERM\fP L'émetteur a transmis des accréditations incorrectes dans \fIstruct\ ucred\fP. .TP \fBEPIPE\fP Le socket distant a été fermé à cause d’un socket flux. Si activé, un signal \fBSIGPIPE\fP est émis également. Cela peut être évité en passant l'indicateur \fBMSG_NOSIGNAL\fP dans \fBsend\fP(2) ou \fBsendmsg\fP(2). .TP \fBEPROTONOSUPPORT\fP Le protocole fourni n'est pas \fBAF_UNIX\fP. .TP \fBEPROTOTYPE\fP Le socket distant ne correspond pas au type de socket local (\fBSOCK_DGRAM\fP versus \fBSOCK_STREAM\fP) .TP \fBESOCKTNOSUPPORT\fP Type de socket inconnu. .TP \fBESRCH\fP Lors de l’envoi d’un message annexe contenant des accréditations (\fBSCM_CREDENTIALS\fP), l’appelant a indiqué un PID ne correspondant à aucun processus existant. .TP \fBETOOMANYREFS\fP Cette erreur peut se produire pour \fBsendmsg\fP(2) lors de l’envoi d’un descripteur de fichier pour des données annexes à travers un socket de domaine UNIX (consultez la description de \fBSCM_RIGHTS\fP, ci\-dessus). Cela se produit si le nombre de descripteurs de fichier « en cours » excède la limite de ressources \fBRLIMIT_NOFILE\fP et si l’appelant n’a pas la capacité \fBCAP_SYS_RESOURCE\fP. Un descripteur de fichier en cours est un descripteur qui a été envoyé en utilisant \fBsendmsg\fP(2) mais qui n’a pas encore été accepté dans le processus récepteur en utilisant \fBrecvmsg\fP(2). .IP .\" commit 712f4aad406bb1ed67f3f98d04c044191f0ff593 Cette erreur est décelée depuis Linux 4.5 (et dans quelques versions précédentes dans lesquelles le correctif a été rétroporté). Dans les versions du noyau précédentes, il était possible d’avoir un nombre illimité de descripteurs de fichier en cours en envoyant chaque descripteur de fichier avec \fBsendmsg\fP(2) et ensuite en fermant le descripteur de fichier de telle façon qu’il ne soit pas pris en compte pour la limite de ressources \fBRLIMIT_NOFILE\fP. .P D'autres erreurs peuvent être déclenchées par la couche générique de socket ou par le système de fichiers lors de la génération d’un objet socket de système de fichiers. Consultez les pages de manuel correspondantes pour plus de détails. .SH VERSIONS \fBSCM_CREDENTIALS\fP et l'espace de noms abstrait ont été introduits avec Linux 2.2 et ne doivent pas être utilisés dans des programmes portables. (Certains systèmes dérivés de BSD prennent aussi en charge le passage d'accréditations, mais les détails d'implémentation diffèrent). .SH NOTES Lier un socket avec un nom de fichier crée un socket dans le système de fichiers que l’appelant doit détruire lorsqu'il n'est plus utile (en utilisant \fBunlink\fP(2)). La sémantique habituelle la plus proche d’UNIX s'applique\ ; le socket peut être délié à tout moment et sera finalement supprimé du système de fichiers lorsque sa dernière référence sera fermée. .P To pass file descriptors or credentials over a \fBSOCK_STREAM\fP socket, you must send or receive at least one byte of nonancillary data in the same \fBsendmsg\fP(2) or \fBrecvmsg\fP(2) call. .P .\" Les sockets flux de domaine UNIX ne prennent pas en charge la notion de données hors\-bande. .SH BOGUES .\" The behavior on Solaris is quite similar. When binding a socket to an address, Linux is one of the implementations that append a null terminator if none is supplied in \fIsun_path\fP. In most cases this is unproblematic: when the socket address is retrieved, it will be one byte longer than that supplied when the socket was bound. However, there is one case where confusing behavior can result: if 108 non\-null bytes are supplied when a socket is bound, then the addition of the null terminator takes the length of the pathname beyond \fIsizeof(sun_path)\fP. Consequently, when retrieving the socket address (for example, via \fBaccept\fP(2)), if the input \fIaddrlen\fP argument for the retrieving call is specified as \fIsizeof(struct sockaddr_un)\fP, then the returned address structure \fIwon't\fP have a null terminator in \fIsun_path\fP. .P .\" i.e., traditional BSD De plus, quelques implémentations n’ont pas besoin d’octet NULL final lors de liaison d’un socket (l’argument \fIaddrlen\fP est utilisé pour déterminer la taille de \fIsun_path\fP) et lorsqu’une adresse de socket est récupérée sur ces implémentations, il n’y a pas d’octet NULL final dans \fIsun_path\fP. .P Les applications qui récupèrent les adresses de socket peuvent coder (de manière portable) pour gérer la possibilité d’absence d’octet NULL final dans \fIsun_path\fP en respectant le fait que le nombre d’octets autorisés dans le nom de chemin est : .P .in +4n .EX strnlen(addr.sun_path, addrlen \- offsetof(sockaddr_un, sun_path)) .EE .in .\" The following patch to amend kernel behavior was rejected: .\" http://thread.gmane.org/gmane.linux.kernel.api/2437 .\" Subject: [patch] Fix handling of overlength pathname in AF_UNIX sun_path .\" 2012-04-17 .\" And there was a related discussion in the Austin list: .\" http://thread.gmane.org/gmane.comp.standards.posix.austin.general/5735 .\" Subject: Having a sun_path with no null terminator .\" 2012-04-18 .\" .\" FIXME . Track http://austingroupbugs.net/view.php?id=561 .P Sinon, une application peut récupérer l’adresse de socket en allouant un tampon de taille \fIsizeof(struct\ sockaddr_un)+1\fP mis à zéro avant la récupération. L’appel de récupération peut préciser \fIaddrlen\fP comme \fIsizeof(struct\ sockaddr_un)\fP et l’octet zéro supplémentaire assure qu’il y aura un octet NULL final dans la chaîne renvoyée dans \fIsun_path\fP : .P .in +4n .EX void *addrp; \& addrlen = sizeof(struct sockaddr_un); addrp = malloc(addrlen + 1); if (addrp == NULL) /* Handle error */ ; memset(addrp, 0, addrlen + 1); \& if (getsockname(sfd, (struct sockaddr *) addrp, &addrlen)) == \-1) /* handle error */ ; \& printf("sun_path = %s\[rs]n", ((struct sockaddr_un *) addrp)\->sun_path); .EE .in .P Cette sorte de désordre peut être évité s’il est garanti que les applications qui \fIcréent\fP les sockets de chemin suivent les règles exposées ci\-dessus dans \fISockets chemin d’accès\fP. .SH EXEMPLES Le code suivant démontre l’utilisation de sockets de paquets ordonnés pour une communication inter\-processus locale. Il est constitué de deux programmes. Le programme serveur attend une connexion d’un programme client. Le client envoie chacun de ses arguments de ligne de commande dans des messages séparés. Le serveur traite les messages entrants comme des entiers et fait leur somme. Le client envoie la chaîne de commande « END ». Le serveur renvoie un message contenant la somme des entiers du client. Le client affiche la somme et quitte. Le serveur attend la connexion d’un nouveau client. Pour stopper le serveur, le client est appelé avec l’argument de ligne de commande « DOWN ». .P La sortie suivante a été enregistrée alors que le serveur fonctionnait en arrière\-plan et en exécutant le client de façon répétée. L’exécution du programme du serveur se termine quand il reçoit la commande « DOWN ». .SS "Sortie de l’exemple" .in +4n .EX $ \fB./server &\fP [1] 25887 $ \fB./client 3 4\fP Result = 7 $ \fB./client 11 \-5\fP Result = 6 $ \fB./client DOWN\fP Result = 0 [1]+ Done ./server $ .EE .in .SS "Source du programme" .\" SRC BEGIN (connection.h) \& .EX /* * File connection.h */ #ifndef CONNECTION_H #define CONNECTION_H \& #define SOCKET_NAME "/tmp/9Lq7BNBnBycd6nxy.socket" #define BUFFER_SIZE 12 \& #endif // include guard .EE .\" SRC END .P .\" SRC BEGIN (server.c) .EX /* * File server.c */ \& #include #include #include #include #include #include #include \& #include "connection.h" \& int main(void) { int down_flag = 0; int ret; int connection_socket; int data_socket; int result; ssize_t r, w; struct sockaddr_un name; char buffer[BUFFER_SIZE]; \& /* Create local socket. */ \& connection_socket = socket(AF_UNIX, SOCK_SEQPACKET, 0); if (connection_socket == \-1) { perror("socket"); exit(EXIT_FAILURE); } \& /* * For portability clear the whole structure, since some * implementations have additional (nonstandard) fields in * the structure. */ \& memset(&name, 0, sizeof(name)); \& /* Bind socket to socket name. */ \& name.sun_family = AF_UNIX; strncpy(name.sun_path, SOCKET_NAME, sizeof(name.sun_path) \- 1); \& ret = bind(connection_socket, (const struct sockaddr *) &name, sizeof(name)); if (ret == \-1) { perror("bind"); exit(EXIT_FAILURE); } \& /* * Prepare for accepting connections. The backlog size is set * to 20. So while one request is being processed other requests * can be waiting. */ \& ret = listen(connection_socket, 20); if (ret == \-1) { perror("listen"); exit(EXIT_FAILURE); } \& /* This is the main loop for handling connections. */ \& for (;;) { \& /* Wait for incoming connection. */ \& data_socket = accept(connection_socket, NULL, NULL); if (data_socket == \-1) { perror("accept"); exit(EXIT_FAILURE); } \& result = 0; for (;;) { \& /* Wait for next data packet. */ \& r = read(data_socket, buffer, sizeof(buffer)); if (r == \-1) { perror("read"); exit(EXIT_FAILURE); } \& /* Ensure buffer is 0\-terminated. */ \& buffer[sizeof(buffer) \- 1] = 0; \& /* Handle commands. */ \& if (!strncmp(buffer, "DOWN", sizeof(buffer))) { down_flag = 1; continue; } \& if (!strncmp(buffer, "END", sizeof(buffer))) { break; } \& if (down_flag) { continue; } \& /* Add received summand. */ \& result += atoi(buffer); } \& /* Send result. */ \& sprintf(buffer, "%d", result); w = write(data_socket, buffer, sizeof(buffer)); if (w == \-1) { perror("write"); exit(EXIT_FAILURE); } \& /* Close socket. */ \& close(data_socket); \& /* Quit on DOWN command. */ \& if (down_flag) { break; } } \& close(connection_socket); \& /* Unlink the socket. */ \& unlink(SOCKET_NAME); \& exit(EXIT_SUCCESS); } .EE .\" SRC END .P .\" SRC BEGIN (client.c) .EX /* * File client.c */ \& #include #include #include #include #include #include #include \& #include "connection.h" \& int main(int argc, char *argv[]) { int ret; int data_socket; ssize_t r, w; struct sockaddr_un addr; char buffer[BUFFER_SIZE]; \& /* Create local socket. */ \& data_socket = socket(AF_UNIX, SOCK_SEQPACKET, 0); if (data_socket == \-1) { perror("socket"); exit(EXIT_FAILURE); } \& /* * For portability clear the whole structure, since some * implementations have additional (nonstandard) fields in * the structure. */ \& memset(&addr, 0, sizeof(addr)); \& /* Connect socket to socket address. */ \& addr.sun_family = AF_UNIX; strncpy(addr.sun_path, SOCKET_NAME, sizeof(addr.sun_path) \- 1); \& ret = connect(data_socket, (const struct sockaddr *) &addr, sizeof(addr)); if (ret == \-1) { fprintf(stderr, "The server is down.\[rs]n"); exit(EXIT_FAILURE); } \& /* Send arguments. */ \& for (int i = 1; i < argc; ++i) { w = write(data_socket, argv[i], strlen(argv[i]) + 1); if (w == \-1) { perror("write"); break; } } \& /* Request result. */ \& strcpy(buffer, "END"); w = write(data_socket, buffer, strlen(buffer) + 1); if (w == \-1) { perror("write"); exit(EXIT_FAILURE); } \& /* Receive result. */ \& r = read(data_socket, buffer, sizeof(buffer)); if (r == \-1) { perror("read"); exit(EXIT_FAILURE); } \& /* Ensure buffer is 0\-terminated. */ \& buffer[sizeof(buffer) \- 1] = 0; \& printf("Result = %s\[rs]n", buffer); \& /* Close socket. */ \& close(data_socket); \& exit(EXIT_SUCCESS); } .EE .\" SRC END .P For examples of the use of \fBSCM_RIGHTS\fP, see \fBcmsg\fP(3) and \fBseccomp_unotify\fP(2). .SH "VOIR AUSSI" \fBrecvmsg\fP(2), \fBsendmsg\fP(2), \fBsocket\fP(2), \fBsocketpair\fP(2), \fBcmsg\fP(3), \fBcapabilities\fP(7), \fBcredentials\fP(7), \fBsocket\fP(7), \fBudp\fP(7) .PP .SH TRADUCTION La traduction française de cette page de manuel a été créée par Christophe Blaess , Stéphan Rafin , Thierry Vignaud , François Micaux, Alain Portal , Jean-Philippe Guérard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas François , Florentin Duneau , Simon Paillard , Denis Barbier , David Prévot et Jean-Paul Guillonneau . .PP Cette traduction est une documentation libre ; veuillez vous reporter à la .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License version 3 .UE concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE. .PP Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à .MT debian-l10n-french@lists.debian.org .ME .