Provided by: manpages-fr_4.23.1-1_all 
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⟩.