Editer un article - Informaticien.be

Editer un article

Titre
Mots Clés
Texte	[size=18] [b]Nom[/b] [/size] recv, recvfrom, recvmsg - Recevoir un message sur une socket. [size=18] [b]Résumé[/b] [/size] [b]#include <sys/types.h>[/b] [b][/b] [b]#include <sys/socket.h>[/b] [b][i]int recv(int s , void * buf , int len , unsigned int flags );[/i][/b] [b][i]int recvfrom(int s , void * buf , int len , unsigned int flags[/i][/b] [b][i]struct sockaddr * from , socklen_t * fromlen );[/i][/b] [b][i]int recvmsg(int s , struct msghdr * msg , unsigned int flags );[/i][/b] [size=18] [b]Description[/b] [/size] Les appels-système [b]recvfrom[/b] et [b]recvmsg[/b] sont utilisés pour recevoir des messages depuis une socket [i]s,[/i] et peuvent servir sur une socket orientée connexion ou non. Si [i]from[/i] n'est pas NULL, et si la socket n'est pas orientée connexion, l'adresse de la source du messages y est insérée. L'argument [i]fromlen[/i] est un paramètre résultat, initialisé à la taille du buffer [b]from ,[/b] et modifié en retour pour indiquer la taille réelle de l'adresse enregistrée. L'appel [b]recv[/b] est normalement utilisé sur une socket [i]connectée[/i] (voir [b]connect (2))[/b] et est équivalent à [b]recvfrom[/b] avec un paramètre [i]from[/i] nul. Ces trois routines renvoient la longueur du message si elles réussissent. Si un message est trop long pour tenir dans le buffer, les octets supplémentaires peuvent être abandonnés suivant le type de socket utilisé (voir [b]socket (2)).[/b] 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 [b]fcntl (2))[/b] auquel cas la valeur -1 est renvoyée, et [i]errno[/i] est positionnée à [b]EAGAIN.[/b] 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 [b]select (2)[/b] ou [b]poll (2)[/b] peuvent permettre de déterminer si des données supplémentaires sont disponibles. L'argument [i]flags[/i] de l'appel recv est constitué par un [i]OU binaire[/i] entre une ou plusieurs des valeurs suivantes : [b]MSG_OOB[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]MSG_PEEK[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]MSG_WAITALL[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]MSG_NOSIGNAL[/b] [table][row][col]    [/col][col]désactive l'émission de [b]SIGPIPE[/b] sur les sockets connectées dont le correspondant disparaît.[/col][/row][/table] [b]MSG_TRUNC[/b] [table][row][col]    [/col][col]Renvoyer la longueur réelle du paquet, même s'il était plus long que le buffer transmis. Valide uniquement pour les sockets paquets.[/col][/row][/table] [b]MSG_ERRQUEUE[/b] [table][row][col]    [/col][col]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 ([b]IP_RECVERR[/b] pour IPv4). Il faut alors fournir un buffer de taille suffisante. Voir [b]cmsg (3)[/b] et [b]ip (7)[/b] pour plus de détails. Le contenu du paquet original qui a causé l'erreur est passé en tant que données normales dans [b]msg_iovec .[/b] L'adresse de destination originale du datagramme ayant causé l'erreur est fournie dans [b]msg_name .[/b][/col][/row][/table] [table][row][col]    [/col][col]Pour les erreurs locales, aucune adresse n'est passée (ceci peut être vérifié dans le membre [i]cmsg_len[/i] de [b]cmsghdr ).[/b] Pour les erreurs reçues, le [b]MSG_ERRQUEUE[/b] est placé dans [b]msghdr .[/b] Après qu'une erreur ait été transmise, 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 [b]sock_extended_err :[/b][/col][/row][/table] [table][row][col]    [/col][col] [table][row][col]    [/col][col].ne 18 .nf .ta 4n 20n 32n #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 { u_int32_t ee_errno; /* numéro d'erreur / u_int8_t ee_origin; / origine de l'erreur / u_int8_t ee_type; / type / u_int8_t ee_code; / code / u_int8_t ee_pad; / remplissage / u_int32_t ee_info; / données supplémentaires/ u_int32_t ee_data; / autres données / / More data may follow / }; struct sockaddr SO_EE_OFFENDER(struct sock_extended_err ); .ta .fi[/col][/row][/table][/col][/row][/table] [b]ee_errno[/b] [table][row][col]    [/col][col]contient le code [i]errno[/i] de l'erreur en file. [b]ee_origin[/b] est le code d'origine de l'erreur. Les autres champs sont spécifiques au protocole. La macro [b]SOCK_EE_OFFENDER[/b] 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 [i]sa_family[/i] de la structure [b]sockaddr[/b] contient [b]AF_UNSPEC[/b] et les autres champs de la structure [b]sockaddr[/b] sont indéfinis. Le contenu du paquet ayant déclenché l'erreur est transmis en données normales.[/col][/row][/table] [table][row][col]    [/col][col]Pour les erreurs locales, aucune adresse n'est transmise (ceci peut être vérifié dans le champ [i]cmsg_len[/i] de [b]cmsghdr ).[/b] À la réception d'erreur, [b]msghdr[/b] sera rempli avec [b]MSG_ERRQUEUE .[/b] Après la lecture d'une erreur, l'état de la socket est modifié d'après l'erreur suivante dans la file.[/col][/row][/table] L'appel [b]recvmsg[/b] utilise une structure [i]msghdr[/i] pour minimiser le nombre de paramètres à fournir directement. Cette structure à la forme suivante, définie dans [b]<sys/socket.h>[/b] [table][row][col]    [/col][col] [table][row][col]    [/col][col].nf .ta 4n 17n 33n struct msghdr { caddr_t msg_name; / optional address / u_int msg_namelen; / size of address / struct iovec msg_iov; /* scatter/gather array / u_int msg_iovlen; / # elements in msg_iov / caddr_t msg_control; / ancillary data, see below / u_int msg_controllen; / ancillary data buffer len / int msg_flags; / flags on received message / }; .ta .fi[/col][/row][/table][/col][/row][/table] Ici [i]msg_name[/i] et [i]msg_namelen[/i] spécifient l'adresse d'origine si la socket n'est pas connectée, [i]msg_name[/i] peut être un pointeur nul si le nom n'est pas nécessaire. [i]msg_iov[/i] et [i]msg_iovlen[/i] décrivent les buffers de réception comme décrit dans [b]readv (2).[/b] [b]msg_control ,[/b] de longueur [b]msg_controllen ,[/b] pointe sur un buffer utilisé pour les autres messages relatifs au protocole, ou à d'autres données annexes. Lorsqu'on invoque [b]recvmsg ,[/b] [i]msg_controllen[/i] doit contenir la longueur disponible dans le buffer [b]msg_control ;[/b] au retour il contiendra la longueur de la séquence de message de contrôle. Les messages ont la forme [table][row][col]    [/col][col] .nf .ta 4n 16n 28n struct cmsghdr { u_int cmsg_len; / data byte count, including hdr / int cmsg_level; / originating protocol / int cmsg_type; / protocol-specific type / / followed by u_char cmsg_data[]; / }; .ta .fi[/col][/row][/table] Les données de service ne doivent être manipulées qu'avec les macros de [b]cmsg (3)[/b] À titre d'exemple, Linux utilise ce mécanisme pour transmettre des erreurs étendues, des options IP, ou des descripteurs de fichiers sur des sockets Unix. Le champ [i]msg_flags[/i] du msghdr est rempli au retour de [b]recvmsg ().[/b] Il peut contenir plusieurs attributs : [b]MSG_EOR[/b] [table][row][col]    [/col][col]indique une fin d'enregistrement, les données reçues terminent un enregistrement (utilisé généralement avec les sockets du type [b]SOCK_SEQPACKET ).[/b][/col][/row][/table] [b]MSG_TRUNC[/b] [table][row][col]    [/col][col]indique que la portion finale du datagramme a été abandonnée car le datagramme était trop long pour le buffer fourni.[/col][/row][/table] [b]MSG_CTRUNC[/b] [table][row][col]    [/col][col]indique que des données de contrôle ont été abandonnées à cause d'un manque de place dans le buffer de données annexes.[/col][/row][/table] [b]MSG_OOB[/b] [table][row][col]    [/col][col]indique que des données hors-bande ont été reçues.[/col][/row][/table] [b]MSG_ERRQUEUE[/b] [table][row][col]    [/col][col]indique qu'aucune donnée n'a été reçue, sauf une erreur étendue depuis la file d'erreurs.[/col][/row][/table] [b]MSG_DONTWAIT[/b] [table][row][col]    [/col][col]Activer les opérations non-bloquantes. Si l'opération devait bloquer, [b]EAGAIN[/b] serait renvoyé (on peut aussi activer ce comportement avec l'option [b]O_NONBLOCK[/b] de la fonction [b]F_SETFL[/b] de [b]fcntl (2).[/b][/col][/row][/table] [size=18] [b]Valeur renvoyée[/b] [/size] Ces fonctions renvoient le nombre d'octets reçus si elles réussissent, ou -1 si elles échouent, auquel cas [i]errno[/i] contient le code d'erreur. [size=18] [b]Erreurs[/b] [/size] 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. [b]EBADF[/b] [table][row][col]    [/col][col]L'argument [i]s[/i] n'est pas un descripteur valide.[/col][/row][/table] [b]ECONNREFUSED[/b] [table][row][col]    [/col][col]Un hôte distant à refusé la connexion réseau (généralement parce qu'il n'offre pas le service demandé).[/col][/row][/table] [b]ENOTCONN[/b] [table][row][col]    [/col][col]La socket est associée à un protocole orienté connexion et n'a pas encore été connectée (voir [b]connect (2)[/b] et [b]accept (2)).[/b][/col][/row][/table] [b]ENOTSOCK[/b] [table][row][col]    [/col][col]L'argument [i]s[/i] ne correspond pas à une socket.[/col][/row][/table] [b]EAGAIN[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]EINTR[/b] [table][row][col]    [/col][col]Un signal a interrompu la lecture avant que des données soient disponibles.[/col][/row][/table] [b]EFAULT[/b] [table][row][col]    [/col][col]Un buffer pointe en dehors de l'espace d'adressage accessible.[/col][/row][/table] [b]EINVAL[/b] [table][row][col]    [/col][col]un argument est invalide.[/col][/row][/table] [size=18] [b]Conformité[/b] [/size] 4.4 BSD (ces fonctions sont apparues dans BSD 4.2). [size=18] [b]Note[/b] [/size] 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., libc4 , et libc5 renvoient un `int'). L'argument [i]flags[/i] est un `int' dans BSD 4., mais `unsigned int' dans libc4 et libc5. L'argument [i]len[/i] est un `int' dans BSD 4., mais un `size_t' dans libc4 et libc5. L'argument [i]fromlen[/i] est un int ' dans BSD 4., libc4 et libc5. Le type `socklen_t *' a été inventé par POSIX. [size=18] [b]Voir aussi[/b] [/size] [b]accept (2).[/b] [size=18] [b]Voir aussi[/b] [/size] [b]accept (2).[/b] [b]fcntl (2),[/b] [b]read (2),[/b] [b]select (2),[/b] [b]getsockopt (2),[/b] [b]socket (2),[/b] [b]cmsg (3)[/b] [size=18] [b]Traduction[/b] [/size] Christophe Blaess, 1996-2003.
Fichier