Discussion :

[LinuxUser]

Bonjour, je souaiterais connaitre la taille d'une trame UDP, et plus precisement la taille du champ données.
Il semblerais que la taille maximum de celui-ci soit 1472 octets.
Cela voudrais-t-il dire que :
1. Il faut plus de 1472 octets de données pour envoyer plus que une seule trame UDP.
2. Que lorsque l'on a moins de 1472 octets de données la trame est "bourée" ou alors que la taille de la trame s'adapte en fonction des données à envoyer.

Exemple :si j'envoie "hello world", est-ce envoyé en plusieurs trame de taille fixe(si oui de quelle taille) ou en une seule trame car inferieur à 1472.

Merci de votre attention et de votre aide.

[BainE]

Bonjour,

toutes les reponses ici

Avec en bas de page un lien vers la RFC qui correspond (et meme un lien avec la meme mais traduite en francais)

[LinuxUser]

OK, merci. Donc la taille est variable et est indiqué dans l entete UDP.
Mais il y a encore une chose qui me tracasse.
En fait je demandais cela car je souhaite numeroter les trames et mettre le numero dans le champ de données, et à la reception controler le desequencement.
Donc si j'ai un texte de moins de 1472 octets cela sera mis dans une seule trame? // désolé de reposer cette question

[ram-0000]

La taille minimum est 8 octets ce qui correspond à 0 octets de données utilisateur (pas très utile comme paquet)
La taille maxi est 65543 octets ce qui correspond à 65535 octets de données utilisateur

Cette taille ne doit pas être confondue avec ton 1472 qui est la taille maxi d'une trame ethernet. Si ton paquet fait plus que 1472, il sera tronconné en autant de plus petits paquets que nécessaire, c'est IP qui s'occupe de cela et aussi du réassemblage.

Donc si j'ai un texte de moins de 1472 octets cela sera mis dans une seule trame?

Je dirai que même si ton paquet fait 1500 octets ou 15000, ce n'est pas ton problème, IP te garanti qu'il le réassemblera. Tu envoies 15000, tu recois 15000 donc ne te préoccupe pas trop, de ce problème.

[LinuxUser]

Justement, c'est se decoupage qui m'interesse.
Car je souhaite ajouter un numero de trame et un checksum a chaque trame.
Par contre je ne sais pas comment elle sent découpée.

[ram-0000]

Le découpage est fait par la couche IP. Il demande ou connait le MTU (Maximum Transmission Unit) du niveau en dessous.

Si c'est de l'ethernet, c'est 1500, si c'est localhost, c'est 10240 (suivant les implémentations), si c'est de la fibre, c'est 4096, si c'est ... et il tronconne pour remplir au maximum les trames.

Comme tu peux le voir, il faut des infos que tu n'as pas au niveau UDP, il faut réassembler à l'autre bout et dans le bon ordre s'il vous plait.

Donc pour ta culture perso, lit et interesse toi mais oublie de l'implémenter au niveau UDP, c'est une fausse bonne idée

[wiztricks]

Justement, c'est se decoupage qui m'interesse.
Car je souhaite ajouter un numero de trame et un checksum a chaque trame.
Par contre je ne sais pas comment elle sent découpée.

Il faut que vous fassiez abstraction entre ce qu'il serait préférable d'appeler message pour signifier les unités d'informations échangées par votre application et les implications qu'auront côté "réseau" l'échange de messages plus grands que la taille du MTU size lorsque vous utilisez UDP pour les transporter.

UDP est une couche au dessus d'IP.
IP sait fragmenter les messages et les réassembler.
Par ailleurs, les messages UDP ont déjà un checksum.

Autrement dit lorsque vous expédier un message par UDP (plus petit que la taille maximale qui doit être 65535 - la taille de l'entête), vous risquez seulement de:
- ne jamais le recevoir ou
- le recevoir un ordre différent que celui dans lequel ils sont été émis.

Ajouter un numéro de message vous permettra de détecter cela...

Mais je serais curieux de savoir comment vous allez traiter cette information.
-W