Citation:
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.
Citation:
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:
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?
Citation:
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.
Citation:
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
