socket
Table des matières
Retour à l'index
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 |
POLLOUT
|
Un connect(2)
sortant
a terminé.
|
| 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
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 à
Index
- NOM
-
- SYNOPSIS
-
- DESCRIPTION
-
- Fonctions du niveau socket
-
- Structures d'adresses de socket
-
- Options de socket
-
- Signaux
-
- /proc interfaces
-
- Ioctls
-
- VERSIONS
-
- NOTES
-
- VOIR AUSSI
-
- TRADUCTION
-
This document was created by
man2html,
using the manual pages.
Time: 05:06:38 GMT, September 19, 2025