RFC: 768
Statut : Standard
La suprématie américaine en matière d'Internet est elle un fatalité absolue. Il faut croire que nous avons du mal, nous les francophones à comprendre la nécessité impérieuse de défendre notre culture et de la transmission de documentation.
J'ai donc entrepris ce travail colossal de traduire (ne rêvons pas complètement ! j'en profite pour me former également) les principales spécifications concernant les technologies Internet.
| Disponible : | rfc793 - VF - 30/09/97 TCP |
| Présentation de TCP/IP (Rutgers) - VF | |
| En préparation : | rfc959 - VF - **/**/** FTP |
| rfc791/792 - VF - **/**/** IP | |
| rfc1034/1035 - VF - **/**/** Domaines | |
| rfc2083 - VF - **/**/** PNG (format graphique) en cours |
D'autres RFC sont en préparation. Cela prendra seulement un petit peu de temps.
Le texte suivant est la traduction intégrale de la spécification UDP, telle qu'éditée par les auteurs originaux du protocole, sans ajouts, commentaires, ni omissions. Ce document est un standard reconnu et approuvé par la communauté Internet.
Le protocole User Datagram Protocol (UDP) est défini dans le but de fournir une communication par paquet unique entre deux processus dans un environnement réseau étendu. Ce protocole suppose l'utilisation du protocole IP comme support de base à la communication.
Ce protocole définit une procédure permettant à une application d'envoyer un message court à une autre application, selon un mécanisme minimaliste. Ce protocole est transactionnel, et ne garantit ni la délivrance du message, ni son éventuelle duplication. Les applications nécessitant une transmission fiabilisée et ordonnée d'un flux de données implémenteront de préférence le protocole TCP (Transmission Control Protocol) [2].
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| Port | Port |
| Source | Destinataire |
+--------+--------+--------+--------+
| | |
| Longueur | Checksum |
+--------+--------+--------+--------+
| données ... |
+---------------- ... --------------+
En-tête UDP
Le Port Source est un champ optionnel. Lorsqu'il est significatif, il indique le numéro de port du processus émetteur, et l'on supposera, en l'absence d'informations complémentaires, que toute réponse devra y être dirigée. S'il n'est pas utilisé, ce champ conservera une valeur 0.
Le Port Destinataire a une signification dans le cadre d'adresses Internet particulières.
La Longueur compte le nombre d'octets dans le datagramme entier y compris le présent en-tête. (Et par conséquent la longueur minimale mentionnée dans ce champ vaut huit, si le datagramme ne transporte aucune donnée).
Le Checksum se calcule en prenant le complément à un de la somme sur 16 bits des compléments à un calculé sur un pseudo en-tête constitué de l'information typique d'une en-tête IP, l'en-tête UDP elle-même, et les données, le tout additionné d'un octet nul éventuel afin que le nombre total d'octets soit pair.
La pré en-tête ajoutée avant l'en-tête UDP contient l'adresse IP source, l'adresse IP destinataire, le code de protocole, et la longueur du segment UDP. Cette information permet d'augmenter l'immunité du réseau aux erreurs de routage de datagrammes. La procédure de calcul du Checksum est la même que pour TCP.
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| adresse source |
+--------+--------+--------+--------+
| adresse destination |
+--------+--------+--------+--------+
| zéro |protocol| Longueur UDP |
+--------+--------+--------+--------+
Si le calcul du checksum vaut zéro, il sera transmis tous ses bits à un (le complément à un). UN Checksum transmis avec une valeur zéro a effectivement une signification particulière. Dans ce cas, le segment indique qu'aucun Checksum n'a été calculé (pour des besoins de mise au point ou pour des protocoles de niveaux supérieurs qui rendent cette vérification inutile).
L'interface utilisateur doit permettre l'ouverture de nouveaux ports de réception, la réception des données et leur transmission ainsi que celle de l'adresse source à l'application sur le port de réception mis en place, et doit mettre en place une commande permettant l'émission d'un datagramme, par laquelle seront spécifiés les données, l'adresse et ports source et destination à utiliser.
Le module UDP doit extraire les adresses source et destination de l'en-tête IP, et vérifier le numéro de protocole. Une interface UDP/IP plausible pourrait retourner le datagramme entier y compris l'en-tête Internet en réponse du datagramme reçu. Une interface devra pour cela permettre à UDP de passer un datagramme Internet complet avec une en-tête IP à la couche IP elle même pour émission. IP n'aura plus qu'à vérifier la cohérence des champs d'en-tête IP préparés par UDP et calculer le Checksum.
Ce protocole sera utilisé principalement pour les communications avec les serveurs de noms de domaines [3], et dans les transactions utilisant le protocole Trivial File Transfer [4].
Ce protocole porte le numéro 17 (21 en octal) lorsqu'il est transporté par le Protocole Internet. D'autres numéros de protocoles pour d'autres couches support sont données dans la référence [5].
[1] Postel, J., "Internet Protocol," RFC 760, USC/Information Sciences Institute, January 1980.
[2] Postel, J., "Transmission Control Protocol," RFC 761, USC/Information Sciences Institute, January 1980.
[3] Postel, J., "Internet Name Server," USC/Information Sciences Institute, IEN 116, August 1979.
[4] Sollins, K., "The TFTP Protocol," Massachusetts Institute of Technology, IEN 133, January 1980.
[5] Postel, J., "Assigned Numbers," USC/Information Sciences Institute, RFC 762, January 1980.