NOM
recv, recvfrom, recvmsg - Recevoir un message sur une socket
SYNOPSIS
#include <sys/types.h>
#include <sys/socket.h>
ssize_t recv(int sockfd, void *buf, size_t len, int flags);
ssize_t recvfrom(int sockfd, void *buf, size_t len, int flags,
struct sockaddr *src_addr, socklen_t *addrlen);
ssize_t recvmsg(int sockfd, struct msghdr *msg, int flags);
Les appels système recvfrom() et recvmsg() sont utilisés pour recevoir
des messages depuis une socket, et peuvent servir sur une socket
orientée connexion ou non.
Si src_addr n’est pas NULL, et si le protocole sous-jacent fournit
l’adresse de la source, celle-ci y est insérée. Quand src_addr vaut
NULL, rien n’est inséré ; dans ce cas, addrlen n’est pas utilisé et
devrait également valoir NULL. addrlen est un paramètre résultat,
initialisé à la taille du tampon src_addr, et modifié en retour pour
indiquer la taille réelle de l’adresse enregistrée. L’adresse renvoyée
est tronquée si le tampon fourni est trop petit ; dans ce cas, addrlen
renverra une valeur supérieure à celle fourni lors de l’appel.
L’appel recv() est normalement utilisé sur une socket connecte (voir
connect(2)) et est équivalent à recvfrom() avec un paramètre src_addr
NULL.
Ces trois routines renvoient la longueur du message si elles
réussissent. Si un message est trop long pour tenir dans le tampon, les
octets supplémentaires peuvent être abandonnés suivant le type de
socket utilisé.
Si aucun message n’est disponible sur la socket, les fonctions de
réception se mettent en attente, à moins que la socket soit non
bloquante (voir fcntl(2)) auquel cas la valeur -1 est renvoyée, et
errno est positionnée à EAGAIN ou EWOULDBLOCK. Les fonctions de
réception renvoient normalement les données disponibles sans attendre
d’avoir reçu le nombre exact réclamé.
Les appels système select(2) ou poll(2) peuvent permettre de déterminer
si des données supplémentaires sont disponibles.
L’argument flags de l’appel recv() est constitué par un OU binaire
entre une ou plusieurs des valeurs suivantes :
MSG_CMSG_CLOEXEC (recvmsg() uniquement ; depuis Linux 2.6.23)
Positionne l’attribut « close-on-exec » pour le descripteur de
fichier reçu via un descripteur de fichier de domaine Unix en
utilisant l’opération SCM_RIGHTS (décrite dans unix(7)). Cet
attribut est utile pour les mêmes raisons que l’attribut
O_CLOEXEC de open(2).
MSG_DONTWAIT (depuis Linux 2.2)
Activer les opérations non bloquantes. Si l’opération devait
bloquer, l’appel échouera avec l’erreur EAGAIN ou EWOULDBLOCK
(on peut aussi activer ce comportement avec l’option O_NONBLOCK
de la fonction F_SETFL de fcntl(2)).
MSG_ERRQUEUE (depuis Linux 2.2)
Cet attribut demande que les erreurs soient reçues depuis la
file d’erreur de la socket. Les erreurs sont transmises dans un
message annexe dont le type dépend du protocole (IP_RECVERR pour
IPv4). Il faut alors fournir un tampon de taille suffisante.
Voir cmsg(3) et ip(7) pour plus de détails. Le contenu du paquet
original qui a causé l’erreur est passé en tant que données
normales dans msg_iovec. L’adresse de destination originale du
datagramme ayant causé l’erreur est fournie dans msg_name.
Pour les erreurs locales, aucune adresse n’est passée (ceci peut
être vérifié dans le membre cmsg_len de cmsghdr). À la réception
d’une erreur, MSG_ERRQUEUE est placé dans msghdr. Après
réception d’une erreur, l’erreur en attente sur la socket est
régénérée en fonction de la prochaine erreur dans la file, et
sera transmise lors de l’opération suivante sur la socket.
L’erreur est contenue dans une structure sock_extended_err :
#define SO_EE_ORIGIN_NONE 0
#define SO_EE_ORIGIN_LOCAL 1
#define SO_EE_ORIGIN_ICMP 2
#define SO_EE_ORIGIN_ICMP6 3
struct sock_extended_err
{
uint32_t ee_errno; /* numéro d’erreur */
uint8_t ee_origin; /* origine de l’erreur */
uint8_t ee_type; /* type */
uint8_t ee_code; /* code */
uint8_t ee_pad; /* remplissage */
uint32_t ee_info; /* données supplémentaires */
uint32_t ee_data; /* autres données */
/* Des données supplémentaires peuvent suivre */
};
struct sockaddr *SO_EE_OFFENDER(struct sock_extended_err *);
ee_errno contient le code errno de l’erreur en file. ee_origin
est le code d’origine de l’erreur. Les autres champs sont
spécifiques au protocole. La macro SOCK_EE_OFFENDER renvoie un
pointeur sur l’adresse de l’objet réseau ayant déclenché
l’erreur, à partir d’un pointeur sur le message. Si l’adresse
n’est pas connue, le membre sa_family de la structure sockaddr
contient AF_UNSPEC et les autres champs de la structure sockaddr
sont indéfinis. Le contenu du paquet ayant déclenché l’erreur
est transmis en données normales.
Pour les erreurs locales, aucune adresse n’est passée (ceci peut
être vérifié dans le membre cmsg_len de cmsghdr). À la réception
d’une erreur, MSG_ERRQUEUE est placé dans msghdr. Après
réception d’une erreur, l’erreur en attente sur la socket est
régénérée en fonction de la prochaine erreur dans la file, et
sera transmise lors de l’opération suivante sur la socket.
MSG_OOB
Cette option permet la lecture des données hors-bande qui ne
seraient autrement pas placées dans le flux de données normales.
Certains protocoles placent ces données hors-bande en tête de la
file normale, et cette option n’a pas lieu d’être dans ce cas.
MSG_PEEK
Cette option permet de lire les données en attente dans la file
sans les enlever de cette file. Ainsi une lecture ultérieure
renverra à nouveau les mêmes données.
MSG_TRUNC (depuis Linux 2.2)
Pour les socket en mode brut (AF_PACKET), datagramme Internet
(depuis Linux 2.4.27/2.6.8) et netlink (depuis Linux 2.6.22) :
renvoyer la taille réelle du paquet ou datagramme, même quand il
est plus grand que le tampon fourni. Ce n’est pas implémenté
pour les sockets de domaine Unix (unix(7)).
Pour une utilisation avec des sockets en mode flux, consultez
tcp(7).
MSG_WAITALL (depuis Linux 2.2)
Cette option demande que l’opération de lecture soit bloquée
jusqu’à ce que la requête complète soit satisfaite. Toutefois,
la lecture peut renvoyer quand même moins de données que prévu
si un signal est reçu, ou si une erreur ou une déconnexion se
produisent.
L’appel recvmsg() utilise une structure msghdr pour minimiser le nombre
de paramètres à fournir directement. Cette structure est définie dans
<sys/socket.h> comme ceci :
struct iovec { /* dispersion/assemblage
d’éléments de tableaux */
void *iov_base; /* Adresse de début */
size_t iov_len; /* Nombre d’octets à transférer */
};
struct msghdr {
void *msg_name; /* adresse optionnelle */
socklen_t msg_namelen; /* taille de l’adresse */
struct iovec *msg_iov; /* tableau scatter/gather */
size_t msg_iovlen; /* # éléments dans msg_iov */
void *msg_control; /* métadonnées, voir ci‐dessous */
socklen_t msg_controllen; /* taille du tampon de métadonnées */
int msg_flags; /* attributs du message reçu */
};
Ici msg_name et msg_namelen spécifient l’adresse d’origine si la socket
n’est pas connectée ; msg_name peut être un pointeur nul si le nom
n’est pas nécessaire. msg_iov et msg_iovlen décrivent les tampons de
réception comme décrit dans readv(2). msg_control, de longueur
msg_controllen, pointe sur un tampon utilisé pour les autres messages
relatifs au protocole, ou à d’autres données annexes. Lorsqu’on invoque
recvmsg, msg_controllen doit contenir la longueur disponible dans le
tampon msg_control ; au retour il contiendra la longueur de la séquence
de message de contrôle.
Les messages ont la forme
struct cmsghdr {
socklen_t cmsg_len; /* nombre d’octets de données, y compris l’en-tête */
int cmsg_level; /* protocole d’origine */
int cmsg_type; /* type dépendant du protocole */
/* suivi de
unsigned char cmsg_data[]; */
};
Les données de service ne doivent être manipulées qu’avec les macros de
cmsg(3).
À titre d’exemple, Linux utilise ce mécanisme pour transmettre des
erreurs étendues, des options IP, ou des descripteurs de fichier sur
des sockets Unix.
Le champ msg_flags du msghdr est rempli au retour de recvmsg(). Il peut
contenir plusieurs attributs :
MSG_EOR
indique une fin d’enregistrement, les données reçues terminent
un enregistrement (utilisé généralement avec les sockets du type
SOCK_SEQPACKET).
MSG_TRUNC
indique que la portion finale du datagramme a été abandonnée car
le datagramme était trop long pour le tampon fourni.
MSG_CTRUNC
indique que des données de contrôle ont été abandonnées à cause
d’un manque de place dans le tampon de données annexes.
MSG_OOB
indique que des données hors-bande ont été reçues.
MSG_ERRQUEUE
indique qu’aucune donnée n’a été reçue, sauf une erreur étendue
depuis la file d’erreurs.
VALEUR RENVOYÉE
Ces fonctions renvoient le nombre d’octets reçus si elles réussissent,
ou -1 si elles échouent. La valeur de retour sera 0 si le pair a
effectué un arrêt normal.
ERREURS
Il y a des erreurs standards déclenchées par le niveau socket, et des
erreurs supplémentaires spécifiques aux protocoles. Voyez leurs pages
de manuel.
EAGAIN ou EWOULDBLOCK
La socket est non bloquante et aucune donnée n’est disponible,
ou un délai de timeout a été indiqué, et il a expiré sans que
l’on ait reçu quoi que ce soit. POSIX.1-2001 permet de renvoyer
l’une ou l’autre des erreurs dans ce cas et n’exige pas que ces
constantes aient la même valeur. Une application portable
devrait donc tester les deux possibilités.
EBADF Le paramètre sockfd n’est pas un descripteur correct.
ECONNREFUSED
Un hôte distant a refusé la connexion réseau (généralement parce
qu’il n’offre pas le service demandé).
EFAULT Un tampon pointe en dehors de l’espace d’adressage accessible.
EINTR Un signal a interrompu la lecture avant que des données soient
disponibles ; voir signal(7).
EINVAL Un paramètre non valable a été fourni.
ENOMEM Pas assez de mémoire pour recvmsg().
ENOTCONN
La socket est associée à un protocole orienté connexion et n’a
pas encore été connectée (voir connect(2) et accept(2)).
ENOTSOCK
Le paramètre sockfd ne correspond pas à une socket.
CONFORMITÉ
BSD 4.4 (ces fonctions sont apparues dans BSD 4.2), POSIX.1-2001.
POSIX.1-2001 décrit seulement les drapeaux MSG_OOB, MSG_PEEK, et
MSG_WAITALL.
NOTES
Les prototypes fournis concernent la glibc 2. Les Spécifications Single
Unix les définissent, mais le type de retour est ssize_t (alors que
BSD 4.x, libc4 , et libc5 renvoient un int). L’argument flags est un
int dans BSD 4.x, mais unsigned int dans libc4 et libc5. L’argument len
est un int dans BSD 4.x, mais un size_t dans libc4 et libc5. L’argument
addrlen est un int * dans BSD 4.x, libc4 et libc5. Le socklen_t *
actuel a été inventé par POSIX. Voir également accept(2).
Selon POSIX.1-2001, le champ msg_controllen de la structure msghdr
devrait être de type socklen_t, mais il a actuellement le type size_t
dans la glibc (version 2.4).
EXEMPLE
Un exemple d’utilisation de recvfrom() se trouve dans la page de manuel
de getaddrinfo(3).
VOIR AUSSI
fcntl(2), getsockopt(2), read(2), select(2), shutdown(2), socket(2),
cmsg(3), sockatmark(3), socket(7)
COLOPHON
Cette page fait partie de la publication 3.23 du projet man-pages
Linux. Une description du projet et des instructions pour signaler des
anomalies peuvent être trouvées à l’adresse
http://www.kernel.org/doc/man-pages/.
TRADUCTION
Cette page de manuel a été traduite et mise à jour par Christophe
Blaess <http://www.blaess.fr/christophe/> entre 1996 et 2003, puis par
Alain Portal <aportal AT univ-montp2 DOT fr> jusqu’en 2006, et mise à
disposition sur http://manpagesfr.free.fr/.
Les mises à jour et corrections de la version présente dans Debian sont
directement gérées par Julien Cristau <jcristau@debian.org> et l’équipe
francophone de traduction de Debian.
Veuillez signaler toute erreur de traduction en écrivant à
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
paquet manpages-fr.
Vous pouvez toujours avoir accès à la version anglaise de ce document
en utilisant la commande « man -L C <section> <page_de_man> ».