Editer un article - Informaticien.be

Editer un article

Titre
Mots Clés
Texte	[size=18] [b]Nom[/b] [/size] udp - Protocole UDP pour IPv4 [size=18] [b]Résumé[/b] [/size] [b]#include <sys/socket.h>[/b] [b][/b] [b]#include <netinet/in.h>[/b] [b][/b] [b]udp_socket = socket(PF_INET, SOCK_DGRAM, 0); [/b] [size=18] [b]Description[/b] [/size] Il s'agit d'une implémentation de l'User Datagram Protocol décrit dans la RFC 768. Elle implémente un service de paquets datagrammes non-fiables, sans connexion. Les paquets peuvent être réordonnées ou dupliqués avant leur arrivée. UDP créé et vérifie des sommes de contrôle pour détecter les erreurs de transmission. Lorsqu'une socket UDP est créée, ses adresses locales et distantes sont indéterminées. Les datagrammes peuvent être envoyés immédiatement en utilisant [b]sendto (2)[/b] ou [b]sendmsg (2)[/b] avec une adresse de destination valide en argument. Lorsque [b]connect (2) [/b] est appelé sur une socket, l'adresse de destination par défaut est fixée, et les datagrammes pourront être envoyés avec [b]send (2)[/b] ou [b]write (2)[/b] sans spécifier d'adresse de destination. Il restera possible d'envoyer des données à d'autres destinations en passant l'adresse à [b]sendto (2)[/b] ou [b]sendmsg (2).[/b] Afin de recevoir les paquets, une socket doit être attachée à une adresse locale en utilisant [b]bind (2).[/b] Sinon la couche socket affectera automatiquement une port local libre, hors de l'intervalle défini par [i]net.ipv4.ip_local_port_range[/i] et attacher la socket à l'adresse [b]INADDR_ANY .[/b] Les opérations de réception ne renvoie qu'un seul paquet à la fois. Si le paquet est plus petit que le buffer transmis, il n'y aura pas plus de données renvoyées. S'il est plus grand le paquet sera tronqué et le drapeau [b]MSG_TRUNC[/b] sera activé. [i]MSG_WAITALL[/i] n'est pas supporté. Les options IP peuvent être fixées ou lues en utilisant les options des sockets décrites dans [b]ip (7).[/b] Elles ne sont traitées par le noyau que lorsque le sysctl approprié est activé (mais sont quand même fournies à l'utilisateur quant il est inhibé). Voir [b]ip (7).[/b] Quand l'attribut [b]MSG_DONTROUTE[/b] est actif à l'émission, l'adresse de destination doit représenter une adresse d'interface locale, et le paquet n'est envoyé qu'à cette interface. UDP fragmente un paquet quand sa longueur totale excède le MTU de l'interface (Maximum Transmission Unit). Une alternative plus efficace pour le réseau est d'utiliser la recherche du MTU du chemin, comme indiqué dans la section [b]IP_PMTU_DISCOVER [/b] de [b]ip (7).[/b] [size=18] [b]Format dadresse[/b] [/size] UDP utilise le format d'adresse IPv4 [b]sockaddr_in [/b] comme indiqué dans [b]ip (7). [/b] [size=18] [b]Gestion derreur[/b] [/size] Toutes les erreurs fatales seront transmises à l'utilisateur comme un retour d'erreur même lorsque la socket n'est pas connectée. Ceci inclut les erreurs asynchrones reçues du réseau. Vous pouvez ainsi recevoir une erreur due à un paquet précédemment envoyé sur la même socket. Ce comportement diffère de celui de nombreuses autres implémentations des sockets BSD, qui ne transmettent pas d'erreur si la socket n'est pas connecté. Les comportement de Linux correspond à la [b]RFC 1122 .[/b] Pour assurer la compatibilité avec du code ancien, on peut fixer l'option SOL_SOCKET [b]SO_BSDCOMPAT [/b] pour ne recevoir les erreurs distantes que si la socket a été connectée (sauf pour [b]EPROTO[/b] et [b]EMSGSIZE ).[/b] Il vaut mieux corriger le code pour gérer les erreurs proprement plutôt que d'activer cette option. Les erreurs locales sont toujours transmises. Lorsque l'option [b]IP_RECVERR[/b] est active, toutes les erreurs sont stockées dans la file d'erreur de la socket et peuvent être lues avec [b]recvmsg (2)[/b] en activant son option [b]MSG_ERRQUEUE .[/b] [size=18] [b]Ioctls[/b] [/size] Les ioctls sont accessible avec l'appel-système [b]ioctl (2).[/b] La syntaxe correcte est : [table][row][col]    [/col][col] .nf [b][i]int value;[/i][/b] [b][i]error = ioctl( tcp_socket , ioctl_type , & value );[/i][/b] .fi[/col][/row][/table] [b]SIOCINQ[/b] [table][row][col]    [/col][col]Prend en argument un pointeur sur un entier. Y écrit la taille en octets du prochain datagramme en attente, ou 0 si aucun datagramme n'est disponible.[/col][/row][/table] [b]SIOCOUTQ[/b] [table][row][col]    [/col][col]Renvoie le nombre d'octets de données dans la file d'émission locale. Seulement sur Linux 2.4 et ultérieurs.[/col][/row][/table] De plus, les ioctls documenté dans [b]ip (7)[/b] et [b]socket (7)[/b] sont supportés. [size=18] [b]Erreurs[/b] [/size] Toutes les erreurs documentées pour [b]socket (7)[/b] ou [b]ip (7)[/b] peuvent être renvoyées lors d'une émission ou d'une réception sur une socket UDP. [b]ECONNREFUSED[/b] Aucun correspondant sur l'adresse destination associée à la socket. Ceci peut être causé par l'émission antérieure d'un paquet sur la socket. [size=18] [b]Versions[/b] [/size] IP_RECVERR est une nouveauté de Linux 2.2. [size=18] [b]Credits[/b] [/size] Cette page de manuel a été écrite par Andi Kleen. [size=18] [b]Voir aussi[/b] [/size] [b]ip (7),[/b] [b]socket (7),[/b] [b]raw (7).[/b] RFC 768 pour le protocole UDP [b][/b] RFC 1122 pour les nécessité de l'hôte. [b][/b] RFC 1191 pour une description de la recherche du MTU par chemin. [size=18] [b]Traduction[/b] [/size] Christophe Blaess, 2001-2003.
Fichier