socket – Interface Linux aux sockets
#include <sys/socket.h>
sockfd = socket(int famille_socket, int type_socket, int protocole);
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.
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 | 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.
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).
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.
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.
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 ».
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.
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.
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.
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)
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 à
debian-l10n-french@lists.debian.org.