#include <sys/socket.h> int socket(int domain, int type, int protocol);
Le paramètre domain indique le domaine de communication ; cela sélectionne la famille de protocole à employer. Elles sont définies dans le fichier <sys/socket.h>. Les formats actuellement compris par le noyau Linux sont :
| Nom | Objectif | Page de manuel |
| AF_UNIX | Communication locale |
unix(7)
|
| AF_LOCAL | Synonyme de AF_UNIX |
|
| AF_INET | Protocoles Internet IPv4 |
ip(7)
|
| AF_AX25 | Protocole radio amateur AX.25 |
ax25(4)
|
| AF_IPX | IPX - Protocoles Novell | |
| AF_APPLETALK | AppleTalk |
ddp(7)
|
| AF_X25 | Protocole ITU-T X.25 / ISO-8208 |
x25(7)
|
| AF_INET6 | Protocoles Internet IPv6 |
ipv6(7)
|
| AF_DECnet | Sockets de protocole DECet | |
| AF_KEY | Protocole de gestion de clé, développé à l'origine pour être utilisé avec IPsec | |
| AF_NETLINK | Interface utilisateur noyau |
netlink(7)
|
| AF_PACKET | Interface paquet bas-niveau |
packet(7)
|
| AF_RDS | Protocole Reliable Datagram Sockets (RDS) |
rds(7)
rds-rdma(7) |
| AF_PPPOX | Couche de transport PPP générique pour paramétrer des tunnels L2 (L2TP et PPPoE) | |
| AF_LLC | Protocole de contrôle de lien logique (IEEE 802.2 LLC) | |
| AF_IB | Adressage natif InfiniBand | |
| AF_MPLS | Multiprotocole Label Switching | |
| AF_CAN | Protocole du bus Controller Area Network automotive | |
| AF_TIPC | Protocole TIPC, « sockets de domaine de grappe » | |
| AF_BLUETOOTH | Protocole du socket de bas niveau Bluetooth | |
| AF_ALG | Interface avec l'API de chiffrement du noyau | |
| AF_VSOCK | Protocole VSOCK (initialement « VMWare VSockets ») de communication hyperviseur-invité |
vsock(7)
|
| AF_KCM | Interface KCM (multiplexeur de connexion au noyau) | |
| AF_XDP | Interface XDP (express data path) |
Vous pouvez trouver plus de détails sur les familles d'adresses ci-dessus, ainsi que des informations sur plusieurs autres familles d'adresses, dans address_families(7).
Le socket a le type indiqué, ce qui indique la sémantique des communications. Les types définis actuellement sont :
Certains types de sockets peuvent ne pas être implémentés par toutes les familles de protocoles.
Depuis Linux 2.6.27, le paramètre type a un autre objectif : en plus d'indiquer le type de socket, il peut inclure les valeurs suivantes en les combinant par un OU binaire, pour modifier le comportement de socket() :
Le protocole à utiliser sur le socket est indiqué par l'argument protocol. Normalement, il n'y a qu'un seul protocole par type de socket pour une famille donnée, auquel cas l'argument protocol peut être nul. Néanmoins, rien ne s'oppose à ce que plusieurs protocoles existent, auquel cas il est nécessaire de le spécifier. Le numéro de protocole dépend du domaine de communication du socket ; consultez protocols(5). Consultez getprotoent(3) pour savoir comment associer un nom de protocole à un numéro.
Des sockets de type SOCK_STREAM sont des flux d'octets full-duplex. Ils ne préservent pas les limites d'enregistrements. Un socket SOCK_STREAM doit être dans un état connecté avant que des données puissent y être lues ou écrites. Une connexion sur un autre socket est établie par l'appel système connect(2). Une fois connecté, les données y sont transmises par read(2) et write(2) ou par des variantes de send(2) et recv(2). Quand une session se termine, on referme le socket avec close(2). Les données hors-bande sont envoyées ou reçues comme il est décrit dans send(2) et recv(2).
Les protocoles de communication qui implémentent les sockets SOCK_STREAM garantissent qu'aucune donnée n'est perdue ou dupliquée. Si un bloc de données, pour lequel le correspondant a suffisamment de place dans son tampon, n'est pas transmis correctement dans un délai raisonnable, la connexion est considérée comme inutilisable. Si l'option SO_KEEPALIVE est activée sur le socket, le protocole vérifie, d'une manière qui lui est spécifique, si le correspondant est toujours actif. Un signal SIGPIPE est envoyé au processus tentant d'écrire sur un socket inutilisable, forçant les programmes ne gérant pas ce signal à se terminer. Les sockets de type SOCK_SEQPACKET emploient les mêmes appels système que ceux de types SOCK_STREAM, à la différence que la fonction read(2) ne renverra que le nombre d'octets requis, et toute autre donnée restante dans le paquet sera éliminée. De plus, les frontières des messages seront préservées.
Les sockets de type SOCK_DGRAM ou SOCK_RAW permettent l'envoi de datagrammes aux correspondants indiqués dans l'appel système sendto(2). Les datagrammes sont généralement lus par la fonction recvfrom(2), qui fournit également l'adresse du correspondant.
Les sockets SOCK_PACKET sont obsolètes. Ils servent à recevoir les paquets bruts directement depuis le gestionnaire de périphérique. Utilisez plutôt packet(7).
Un appel à fcntl(2) avec l'argument F_SETOWN permet de préciser un processus ou un groupe de processus qui recevront un signal SIGURG lors de l'arrivée de données hors-bande, ou le signal SIGPIPE lorsqu'une connexion sur un socket SOCK_STREAM se termine inopinément. Cette fonction permet également de définir le processus ou groupe de processus qui recevront une notification asynchrone des événements d'entrées-sorties par le signal SIGIO. L'utilisation de F_SETOWN est équivalent à un appel ioctl(2) avec l'argument FIOSETOWN ou SIOCSPGRP.
Lorsque le réseau indique une condition d'erreur au module du protocole (par exemple avec un message ICMP pour IP), un drapeau signale une erreur en attente sur le socket. L'opération suivante sur ce socket renverra ce code d'erreur. Pour certains protocoles, il est possible d'activer une file d'attente d'erreurs par socket. Pour plus de détails, consultez IP_RECVERR dans ip(7).
Les opérations sur les sockets sont contrôlées par des options du niveau socket. Ces options sont définies dans <sys/socket.h>. Les fonctions setsockopt(2) et getsockopt(2) sont utilisées respectivement pour définir ou lire les options.
D'autres erreurs peuvent être dues aux modules de protocoles sous-jacents.
Les attributs SOCK_NONBLOCK et SOCK_CLOEXEC sont spécifiques à Linux.
La fonction socket() est apparue dans BSD 4.2. Elle est généralement portable de/vers les systèmes non-BSD supportant des clones des sockets BSD (y compris les variantes de System V).
« An Introductory 4.3BSD Interprocess Communication Tutorial » et « BSB Interprocess Communication Tutorial », réimprimés dans UNIX Programmer's Supplementary Documents Volume 1.
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à