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
<
[email protected]>, Thierry Vignaud
<
[email protected]>, François Micaux, Alain Portal
<
[email protected]>, Jean-Philippe Guérard
<
[email protected]>, Jean-Luc Coulon (f5ibh)
<
[email protected]>, Julien Cristau
<
[email protected]>, Thomas Huriaux <
[email protected]>,
Nicolas François <
[email protected]>, Florentin
Duneau <
[email protected]>, Simon Paillard
<
[email protected]>, Denis Barbier
<
[email protected]>, David Prévot <
[email protected]>,
Cédric Boutillier <
[email protected]>,
Frédéric Hantrais <
[email protected]> et Jean-Paul
Guillonneau <
[email protected]>
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 à
[email protected]