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

[LinuxUser]

Mon but est justement de detecter les desequencements(en numerotant les trames) et les erreurs(en ajoutant un checksum) en ajoutant ces informations(num+checksum) dans le champs data udp.
Mais ne connaissant pas la taille des trames ni comment elles sont decoupées je ne sais pas comment ajouter ces infos.
Je précise que ce n'est pas par culture personnel mais pour un projet.
Merci.

[Emmanuel Delahaye]

Mon but est justement de detecter les desequencements(en numerotant les trames) et les erreurs(en ajoutant un checksum) en ajoutant ces informations(num+checksum) dans le champs data udp.
Mais ne connaissant pas la taille des trames ni comment elles sont decoupées je ne sais pas comment ajouter ces infos.
Je précise que ce n'est pas par culture personnel mais pour un projet.
Merci.

Si tu veux ajouter un couche de protocole audessu de UDP, (comme TFTP, par exemple), libre à toi, mais les datagrams (paquets de données) seront de toutes façons reçus comme ils ont été émis. Par contre, oui, il peut en manquer un, et dans ce cas, la numérotation peut avoir un sens.

Dans ce cas, prévois une encapsulation dans le genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

[N° de séquence | taille | données | checksum]

(pas sûr que le checksum soit utile, IP ne peut pas faire d'erreur en principe...)

Mais comme c'est une couche supérieure, c'est à toi de faire ce travail.

Par exemple, tu as un bloc de 2 Mo a transférer en UDP.

Tu décides, pour des raisons de compromis entre sécurité et rapidité, que les blocs font un maximum de 16k.

Tu définis (MSB en tête) :

[0..1] NFRAME : Numéro de trame (16-bit)
[2..3] LDATA : Longueur des données (16-bit)
[4..4 + LDATA] DATA : (Données)
[4 + LDATA+1 .. 4 + LDATA+2] CHKSUM : Checksum (16-bit)

et tu découpes le bloc à émettre en autant de trames numérotées que nécessaire et que tu envoies avec sendto().

Il est peut être intéressant, selon le contexte, de transmettre aussi au début une trame d'info qui contient
- la longueur des données à émettre
- le checksum des données (32-bit)
- le nom du fichier, les droits...

[wiztricks]

Hu?!
Le numéro de séquence gère l'ordre dans lequel les messages arrivent.
Vous l'utilisez aussi pour gérer les numéros de fragments.
Ca ne peut pas marcher!

Est-il utile de gérer la fragmentation?
Pensez à la sérialisation de vos informations.
- W

[LinuxUser]

Si tu veux ajouter un couche de protocole audessu de UDP,

C'est exactement cela.

mais les datagrams (paquets de données) seront de toutes façons reçus comme ils ont été émis.
(pas sûr que le checksum soit utile, IP ne peut pas faire d'erreur en principe...)

Un programme "medium" nous est fourni qui desequence,engendre des pertes et des erreurs dans les messages transmis en UDP.

Et je dois justement sécurisé UDP.

Ce que je ne comprenait pas, c'etait comment numéroté les trames, mais à présent je vois à peu près comment faire.

Désolé si je répète ce que vous dites, mais c'est pour etre bien sur.

Si je comprend bien, je devrais définir une taille de trame : 16koctets.
Découper mes messages en paquets de 16koctets.

Définir chaque trame :

octet 0 et 1 : numero de trame
octet 2 et 3 : longueur des données // je pense qu'un seul octet suffirait
octet 4 jusqu'à octet 13 : pour les données
octet 14 et 15 : le checksum. // j'aurais plutot mis aux octets 4 et 5, puis le reste pour les données

Puis envoyer successivement les trames avec sendto.

[Emmanuel Delahaye]

Définir chaque trame :

octet 0 et 1 : numero de trame
octet 2 et 3 : longueur des données // je pense qu'un seul octet suffirait
octet 4 jusqu'à octet 13 : pour les données
octet 14 et 15 : le checksum. // j'aurais plutot mis aux octets 4 et 5, puis le reste pour les données

Pourquoi tu déformes ce que je dis ?

Il faut que je fasse un copié-collé ?

La longueur des données peut faire jusqu'à 16 ko. Tu penses que 4000h (16384), ça rentre dans un octet ?

Pourquoi "jusqu'à octet 13" ? Le checksum se trouve au bout des données. Sa position dépende la longueur de la trame, non ? C'est pas ce que j'avais écrit ? J'ajoute, parce que ça n'a pas l'air évident, que cette longueur peut faire de 0 à 16384.

Le checksum n'est certainement pas en 14 et 15... J'ai déjà donné la formule...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
+------+--------+--------------------------------+--------+
|Numero|Longueur|Données ........................|Ckecksum|
+------+--------+--------------------------------+--------+

ce n'est qu'un exemple. Tu peux définir un autre format si ça te chante...

[LinuxUser]

Désolé, je n'avais pas bien compris.

Au sujet de la taille, y'a-t-il une raison particuliere pour 16ko, ou est-ce juste un exemple?

Et si les données n'atteignent pas la taille MAX, dois-je "bourrer" manuellment la trame?

Et désolé d'insister, mais pourquoi le checksum à la fin? J'aurais plutot penser le mettre avant les donnees.

Et pour le checksum, je ne sais pas si je dois inclure les IP(source+dest) pour le calcul de ce dernier.

Désolé si je pose des questions un peu bêtes ou redondantes.

[ram-0000]

A mon avis, IP et UDP disposent déjà de la fonctionnalité checksum donc si tu as une trame en erreur, elle sera détectée par les niveaux inférieurs.

Mettre les IP (et le header) dans le checksum, mauvaise idée. Si tu passes par de la translation d'adresse (NAT) par exemple, il faudra recalculer ton checksum avec les nouvelles adresses.

Donc un checksum, si tu veux mais uniquement sur les données applicatives mais je suis prêt à parier que tu ne verras jamais d'erreur de checksum dans ces données, elles seront interceptées avant par IP et/ou UDP.

[Emmanuel Delahaye]

Désolé, je n'avais pas bien compris.
Au sujet de la taille, y'a-t-il une raison particuliere pour 16ko, ou est-ce juste un exemple?

Juste un exemple.

Et si les données n'atteignent pas la taille MAX, dois-je "bourrer" manuellement la trame?

Si il fallait 'bourrer', à quoi ça servirait de passer la longueur ?

Et désolé d'insister, mais pourquoi le checksum à la fin? J'aurais plutot penser le mettre avant les donnees.

Disons qu'il est difficile de remonter dans le temps...

Et pour le checksum, je ne sais pas si je dois inclure les IP(source+dest) pour le calcul de ce dernier.

On est au-dessus de l'UDP là. Ce qui se passe en-dessous ne nous intéresse pas. Tu ne sais pas ce qu'est l'organisation en couche des protocoles .

Désolé si je pose des questions un peu bêtes ou redondantes.

On dirait que tu n'as pas lu tes cours sur les réseaux...

[wiztricks]

Au sujet de la taille, y'a-t-il une raison particuliere pour 16ko, ou est-ce juste un exemple?

C'est un exemple.
Vous êtes en sandwich avec réseau et couche applicative. Il vous faut décider ce que sera la taille maximale:

• des messages transportés,
• des trames échangées.

Et si les données n'atteignent pas la taille MAX, dois-je "bourrer" manuellment la trame?

Tant que vous n'arrivez pas côté conceptuel à séparer le haut du bas et le droit du gauche, vous allez dans le mur.

Regarder tout le petit monde que cela concerne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
           { emission } ------------------> { reception }
                                     (1)
                n+1    <--- messages ----> n+1
           (2)   |                                   |  (4)
                  n     <---   trames   ----> n
                                   (3)

transmettre un message "trop" gros en une suite de "trame" de décompose en opérations de

• fragmentation (2) côté émission
• ré-assemblage (3) côté réception.

Ce sont des fonctionnalités offertes entre n+1 et n pour assurer le transfert de messages (1).

Et pour que çà fonctionne, il faudra soit numéroter les fragments soit que la couche au dessous soit suffisamment fiable.

Le numéro des trames est une information échangée entre chaque extrémité de la couche n. Côté réception, il faut prédire le numéro de paquet à venir pour statuer s'il est en séquence ou s'il faut s'inquiéter de sa perte ou de la duplication.

La fonction "suivant" définie par suivant(n) : n + 1 modulo N est simple.
Elle ne dépend que du numéro de la dernière trame reçue (en séquence et correctement).

Ce qui rend cette fonction satisfaisante est quelle présente les attraits d'une fonction monotone croissante...
Mais comme les paquets transportés par un réseau ont une durée de vie assez limitée: inutile de donner un numéro unique à toutes les trames.

L'opération modulo recycle les numéros... Pleins de trames seront numérotés 0 ou 1 mais N sera suffisament "grand" pour que la probabilité de recevoir à l'instant t, deux trames avec un même numéro soit très réduite.

Note: Réduire la probabilité impose N grand, mais au plus N est grand au plus il faudra de bits pour coder cette information. Les compromis ne sont pas les mêmes pour recycler des numéros de trames, des adresses Ethernet, des numéros de plaque minéralogiques.

L'autre aspect est que la taille des trames sera au plus égale à T.
Qu'importe les justifications de ce T, transporter des messages d'une longueur M > T signifie utiliser M/T trames....
Et l'ajout et la gestion des informations correspondante pour ce faire. Parmi celles-ci, il y a numéroter les fragments.

Le calcul du numéro de fragment suivant et similaire à celui du numéro de trame suivante... un fonction de la forme n+1 modulo(...)

Avec des bizarreries:
- fragment.suivant(0) = 0 si M <- T
- fragment.suivant(n) = 0 si N * T > M ; n + 1 modulo(n), sinon

Si nous expédions une suite de messages de taille < T, fragment.suivant sera égal à 0 et impossible dans ce cas de savoir si une des trames à été dupliquée, perdue...

Donc techniquement, çà ne peut pas fonctionner et il faut gérer indépendamment la numérotation des fragments et celle des trames .

Question à laquelle vous n'avez pas répondu: ok pour détecter les problèmes de transmission mais que présager vous de faire dans ce cas?
=> s'il n'y a rien à faire, inutile de multiplier les informations...
=> si vous souhaitez "fiabiliser" avec des ré-missions, etc... Mais dans ce cas est ce qu'UDP reste un bon choix?

Et désolé d'insister, mais pourquoi le checksum à la fin? J'aurais plutot penser le mettre avant les donnees.

Dans le monde réseau, les données sont échangées en série...
Les "unités de traitement" voient défiler les informations en fonction du temps un peu comme si elles étaient sur un ruban.

Pour calculer un checksum, il faut déterminer le début de la trame pour l'initialiser et sa valeur est mise à jour au passage des informations.
La valeur calculée sur les données reçues ne pourra être comparée qu'après avoir détecté le passage de la fin du paquet.

Le placement "optimal" de l'information de référence est sera plutôt à la fin.
Les critères pour "optimal" renvoie au défilement des informations sur un ruban: début = ancien => mémoriser l'information "longtemps" avant de l'utiliser.
Ca coûte de la mémoire.

Vous vous rendez compte que nous avons fait un saut quantique: nous ne sommes plus dans les échanges de messages ou de trames mais dans le traitement des bits/bytes correspondants.

=> Vous n'êtes absolument pas dans ce cas là, peut importe ou vous mettrez le checksum vous lirez/recevrez un "paquet" d'octets sans possibilité d'aller plus bas.

Note: IP, la couche utilisée par UDP fait déjà cela pour vous: sauf bug dans le codage de votre checksum, vous ne verrez jamais de packets en erreur.

Et pour le checksum, je ne sais pas si je dois inclure les IP(source+dest) pour le calcul de ce dernier.

La fonction du checksum est de vous permettre de statuer sur l'intégrité des données reçues. Ce doit être une fonction de ces données.

Qu'apporte la dépendance des adresses IP dans ce calcul?
En général, faire dépendre ce calcul d'autres informations que les données reçues/transmises demande à assurer de la cohérence de celles-ci de chaque côté.

=> Nous sommes dans le même piège que numéro de séquence et fragmentation.... Pour en sortir, la règle est de faire en sorte que chaque niveau protocolaire puisque être "auto-suffisant" dans les échanges avec son pair (l'entité correspondante de "l'autre côté").

Dit autrement, réduire les dépendances qui ne concernent pas le service à rendre en collaboration avec le pair.

-W