oracular (7) socket.7.gz

Provided by: manpages-fr_4.23.1-1_all bug

NOM

       socket – Interface Linux aux sockets

SYNOPSIS

       #include <sys/socket.h>

       sockfd = socket(int famille_socket, int type_socket, int protocole);

DESCRIPTION

       Cette  page de manuel documente l'interface utilisateur de l'implémentation Linux des sockets réseau. Les
       sockets compatibles BSD représentent l'interface uniforme entre le processus utilisateur et les piles  de
       protocoles réseau dans le noyau. Les modules des protocoles sont regroupés en familles de protocoles tels
       que AF_INET, AF_IPX et AF_PACKET, et en types de  sockets  comme  SOCK_STREAM  ou  SOCK_DGRAM.  Consultez
       socket(2) pour plus d'informations sur les familles et les types de sockets.

   Fonctions du niveau socket
       Ces  fonctions  servent  au  processus  utilisateur  pour  envoyer  ou recevoir des paquets et pour faire
       d'autres opérations sur les sockets. Pour plus de détails, consultez leurs pages de manuel respectives.

       socket(2) crée un socket, connect(2) connecte un socket à une adresse  de  socket  distant,  la  fonction
       bind(2)  attache  un socket à une adresse locale, listen(2) indique au socket que de nouvelles connexions
       doivent être acceptées et accept(2) est  utilisé  pour  obtenir  un  nouveau  socket  avec  une  nouvelle
       connexion  entrante.  socketpair(2)  renvoie  deux sockets anonymes connectés (seulement implémentée pour
       quelques familles locales comme AF_UNIX).

       send(2), sendto(2) et sendmsg(2)  envoient  des  données  sur  un  socket,  et  recv(2),  recvfrom(2)  et
       recvmsg(2)  reçoivent les données d’un socket. poll(2) et select(2) attendent que des données arrivent ou
       que l'émission soit possible. De plus, les opérations d'entrée-sortie standard comme write(2), writev(2),
       sendfile(2), read(2) et readv(2) peuvent être utilisées pour la lecture et l'écriture des données.

       getsockname(2)  renvoie  l'adresse du socket local et getpeername(2) renvoie l'adresse du socket distant.
       getsockopt(2) et setsockopt(2) servent à définir et à obtenir les options  de  la  couche  socket  ou  du
       protocole. ioctl(2) peut être utilisée pour lire et écrire d'autres options.

       close(2)  sert  à  fermer  un socket. shutdown(2) ferme une partie des connexions d'un duplex intégral de
       socket.

       La recherche ou l'utilisation de pread(2) ou pwrite(2) avec une position différente  de  zéro  n'est  pas
       possible sur les sockets.

       Des  opérations  d'entrée-sortie  non bloquantes sur les sockets sont possibles en définissant l'attribut
       O_NONBLOCK du descripteur de fichier du  socket  avec  fcntl(2).  Toutes  les  opérations  qui  devraient
       normalement   bloquer   se  terminent  alors  avec  l'erreur  EAGAIN  (l'opération  devra  être  retentée
       ultérieurement). connect(2) renverra l'erreur  EINPROGRESS.  L'utilisateur  peut  alors  attendre  divers
       événements avec poll(2) ou select(2).

       ┌────────────────────────────────────────────────────────────────────────────────────────────────────────┐
       │                                            Événements E/S                                              │
       ├─────────────┬───────────────────┬──────────────────────────────────────────────────────────────────────┤
       │Évènement    │ Indicateur d’état │ Occurrence                                                           │
       ├─────────────┼───────────────────┼──────────────────────────────────────────────────────────────────────┤
       │Lecture      │ POLLIN            │ Arrivée de nouvelles données.                                        │
       ├─────────────┼───────────────────┼──────────────────────────────────────────────────────────────────────┤
       │Lecture      │ POLLIN            │ Une connexion a été réalisée (pour les sockets orientés connexion)   │
       ├─────────────┼───────────────────┼──────────────────────────────────────────────────────────────────────┤
       │Lecture      │ POLLHUP           │ Une demande de déconnexion a été initiée par l'autre extrémité.      │
       ├─────────────┼───────────────────┼──────────────────────────────────────────────────────────────────────┤
       │Lecture      │ POLLHUP           │ Une  connexion  est  rompue  (seulement pour les protocoles orientés │
       │             │                   │ connexion). Lorsque le socket est écrit, SIGPIPE est aussi envoyé.   │
       ├─────────────┼───────────────────┼──────────────────────────────────────────────────────────────────────┤
       │Écriture     │ POLLOUT           │ Le socket a assez de place dans le tampon d'émission pour écrire  de │
       │             │                   │ nouvelles données.                                                   │
       ├─────────────┼───────────────────┼──────────────────────────────────────────────────────────────────────┤
       │Lect./Écrit. │ POLLIN |          │ Un connect(2) sortant a terminé.                                     │
       │             │ POLLOUT           │                                                                      │
       ├─────────────┼───────────────────┼──────────────────────────────────────────────────────────────────────┤
       │Lect./Écrit. │ POLLERR           │ Une erreur asynchrone s'est produite.                                │
       ├─────────────┼───────────────────┼──────────────────────────────────────────────────────────────────────┤
       │Lect./Écrit. │ POLLHUP           │ Le correspondant a clos un sens de communication.                    │
       ├─────────────┼───────────────────┼──────────────────────────────────────────────────────────────────────┤
       │Exception    │ POLLPRI           │ Arrivée de données urgentes. SIGURG est alors envoyé.                │
       └─────────────┴───────────────────┴──────────────────────────────────────────────────────────────────────┘
       Une  alternative à poll(2) et select(2) est de laisser le noyau informer l'application des événements par
       l'intermédiaire d'un signal SIGIO. Pour cela, l'attribut O_ASYNC doit être défini sur un  descripteur  de
       fichier du socket à l’aide de fcntl(2) et un gestionnaire de signal valable pour SIGIO doit être installé
       avec sigaction(2). Consultez les remarques sur les Signaux ci-dessous.

   Structures d'adresses de socket
       Chaque domaine de socket a son propre format pour les adresses de socket, avec  une  structure  d'adresse
       propre.  Chacune  de  ces  structures  commence  par  un  champ  d’entier  « family »  (famille), de type
       sa_family_t, qui indique le type de structure d'adresse. Cela permet aux appels système génériques à tous
       les  domaines  de  socket (par exemple connect(2), bind(2), accept(2), getsockname(2), getpeername(2)) de
       déterminer le domaine d'une adresse de socket donnée.

       Le type struct sockaddr est défini afin de pouvoir passer n'importe quel type  d'adresse  de  socket  aux
       interfaces  dans  l'API  des  sockets.  Le but de ce type est purement d'autoriser la conversion de types
       d'adresse de socket propres à un domaine vers le type « générique », afin d'éviter les avertissements  du
       compilateur au sujet de la non correspondance de type dans les appels de l'API des sockets.

       De  plus,  l'API  des  sockets  fournit le type de données struct sockaddr_storage. Ce type est fait pour
       contenir toute structure d'adresse de socket spécifique à un domaine. Il est suffisamment  grand  et  est
       aligné correctement (en particulier, il est assez grand pour contenir des adresses de socket IPv6). Cette
       structure contient le champ suivant, qui peut être utilisé pour identifier le type  d'adresse  de  socket
       effectivement stockée dans la structure :

               sa_family_t ss_family;

       La structure sockaddr_storage est utile dans les programmes qui doivent prendre en charge les adresses de
       socket de manière générique (par exemple les programmes qui doivent gérer  à  la  fois  des  adresses  de
       socket IPv4 et IPv6).

   Options de socket
       Les options de socket présentées ci-dessous peuvent être définies en utilisant setsockopt(2) et lues avec
       getsockopt(2) avec le niveau de socket positionné à  SOL_SOCKET  pour  tous  les  sockets.  Sauf  mention
       contraire, optval est un pointeur vers un int.

       SO_ACCEPTCONN
              Renvoyer  une  valeur indiquant si le socket a été déclaré comme acceptant ou non les connexions à
              l'aide de listen(2). La valeur 0 indique que le socket n'est pas à l’écoute et la valeur 1 indique
              que le socket l’est. Cette option de socket peut être seulement lue.

       SO_ATTACH_FILTER (depuis Linux 2.2)
       SO_ATTACH_BPF (depuis Linux 3.19)
              Attacher  un programme BPF classique (SO_ATTACH_FILTER) ou un programme BPF étendu (SO_ATTACH_BPF)
              au socket pour une utilisation comme filtre dans les paquets entrants. Un paquet sera abandonné si
              le  programme  de filtrage renvoie zéro. Si le programme de filtrage renvoie une valeur différente
              de zéro qui est moindre que la taille des données du paquet, celui-ci sera  tronqué  à  la  taille
              renvoyée.  Si  la valeur renvoyée par le filtre est supérieure ou égale à la taille des données du
              paquet, le paquet est autorisé à continuer non modifié.

              L’argument pour SO_ATTACH_FILTER est une structure sock_fprog, définie dans <linux/filter.h> :

                  struct sock_fprog {
                      unsigned short      len;
                      struct sock_filter *filter;
                  };

              L’argument pour SO_ATTACH_BPF est un descripteur de fichier renvoyé par l’appel système bpf(2)  et
              doit référer à un programme de type BPF_PROG_TYPE_SOCKET_FILTER.

              Ces options peuvent être définies plusieurs fois pour un socket donné, remplaçant à chaque fois le
              programme de filtre précédent. Les versions classiques et étendues peuvent être  appelées  sur  le
              même  socket,  mais  le filtre précédent sera toujours remplacé de telle façon qu’un socket n’aura
              jamais plus d’un filtre défini.

              Les versions  BPF  classique  et  étendue  sont  expliquées  dans  le  fichier  source  du  noyau,
              Documentation/networking/filter.txt

       SO_ATTACH_REUSEPORT_CBPF
       SO_ATTACH_REUSEPORT_EBPF
              Pour une utilisation avec l’option SO_REUSEPORT, ces options permettent à l’utilisateur de définir
              un programme BPF classique (SO_ATTACH_REUSEPORT_CBPF)  ou  étendu  (SO_ATTACH_REUSEPORT_EBPF)  qui
              précise  comment  les  paquets  sont  assignés aux sockets dans le groupe de réutilisation de port
              (c’est-à-dire tous les sockets qui ont SO_REUSEPORT activé et qui utilisent la même adresse locale
              pour recevoir des paquets).

              Le  programme  BPF doit renvoyer un indice entre 0 et N-1 représentant le socket qui doit recevoir
              le paquet (où N est le nombre de sockets dans le groupe). Si le programme BPF  renvoie  un  indice
              non valable, la sélection du socket reviendra au mécanisme strict SO_REUSEPORT.

              Les sockets sont numérotés dans l’ordre dont ils sont ajoutés dans le groupe (c’est-à-dire l’ordre
              des appels bind(2) pour les sockets UDP ou l’ordre des appels listen(2) pour les sockets TCP). Les
              nouveaux  sockets  ajoutés à un groupe de réutilisation de port hériteront du programme BPF. Quand
              un socket est supprimé d’un groupe de réutilisation (à l’aide de close(2)), le dernier socket sera
              déplacé dans la position du socket fermé.

              Ces  options  peuvent être définies à plusieurs reprises n’importe quand sur n’importe quel socket
              dans le groupe pour remplacer le programme BPF en cours utilisé par tous les sockets du groupe.

              SO_ATTACH_REUSEPORT_CBPF   prend   le   même   type    d’argument    que    SO_ATTACH_FILTER    et
              SO_ATTACH_REUSEPORT_EBPF prend le même argument type que SO_ATTACH_BPF.

              La  prise  en  charge d’UDP pour cette fonctionnalité est disponible depuis Linux 4.5. La prise en
              charge de TCP est disponible depuis Linux 4.6.

       SO_BINDTODEVICE
              Attacher ce socket à  un  périphérique  donné,  tel  que  « eth0 »,  comme  indiqué  dans  le  nom
              d'interface  transmis.  Si  le nom est une chaîne vide ou si la longueur de l'option est nulle, le
              socket est détaché du périphérique.  L'option  transmise  est  une  chaîne  de  longueur  variable
              terminée  par un octet NULL, contenant le nom de l'interface, la longueur maximale étant IFNAMSIZ.
              Si un socket est attaché à une interface, seuls les paquets reçus de cette interface  particulière
              sont  traités  par le socket. Cela ne fonctionne que pour certains types de socket, en particulier
              les sockets AF_INET. Cela n'est pas géré pour les sockets paquet (utilisez pour cela bind(2)).

              Avant Linux 3.8, cette option de socket  pouvait  être  configurée,  sans  pouvoir  être  lue  par
              getsockopt(2).  Depuis Linux 3.8, elle est lisible. Le paramètre optlen doit contenir la taille du
              tampon destiné à recevoir le nom du périphérique et il est recommandé d'être de IFNAMSZ octets. La
              véritable longueur du nom du périphérique est renvoyée dans le paramètre optlen.

       SO_BROADCAST
              Définir  ou  lire  l'attribut  de  diffusion.  Une  fois  activé,  les sockets de datagrammes sont
              autorisés à envoyer des paquets à une adresse de diffusion. Cette option n'a aucun effet  sur  les
              sockets orientés flux.

       SO_BSDCOMPAT
              Activer  la  compatibilité  BSD  bogue-à-bogue. Cela est utilisé par le module du protocole UDP de
              Linux 2.0 et 2.2. Si cette compatibilité est activée, les erreurs ICMP reçues pour un  socket  UDP
              ne seront pas transmises au programme utilisateur. Dans les versions récentes du noyau, la gestion
              de cette option a été abandonnée progressivement : Linux 2.4 l'ignore silencieusement et Linux 2.6
              génère  une  alerte  noyau  (printk())  si  le  programme utilise cette option. Linux 2.0 activait
              également les options de compatibilité BSD bogue-à-bogue (modification aléatoire des en-têtes, non
              prise en compte de l'attribut de diffusion) pour les sockets bruts ayant cette option, mais cela a
              été éliminé dans Linux 2.2.

       SO_DEBUG
              Activer le débogage de socket. Cela n'est autorisé  que  pour  les  processus  ayant  la  capacité
              CAP_NET_ADMIN ou un identifiant d'utilisateur effectif égal à 0.

       SO_DETACH_FILTER (depuis Linux 2.2)
       SO_DETACH_BPF (depuis Linux 3.19)
              Ces  deux  options,  qui  sont  synonymes,  peuvent  être  utilisées pour retirer le programme BPF
              classique ou étendu attaché à un socket avec soit SO_ATTACH_FILTER soit SO_ATTACH_BPF.  La  valeur
              d’option est ignorée.

       SO_DOMAIN (depuis Linux 2.6.32)
              Récupérer  le  domaine  de socket sous forme d’entier, en renvoyant une valeur telle que AF_INET6.
              Consultez socket(2) pour plus de détails. Cette option de socket peut être seulement lue.

       SO_ERROR
              Lire et effacer l'erreur en cours sur le socket. Cette option de socket peut être  seulement  lue.
              Un entier est attendu.

       SO_DONTROUTE
              Ne pas émettre par l'intermédiaire d'une passerelle, n'envoyer qu'aux hôtes directement connectés.
              Le même effet peut être obtenu avec l'attribut MSG_DONTROUTE durant une opération send(2)  sur  le
              socket. Un attribut entier booléen est attendu.

       SO_INCOMING_CPU (récupérable depuis Linux 3.19, modifiable depuis Linux 4.4)
              Définir ou obtenir l’affinité CPU d’un socket. Un attribut entier est attendu.

                  int cpu = 1;
                  setsockopt(fd, SOL_SOCKET, SO_INCOMING_CPU, &cpu,
                             sizeof(cpu));

              Parce  que  tous les paquets d’un flux unique (c’est-à-dire tous les paquets pour le même 4-tuple)
              arrivent sur une file d’attente RX unique qui  est  associée  avec  un  CPU  particulier,  le  cas
              d’utilisation  classique  est  d’employer  un processus d’écoute par file RX, avec le flux entrant
              géré par un écouteur sur le même CPU gérant la file RX. Cela fournit un comportement NUMA  optimal
              et conserve les caches de CPU prêts.

       SO_INCOMING_NAPI_ID (récupérable depuis Linux 4.12)
              Renvoyer  un  ID  unique  au  niveau système, appelé ID NAPI qui est associé avec une file RX dans
              laquelle le dernier paquet associé à ce socket est reçu.

              Cela peut être utilisé par une  application  qui  sépare  les  flux  entrants  entre  les  threads
              d’exécution  (worker)  en se basant sur la file RX sur laquelle les paquets associés avec les flux
              sont reçus. Cela permet à chaque thread d’exécution d’être associé à une file de réception  HW  de
              NIC  et  de  servir toutes les requêtes de connexion reçues sur cette file RX. Ce mappage entre un
              thread d’application et  une  file  HW  de  NIC  rationalise  le  flux  de  données  du  NIC  vers
              l’application.

       SO_KEEPALIVE
              Activer  l'émission  de  messages  périodiques  gardant le socket ouvert pour les sockets orientés
              connexion. Un attribut entier booléen est attendu.

       SO_LINGER
              Définir ou lire l'option SO_LINGER. L’argument est une structure linger.

                  struct linger {
                      int l_onoff;    /* attente activée */
                      int l_linger;   /* durée d'attente en secondes */
                  };

              Lorsque ce paramètre est actif, un appel à close(2) ou shutdown(2) ne se terminera pas  avant  que
              tous  les messages en attente pour le socket aient été correctement émis ou que le délai d'attente
              soit  écoulé.  Sinon,  l'appel  se  termine  immédiatement  et  la  fermeture  est  effectuée   en
              arrière-plan.  Lorsque  le  socket  est  fermé  au  cours  d'un  exit(2),  il  attend  toujours en
              arrière-plan.

       SO_LOCK_FILTER
              Lorsqu'elle est établie cette option empêchera la modification des filtres associés au socket. Ces
              filtres  incluent  tous les ensembles issus des options de socket SO_ATTACH_FILTER, SO_ATTACH_BPF,
              SO_ATTACH_REUSEPORT_CBPF et SO_ATTACH_REUSEPORT_EBPF.

              Le cas d’utilisation typique est celui d’un processus privilégié pour définir un socket brut  (une
              opération  nécessitant  la  capacité CAP_NET_RAW), appliquer un filtre restrictif, régler l’option
              SO_LOCK_FILTER et alors soit abandonner ses privilèges soit passer le descripteur  de  fichier  du
              socket à un processus non privilégié à l’aide d’un socket de domaine UNIX.

              Une  fois que l’option SO_LOCK_FILTER a été activée, essayer de modifier ou de supprimer le filtre
              attaché à un socket, ou désactiver l’option SO_LOCK_FILTER échouera avec l’erreur EPERM.

       SO_MARK (depuis Linux 2.6.25)
              Positionner la marque pour chaque paquet envoyé au travers de ce socket (similaire à la cible MARK
              de  netfilter,  mais  pour les sockets). Le changement de marque peut être utilisé pour un routage
              par marques sans netfilter ou pour le filtrage de paquets.  Utiliser  cette  option  nécessite  la
              capacité CAP_NET_ADMIN ou CAP_NET_RAW (depuis Linux 5.17).

       SO_OOBINLINE
              Si  cette  option  est  activée,  les données hors bande sont placées directement dans le flux des
              données reçues. Sinon, elles ne sont transmises que si l'attribut MSG_OOB  est  défini  durant  la
              réception.

       SO_PASSCRED
              Autoriser  ou  interdire  la  réception  des  messages  de  contrôle SCM_CREDENTIALS. Pour plus de
              détails, consultez unix(7).

       SO_PASSSEC
              Autoriser ou interdire la réception des messages de contrôle SCM_SECURITY. Pour plus  de  détails,
              consultez unix(7).

       SO_PEEK_OFF (depuis Linux 3.4)
              Cette  option, qui n'est à ce jour prise en charge que pour les sockets unix(7), définit la valeur
              de la première « position de lecture » (« peek offset ») pour l'appel  système  recv(2)  lorsqu'il
              est invoqué avec l'attribut MSG_PEEK.

              Lorsque  cette  option  reçoit  une  valeur  négative (elle est initialisée à -1 pour tout nouveau
              socket), elle se comporte classiquement : recv(2), avec l'attribut MSG_PEEK, lit  les  données  au
              début de la file.

              Lorsque  l'option  reçoit  une  valeur  supérieure  ou égale à zéro, alors la lecture suivante des
              données en file d’attente dans le socket est réalisée à la position  précisée  par  la  valeur  de
              l'option.  Dans  le  même temps, la « position de lecture » est incrémentée du nombre d'octets lus
              dans la file, de façon à ce que la prochaine lecture renvoie la donnée suivante dans la file.

              Si des données sont retirées de la tête de la file par la fonction recv(2)  (ou  équivalent)  sans
              l'attribut  MSG_PEEK,  alors la « position de lecture » est diminuée du nombre d'octets supprimés.
              Autrement dit, l'acquisition de données sans avoir recours à l'attribut MSG_PEEK a pour  effet  de
              modifier  la  « position  de  lecture », de sorte que la prochaine lecture renvoie les données qui
              auraient été renvoyées si aucune donnée n'avait été supprimée.

              Pour les sockets de datagrammes, si la « position de lecture » pointe à l'intérieur  d'un  paquet,
              alors les données renvoyées seront marquées avec l'attribut MSG_TRUNC.

              L'exemple  suivant  illustre  l'usage  de  SO_PEEK_OFF.  Imaginons un socket de flux contenant les
              données suivantes dans sa file :

                  aabbccddeeff

              La séquence suivante d'appels à recv(2) aura l'effet décrit dans les commentaires :

                  int ov = 4;                  // réglage à 4 de la position de lecture
                  setsockopt(fd, SOL_SOCKET, SO_PEEK_OFF, &ov, sizeof(ov));

                  recv(fd, buf, 2, MSG_PEEK);  // Lit "cc"; position réglée à 6
                  recv(fd, buf, 2, MSG_PEEK);  // Lit "dd"; position réglée à 8
                  recv(fd, buf, 2, 0);         // Lit "aa"; position réglée à 6
                  recv(fd, buf, 2, MSG_PEEK);  // Lit "ee"; position réglée à 8

       SO_PEERCRED
              Renvoyer les accréditations du processus  pair  connecté  à  ce  socket.  Pour  plus  de  détails,
              consultez unix(7).

       SO_PEERSEC (depuis Linux 2.6.2)
              Renvoyer  le  contexte  de  sécurité  du  socket  pair connecté à ce socket. Pour plus de détails,
              consultez unix(7) et ip(7).

       SO_PRIORITY
              Définir la priorité définie par le protocole pour tous les paquets envoyés sur  ce  socket.  Linux
              utilise  cette  valeur  pour trier les files réseau : les paquets avec une priorité élevée peuvent
              être traités d'abord, en fonction de la gestion des files sur le périphérique sélectionné. Établir
              une priorité en dehors de l'intervalle allant de 0 à 6 nécessite la capacité CAP_NET_ADMIN.

       SO_PROTOCOL (depuis Linux 2.6.32)
              Récupérer  le  protocole  de  socket  sous  forme  d’entier,  en  renvoyant  une  valeur telle que
              IPPROTO_SCTP. Consultez socket(2) pour plus de détails. Cette option de socket peut être seulement
              lue et pas modifiée.

       SO_RCVBUF
              Définir  ou lire la taille maximale en octets du tampon de réception. Le noyau double cette valeur
              (pour prévoir de l'espace pour les opérations de service)  lorsque  la  valeur  est  définie  avec
              setsockopt(2)  et  cette  valeur doublée est retournée par getsockopt(2). La valeur par défaut est
              définie par le fichier /proc/sys/net/core/rmem_default et la valeur maximale autorisée est définie
              par  le  fichier  /proc/sys/net/core/rmem_max.  La valeur (doublée) minimale pour cette option est
              256.

       SO_RCVBUFFORCE (depuis Linux 2.6.14)
              En utilisant cette option de socket, un processus privilégié (CAP_NET_ADMIN) peut exécuter la même
              tâche que SO_RCVBUF, mais la limite rmem_max peut être remplacée.

       SO_RCVLOWAT et SO_SNDLOWAT
              Indiquer  le nombre minimal d'octets dans le tampon pour que la couche socket passe les données au
              protocole (SO_SNDLOWAT) ou à l'utilisateur en  réception  (SO_RCVLOWAT).  Ces  deux  valeurs  sont
              initialisées  à 1.  SO_SNDLOWAT n'est pas modifiable sur Linux (setsockopt(2) échoue avec l'erreur
              ENOPROTOOPT). SO_RCVLOWAT est modifiable seulement depuis Linux 2.4.

              Avant Linux 2.6.28, select(2), poll(2) et epoll(7) ne respectaient pas le réglage SO_RCVLOWAT  sur
              Linux et indiquaient un socket comme lisible même si un seul octet était disponible. Une prochaine
              lecture du socket bloquerait alors jusqu’à ce que SO_RCVLOWAT octets  soient  disponibles.  Depuis
              Linux 2.6.28,  select(2),  poll(2) et epoll(7) indiquent qu’un socket est lisible uniquement si au
              moins SO_RCVLOWAT octets sont disponibles.

       SO_RCVTIMEO et SO_SNDTIMEO
              Indiquer le délai maximal d'émission ou de réception avant de signaler une  erreur.  Le  paramètre
              est  une structure timeval. Si une fonction d'entrée ou de sortie bloque pendant cet intervalle de
              temps et que des données ont été envoyées ou reçues, la valeur de retour de cette fonction sera la
              quantité  de  données  transmises. Si aucune donnée n'a été transmise et si le délai d'attente est
              atteint, -1 est renvoyé et errno est positionné à EAGAIN  ou  EWOULDBLOCK,  ou  EINPROGRESS  (pour
              connect(2)),  comme  si  le  socket avait été défini comme non bloquant. Si le délai d'attente est
              défini à zéro (valeur par défaut), l'opération  ne  sera  jamais  interrompue.  Les  délais  n'ont
              d'effet  que  pour  les  appels  système  faisant  des E/S sur des sockets (par exemple accept(2),
              connect(2), read(2), recvmsg(2), send(2), sendmsg(2)) ; ils  n'ont  pas  d'effet  pour  select(2),
              poll(2), epoll_wait(2), etc.

       SO_REUSEADDR
              Indiquer que les règles utilisées pour la validation des adresses fournies dans un appel à bind(2)
              doivent autoriser la réutilisation des adresses locales. Pour les sockets AF_INET,  cela  signifie
              que le socket peut être attaché à n'importe quelle adresse sauf lorsqu'un socket actif en écoute y
              est liée. Lorsque le socket en écoute est attaché à INADDR_ANY avec un port spécifique,  il  n'est
              pas  possible de s'attacher à ce port quelle que soit l'adresse locale. L'argument est un attribut
              booléen entier.

       SO_REUSEPORT (depuis Linux 3.9)
              Autoriser plusieurs sockets AF_INET ou AF_INET6 à être liés à une  adresse  identique  de  socket.
              Cette  option  doit  être déclarée sur chaque socket (y compris le premier socket) avant d’appeler
              bind(2) sur le socket. Pour prévenir le détournement de port, tous les processus reliés à la  même
              adresse  doivent  avoir le même UID effectif. Cette option peut être employée avec les sockets TCP
              et UDP.

              Pour les sockets TCP, cette option autorise la répartition des charges accept(2) dans  un  serveur
              multithread  pour être renforcée en utilisant un socket d’écoute pour chaque thread. Cela améliore
              la répartition des charges par rapport aux techniques traditionnelles telles qu’un  unique  thread
              accept(2)ant  qui  répartit  les  connexions  ou  d’avoir  plusieurs  threads  qui rivalisent pour
              accept(2) à partir du même socket.

              Pour les sockets UDP, l’utilisation de cette option peut procurer une  meilleure  répartition  des
              datagrammes   entrants   vers   plusieurs  processus  (ou  threads)  par  rapport  aux  techniques
              traditionnelles d’avoir plusieurs processus rivalisant pour recevoir des datagrammes sur  le  même
              socket.

       SO_RXQ_OVFL (depuis Linux 2.6.33)
              Indiquer  qu'un  message  auxiliaire  (cmsg)  sous  la  forme d'une valeur non signée et codée sur
              32 bits doit être joint aux tampons de socket  (skb  — socket  buffer),  indiquant  le  nombre  de
              paquets perdus par le socket depuis sa création.

       SO_SELECT_ERR_QUEUE (depuis Linux 3.10)
              Quand  cette  option  est activée sur un socket, une condition d’erreur sur un socket entraîne une
              notification pas seulement à l’aide de l’ensemble  exceptfds  de  select(2).  De  la  même  façon,
              poll(2) renvoie aussi POLLPRI a chaque fois qu’un évènement POLLERR est renvoyé.

              Contexte :  cette  option  a  été  ajoutée  depuis  que  le  réveil  sur une condition d’erreur se
              produisait seulement au travers des ensembles readfds et writefds de select(2). Cette option a été
              ajoutée  pour  permettre  la  supervision des conditions d’erreur à l’aide de l’argument exceptfds
              sans avoir simultanément à recevoir des notifications (à  l’aide  de  readfds)  pour  des  données
              régulières  pouvant  être  lues  à  partir  du  socket.  Après  les  changements  dans Linux 4.16,
              l’utilisation de cet indicateur n’est plus nécessaire. Cette option est néanmoins  conservée  pour
              la rétrocompatibilité.

       SO_SNDBUF
              Définir  ou  lire  la taille maximale en octets du tampon d'émission. Le noyau double cette valeur
              (pour prévoir de l'espace pour les opérations de service)  lorsque  la  valeur  est  définie  avec
              setsockopt(2),  et  cette valeur doublée est retournée par getsockopt(2). La valeur par défaut est
              définie par le fichier /proc/sys/net/core/wmem_default et la valeur maximale autorisée est définie
              par  le  fichier  /proc/sys/net/core/wmem_max.  La  valeur  (doublée)  minimale  pour cette option
              est 2048.

       SO_SNDBUFFORCE (depuis Linux 2.6.14)
              En utilisant cette option de socket, un processus privilégié (CAP_NET_ADMIN) peut exécuter la même
              tâche que SO_SNDBUF, mais la limite wmem_max peut être remplacée.

       SO_TIMESTAMP
              Activer  ou  désactiver la réception des messages de contrôle SO_TIMESTAMP. Le message de contrôle
              d'horodatage est envoyé avec le niveau SOL_SOCKET et  un  cmsg_type  de  SCM_TIMESTAMP.  Le  champ
              cmsg_data  est  une  structure  timeval  indiquant la date de réception du dernier paquet fourni à
              l'utilisateur dans cet appel. Consultez cmsg(3) pour plus de détails sur les messages de contrôle.

       SO_TIMESTAMPNS (depuis Linux 2.6.22)
              Activer ou désactiver la réception des messages de contrôle SO_TIMESTAMPNS. Le message de contrôle
              d'horodatage  est  envoyé  avec  le niveau SOL_SOCKET et un cmsg_type de SCM_TIMESTAMPNS. Le champ
              cmsg_data est une structure timespec indiquant la date de réception du  dernier  paquet  fourni  à
              l'utilisateur  dans  cet appel. L’horloge utilisée pour l’horodatage est CLOCK_REALTIME. Consultez
              cmsg(3) pour plus de détails sur les messages de contrôle.

              Un socket ne peut pas mélanger SO_TIMESTAMP et SO_TIMESTAMPNS, les deux  modes  sont  mutuellement
              exclusifs.

       SO_TYPE
              Lire  le  type  de  socket, sous forme d'entier (par exemple, SOCK_STREAM). Cette option de socket
              peut être seulement lue, et pas modifiée.

       SO_BUSY_POLL (depuis Linux 3.11)
              Définir la durée approximative, en  milliseconde,  d’attente  active  de  réception  bloquante  en
              absence de données. CAP_NET_ADMIN est nécessaire pour augmenter cette valeur. La valeur par défaut
              pour cette option est contrôlée par le fichier /proc/sys/net/core/busy_read.

              La valeur dans  le  fichier  /proc/sys/net/core/busy_poll  détermine  la  durée  pendant  laquelle
              select(2)  et  poll(2)  seront  en  attente  active  lors  d’une  opération  sur  des sockets avec
              SO_BUSY_POLL défini et qu’aucun événement à signaler n’est trouvé.

              Dans les deux cas, l’attente active ne sera réalisée que lorsque les dernières données reçues  par
              le socket proviennent d’un périphérique réseau qui prend en charge cette option.

              Bien  que  l’attente  active  peut  améliorer  la  latence de quelques applications, une attention
              particulière doit être portée à son utilisation puisque cela augmentera à la fois l’utilisation du
              processeur et la consommation de puissance.

   Signaux
       Lors  de  l'écriture sur un socket orienté connexion qui a été fermé (localement ou à l'autre extrémité),
       le signal SIGPIPE est envoyé au processus qui écrivait et EPIPE est renvoyé. Le signal n'est  pas  envoyé
       lorsque l'appel d'écriture indiqué contenait l'attribut MSG_NOSIGNAL.

       Lorsque  demandé  avec  l'option FIOSETOWN de fcntl(2) ou l'option SIOCSPGRP de ioctl(2), le signal SIGIO
       est envoyé quand un événement d'entrée-sortie a lieu. Il est possible  d'utiliser  poll(2)  ou  select(2)
       dans  le  gestionnaire  de  signal pour savoir sur quel socket l'événement s'est produit. Une alternative
       (sous Linux 2.2) est de définir un signal en temps réel avec le fnctl(2)  F_SETSIG.  Le  gestionnaire  du
       signal  en  temps  réel  sera appelé avec le descripteur de fichier dans le champ si_fd de son siginfo_t.
       Consultez fcntl(2) pour plus d'informations.

       Dans certains cas (par exemple, différents  processus  accédant  au  même  socket),  la  condition  ayant
       déclenché  le  signal  SIGIO  peut  avoir  déjà  disparu  quand le processus réagit au signal. Si cela se
       produit, le processus devrait attendre à nouveau, car Linux renverra ce signal ultérieurement.

   /proc interfaces
       Les paramètres réseau de base des sockets sont  accessibles  en  utilisant  les  fichiers  du  répertoire
       /proc/sys/net/core/.

       rmem_default
              contient la taille en octets par défaut du tampon de réception du socket.

       rmem_max
              contient  la  taille maximale en octets du tampon de réception qu'un utilisateur peut définir avec
              l'option SO_RCVBUF du socket.

       wmem_default
              contient la taille en octets par défaut du tampon d'émission du socket.

       wmem_max
              contient la taille maximale en octets du tampon d'émission qu'un  utilisateur  peut  définir  avec
              l'option SO_SNDBUF du socket.

       message_cost et message_burst
              configurent  le  filtrage  par  seau  à  jetons  (token bucket) utilisé pour limiter la charge des
              messages d'avertissement dus aux événements réseau extérieurs.

       netdev_max_backlog
              contient le nombre maximal de paquets dans la file d'entrée globale.

       optmem_max
              contient la taille maximale par  socket  des  données  auxiliaires  et  des  données  de  contrôle
              utilisateur comme les « iovec ».

   Ioctls
       Ces opérations sont accessibles en utilisant ioctl(2) :

           error = ioctl(ip_socket, type_ioctl, &valeur_résultat);

       SIOCGSTAMP
              Renvoyer  une  structure  timeval  avec  la  date  de  réception  du  dernier  paquet  transmis  à
              l'utilisateur. Cela est utile pour  des  mesures  précises  du  temps  de  cheminement.  Consultez
              setitimer(2) pour une description de la structure timeval. L'ioctl ne doit être utilisé que si les
              options SO_TIMESTAMP et SO_TIMESTAMPNS du socket ne sont pas définies. Sinon, la date  du  dernier
              paquet  reçu quand SO_TIMESTAMP et SO_TIMESTAMPNS n'étaient pas définies est renvoyée, ou un échec
              est constaté si de tels paquets ne sont pas reçus (c'est-à-dire que ioctl(2) renvoie  -1  avec  un
              errno défini à ENOENT).

       SIOCSPGRP
              Définir  le  processus  ou le groupe de processus qui doivent recevoir les signaux SIGIO ou SIGURG
              quand les E/S deviennent possibles ou que des données urgentes sont disponibles. L’argument est un
              pointeur vers un pid_t. Pour d’autres détails, consultez la description de F_SETOWN dans fcntl(2).

       FIOASYNC
              Changer  l'attribut  O_ASYNC  pour  activer  ou  désactiver  le mode d'entrée-sortie asynchrone du
              socket. Un mode d'entrée-sortie asynchrone signifie que le signal SIGIO ou le signal  défini  avec
              F_SETSIG est envoyé quand un événement d'entrée-sortie se produit.

              Le  paramètre  est  un  entier booléen. (Cette opération est synonyme de l'utilisation de fcntl(2)
              pour définir l'attribut O_ASYNC).

       SIOCGPGRP
              Lire le processus ou le groupe de processus en cours auquel  les  signaux  SIGIO  ou  SIGURG  sont
              envoyés. Zéro est obtenu quand aucun n'est défini.

       Opérations fcntl(2) valables :

       FIOGETOWN
              Identique à l'ioctl(2) SIOCGPGRP.

       FIOSETOWN
              Identique à l'ioctl(2) SIOCSPGRP.

VERSIONS

       SO_BINDTODEVICE  a  été  introduit  dans  Linux 2.0.30.  SO_PASSCRED  est une nouveauté de Linux 2.2. Les
       interfaces /proc ont été introduites  dans  Linux 2.2.  SO_RCVTIMEO  et  SO_SNDTIMEO  sont  gérés  depuis
       Linux 2.3.41. Auparavant, les délais d'attente étaient définis selon un réglage spécifique aux protocoles
       et ne pouvaient être ni lus ni modifiés.

NOTES

       Linux suppose que la moitié du tampon d'émission/réception est utilisé pour les  structures  internes  du
       noyau.  Ainsi  les  valeurs dans les fichiers /proc correspondants sont deux fois plus grandes que ce que
       l'on peut observer directement sur le câble.

       Linux ne permettra la réutilisation des ports qu'avec l'option SO_REUSEADDR lorsque celle-ci sera définie
       à  la  fois par le précédent programme qui a effectué un bind(2) sur le port et par le programme qui veut
       réutiliser ce port. Cela diffère de certaines implémentations (par  exemple,  sur  FreeBSD)  où  seul  le
       dernier  programme  doit  définir  l'option SO_REUSEADDR. Habituellement, cette différence est invisible,
       puisque, par exemple, un programme serveur est conçu pour toujours définir cette option.

VOIR AUSSI

       wireshark(1), bpf(2), connect(2), getsockopt(2), setsockopt(2), socket(2), pcap(3),  address_families(7),
       capabilities(7), ddp(7), ip(7), ipv6(7), packet(7), tcp(7), udp(7), unix(7), tcpdump(8)

TRADUCTION

       La   traduction   française   de   cette   page   de   manuel   a   été   créée   par  Christophe  Blaess
       <https://www.blaess.fr/christophe/>,   Stéphan   Rafin   <stephan.rafin@laposte.net>,   Thierry   Vignaud
       <tvignaud@mandriva.com>,  François  Micaux,  Alain Portal <aportal@univ-montp2.fr>, Jean-Philippe Guérard
       <fevrier@tigreraye.org>,   Jean-Luc   Coulon   (f5ibh)   <jean-luc.coulon@wanadoo.fr>,   Julien   Cristau
       <jcristau@debian.org>,      Thomas      Huriaux      <thomas.huriaux@gmail.com>,     Nicolas     François
       <nicolas.francois@centraliens.net>,    Florentin    Duneau    <fduneau@gmail.com>,     Simon     Paillard
       <simon.paillard@resel.enst-bretagne.fr>,     Denis    Barbier    <barbier@debian.org>,    David    Prévot
       <david@tilapin.org>,    Cédric    Boutillier     <cedric.boutillier@gmail.com>,     Frédéric     Hantrais
       <fhantrais@gmail.com> et Jean-Paul Guillonneau <guillonneau.jeanpaul@free.fr>

       Cette  traduction  est  une  documentation libre ; veuillez vous reporter à la GNU General Public License
       version 3  ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩  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 à
       ⟨debian-l10n-french@lists.debian.org⟩.