Provided by: manpages-fr_4.18.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
       These functions are used by the user process to send or receive packets and  to  do  other
       socket operations. For more information, see their respective manual pages.

       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
              Bind this socket to a particular device like “eth0”, as  specified  in  the  passed
              interface  name.  If  the name is an empty string or the option length is zero, the
              socket  device  binding  is  removed.  The  passed  option  is  a   variable-length
              null-terminated  interface  name  string  with  the  maximum size of IFNAMSIZ. If a
              socket is bound to  an  interface,  only  packets  received  from  that  particular
              interface  are  processed  by the socket. Note that this works only for some socket
              types, particularly AF_INET sockets. It is not supported for  packet  sockets  (use
              normal bind(2) there).

              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.

       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
              Enable  or  disable  the receiving of the SCM_CREDENTIALS control message. For more
              information, see unix(7).

       SO_PASSSEC
              Enable or disable the receiving of  the  SCM_SECURITY  control  message.  For  more
              information, see 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
              Specify the receiving or sending timeouts until reporting an error. The argument is
              a  struct  timeval.  If an input or output function blocks for this period of time,
              and data has been sent or received, the return value of that function will  be  the
              amount  of  data  transferred;  if no data has been transferred and the timeout has
              been reached, then -1 is returned with errno  set  to  EAGAIN  or  EWOULDBLOCK,  or
              EINPROGRESS   (for  connect(2))   just  as  if  the  socket  was  specified  to  be
              nonblocking. If the timeout is set to zero (the default), then the  operation  will
              never  timeout.  Timeouts only have effect for system calls that perform socket I/O
              (e.g., accept(2), connect(2), read(2), recvmsg(2), send(2),  sendmsg(2));  timeouts
              have no effect for select(2), poll(2), epoll_wait(2), and so on.

       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.

   Interfaces /proc
       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⟩.