accept(2) System Calls Manual accept(2)
NOM
accept, accept4 - Accepter une connexion sur une socket
BIBLIOTHÈQUE
Bibliothèque C standard (libc, -lc)
SYNOPSIS
#include <sys/socket.h>
int accept(int sockfd, struct sockaddr *_Nullable restrict addr,
socklen_t *_Nullable restrict addrlen);
#define _GNU_SOURCE /* Consultez feature_test_macros(7) */
#include <sys/socket.h>
int accept4(int sockfd, struct sockaddr *_Nullable restrict addr,
socklen_t *_Nullable restrict addrlen, int flags);
DESCRIPTION
L'appel système accept() est employé avec les sockets utilisant un pro-
tocole en mode connecté (SOCK_STREAM, SOCK_SEQPACKET). Il extrait la
première connexion de la file des connexions en attente de la socket
sockfd à l'écoute, crée une nouvelle socket et alloue pour cette socket
un nouveau descripteur de fichier qu'il renvoie. La nouvelle socket
n'est pas en état d'écoute. La socket originale sockfd n'est pas modi-
fiée par l'appel système.
L'argument sockfd est une socket qui a été créée avec la fonction so-
cket(2), attachée à une adresse avec bind(2), et attend des connexions
après un appel listen(2).
L'argument addr est un pointeur sur une structure sockaddr. La struc-
ture sera remplie avec l'adresse du correspondant se connectant, telle
qu'elle est connue par la couche de communication. Le format exact du
paramètre addr dépend du domaine dans lequel la communication s'établit
(consultez socket(2) et la page de manuel correspondant au protocole).
Quand addr vaut NULL, rien n'est rempli ; dans ce cas, addrlen n'est
pas utilisé et doit aussi valoir NULL.
addrlen est un paramètre-résultat : l'appelant doit l'initialiser de
telle sorte qu'il contienne la taille (en octets) de la structure poin-
tée par addr, et est renseigné au retour par la longueur réelle (en oc-
tets) de l'adresse remplie.
L'adresse renvoyée est tronquée si le tampon fourni est trop petit ;
dans ce cas, addrlen renverra une valeur supérieure à celle fournie
lors de l'appel.
S'il n'y a pas de connexion en attente dans la file, et si la socket
n'est pas marquée comme non bloquante, accept() se met en attente d'une
connexion. Si la socket est non bloquante, et qu'aucune connexion n'est
présente dans la file, accept() retourne une erreur EAGAIN ou EWOULD-
BLOCK.
Pour être prévenu de l'arrivée d'une connexion sur une socket, on peut
utiliser select(2), poll(2) ou epoll(7). Un événement « lecture » sera
délivré lorsqu'une tentative de connexion aura lieu, et on pourra alors
appeler accept() pour obtenir une socket pour cette connexion. Autre-
ment, on peut configurer la socket pour qu'elle envoie un signal SIGIO
lorsqu'une activité la concernant se produit, consultez socket(7) pour
plus de détails.
Si flags vaut 0 alors accept4() est identique à accept(). Les valeurs
suivantes peuvent être combinées dans flags par un OU binaire pour ob-
tenir un comportement différent :
SOCK_NONBLOCK Placer l'attribut d'état de fichier O_NONBLOCK sur la
description du fichier ouvert référencée par le nouveau
descripteur de fichier (consulter open(2)). Utiliser
cet attribut économise des appels supplémentaires à
fcntl(2) pour obtenir le même résultat.
SOCK_CLOEXEC Placer l'attribut « close-on-exec » (FD_CLOEXEC) sur le
nouveau descripteur de fichier. Consultez la descrip-
tion de l'attribut O_CLOEXEC dans open(2) pour savoir
pourquoi cela peut être utile.
VALEUR RENVOYÉE
S'ils réussissent, ces appels système renvoient un descripteur de fi-
chier pour la socket acceptée (un entier positif ou nul). En cas d'er-
reur, ils renvoient -1, errno est positionné pour indiquer l'erreur et
addrlen est laissé inchangé.
Traitement des erreurs
Sous Linux, accept() (et accept4()) renvoie les erreurs réseau déjà en
attente sur la socket comme une erreur de l'appel système. Ce comporte-
ment diffère d'autres implémentations des sockets BSD. Pour un compor-
tement fiable, une application doit détecter les erreurs réseau défi-
nies par le protocole après le accept() et les traiter comme des er-
reurs EAGAIN, en réitérant le mécanisme. Dans le cas de TCP/IP, ces er-
reurs sont ENETDOWN, EPROTO, ENOPROTOOPT, EHOSTDOWN, ENONET, EHOSTUN-
REACH, EOPNOTSUPP, et ENETUNREACH.
ERREURS
EAGAIN ou EWOULDBLOCK
La socket est marquée comme étant non bloquante et aucune
connexion n'est présente pour être acceptée. POSIX.1-2001 et PO-
SIX.1-2008 permettent de renvoyer l'une ou l'autre des erreurs
dans ce cas et n'exige pas que ces constantes aient la même va-
leur. Une application portable devrait donc tester les deux pos-
sibilités.
EBADF sockfd n'est pas un descripteur de fichier valable.
ECONNABORTED
Une connexion a été abandonnée.
EFAULT addr n'est pas dans l'espace d'adressage accessible en écriture.
EINTR L'appel système a été interrompu par l'arrivée d'un signal avant
qu'une connexion valable ne survienne ; consultez signal(7).
EINVAL La socket n'est pas en attente de connexions, ou addrlen est non
autorisée (par exemple négatif).
EINVAL (accept4()) flags contient une valeur incorrecte.
EMFILE La limite du nombre de descripteurs de fichiers par processus a
été atteinte.
ENFILE La limite du nombre total de fichiers ouverts pour le système
entier a été atteinte.
ENOBUFS, ENOMEM
Pas assez de mémoire disponible. En général, cette erreur est
due à la taille limitée du tampon des sockets, et non à la mé-
moire système proprement dite.
ENOTSOCK
Le descripteur de fichier sockfd ne fait pas référence à un so-
cket.
EOPNOTSUPP
La socket utilisée n'est pas de type SOCK_STREAM.
EPERM Les règles du pare-feu interdisent la connexion.
EPROTO Erreur de protocole.
De plus il peut se produire des erreurs réseau dépendant du protocole
de la socket. Certains noyaux Linux peuvent renvoyer d'autres erreurs
comme ENOSR, ESOCKTNOSUPPORT, EPROTONOSUPPORT, ETIMEDOUT. L'erreur
ERESTARTSYS peut être rencontrée durant un suivi dans un débogueur.
VERSIONS
L'appel système accept4() est disponible depuis Linux 2.6.28 ; la prise
en charge dans la glibc est disponible depuis la glibc 2.10.
STANDARDS
accept() : POSIX.1-2001, POSIX.1-2008, SVr4, 4.4BSD (accept() est ap-
paru dans BSD 4.2).
accept4() est une extension non standard de Linux.
Avec la version Linux de accept(), la nouvelle socket n'hérite pas des
attributs comme O_NONBLOCK et O_ASYNC de la socket en écoute. Ce com-
portement est différent de l'implémentation BSD de référence. Les pro-
grammes portables ne doivent pas s'appuyer sur cette particularité, et
doivent reconfigurer les attributs sur la socket renvoyée par accept().
NOTES
Il n'y a pas nécessairement de connexion en attente après la réception
de SIGIO ou après que select(2), poll(2) ou epoll(7) indiquent quelque
chose à lire. En effet la connexion peut avoir été annulée à cause
d'une erreur de réseau asynchrone ou par un autre thread avant que ac-
cept() ne soit appelé. Si cela se produit, l'appel bloquera en atten-
dant une autre connexion. Pour s'assurer que accept() ne bloquera ja-
mais, la socket sockfd transmise doit avoir l'attribut O_NONBLOCK
(consultez socket(7)).
Pour certains protocoles nécessitant une confirmation explicite, comme
DECNet, accept() peut être considéré comme extrayant simplement la
connexion suivante de la file, sans demander de confirmation. On peut
effectuer la confirmation par une simple lecture ou écriture sur le
nouveau descripteur, et le rejet en fermant la nouvelle socket. Pour le
moment, seul DECNet se comporte ainsi sous Linux.
Le type socklen_t
Dans l'implémentation des sockets de BSD originale (et sur d'autres an-
ciens systèmes), le troisième paramètre de accept() était déclaré en
tant que int *. Un brouillon du standard POSIX.1g voulait le changer
pour size_t *C ; les derniers standards POSIX et glibc 2.x mentionnent
socklen_t * .
EXEMPLES
Consultez bind(2).
VOIR AUSSI
bind(2), connect(2), listen(2), select(2), socket(2), socket(7)
TRADUCTION
La traduction française de cette page de manuel a été créée par Chris-
tophe Blaess <https://www.blaess.fr/christophe/>, Stéphan Rafin <ste-
phan.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.cou-
lon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas Huriaux
<thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centra-
liens.net>, Florentin Duneau <fduneau@gmail.com>, Simon Paillard <si-
mon.paillard@resel.enst-bretagne.fr>, Denis Barbier <barbier@de-
bian.org>, David Prévot <david@tilapin.org>, Cédric Boutillier <ce-
dric.boutillier@gmail.com>, Frédéric Hantrais <fhantrais@gmail.com> et
Jean-Philippe MENGUAL <jpmengual@debian.org>
Cette traduction est une documentation libre ; veuillez vous reporter à
la GNU General Public License version 3
⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ concernant les conditions
de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel,
veuillez envoyer un message à ⟨debian-l10n-french@lists.debian.org⟩.
Pages du manuel de Linux 6.03 4 décembre 2022 accept(2)
Generated by dwww version 1.15 on Sat Jun 29 01:46:05 CEST 2024.