Discussion :

[coyotte507]

Bonjour,

sachant que j'ai des paquets à envoyer,

est-ce que ça pose un problème si j'envoie un paquet de quelques kilo-octets d'un coup, ou vaut-il mieux fragmenter?

Y'a-t-il un inconvénient à ne pas fragmenter l'envoi?

J'ai la même question pour la réception

Si je ne suis pas clair dites-le.

Merci!

[nouknouk]

est-ce que ça pose un problème si j'envoie un paquet de quelques kilo-octets d'un coup, ou vaut-il mieux fragmenter?

Salut,

Pour l'émission: Les couches réseau successives s'occupent toutes seules de fragmenter elle-même les paquets pour qu'ils puissent traverser le réseau comme il faut. en effet, pour une même salve de paquets, et suivant le 'chemin' du réseau qu'elle empruntera, la fragmentation ne sera pas effectuée de la même manière, en fonction des capacités de chaque noeud du réseau, de leur congestion, ...

L'opération inverse est également parfois effectuée: si tu envoies plusieurs paquets de quelques octets à la suite, la pile TCP pourra très bien les réassembler elle-même pour éviter d'avoir trop de surcharge par des données 'non utiles' (cf algorithme de Nagle)

Il est donc plus que recommandé de laisser les couches réseaux faire leur petite sauce dans leur coin et de ne pas s'en préoccuper. Envoie donc tout d'un coup pour leur laisser l'opportunité d'optimiser au mieux.


Pour la réception, tu ne choisis pas la fragmentation puisque c'est la façon dont l'émetteur aura envoyé ses données qui conditionnera la réception (en admettant que les noeuds intermédiaires n'aient rien sous-fragmenté / regroupé, ce qui reste purement théorique)

La seule chose à surveiller est la taille du buffer interne à ta socket. En fonction de lui, il faut se débrouiller pour éviter qu'à tout moment celui-ci ne soit complètement rempli et ainsi ne pas perdre de données en cours de route. Pour cela, rien de bien incroyable à implémenter: toujours s'assurer que lorsque ton applicatif reçoit une notification qu'il a reçu de nouvelles données sur la socket, il ne mettre pas trois plombes à lire la totalité des données disponibles (quitte à lui même les stocker dans son propre buffer en attendant de les traiter).

A ne pas oublier: Lorsqu'on débute avec TCP, on voit que TCP garantit l'ordre de réception des données, leur 'non-perte' et leur intégrité. On a souvent tendance à comprendre implicitement que leur fragmentation est également préservée, ce qui n'est pas le cas. Par exemple, lorsqu'un émetteur envoie les données ABC puis DEF puis GHI, le récepteur peut:
- recevoir effectivement ABC puis DEF puis GHI
- recevoir tout en une seule fois ABCDEFGHI
- recevoir A puis BCDEFG puis HI
- recevoir A puis B puis C puis DEFGHI
- etc...

En conséquence, c'est à l'applicatif de gérer ces différents cas de figure de d'implémenter son propre mécanisme de framentation du flux de données. Par exemple, si ton flux fonctionne sur un système de messages de tailles variable (un message ne pouvant être traité que lorsque l'intégralité de celui-ci est reçue), il te faudra:

- ajouter à chaque début de message un 'champ d'en-tête - ou header en Anglais' (genre un entier sur 4 octets) pour indiquer la taille en octet su message lui-même.

- à chaque fois que le récepteur reçoit des données de la socket, il les stocke dans son buffer applicatif.

- lorsque le buffer contient au moins l'en-tête (les 4 octets), il peut déterminer la taille du prochain message

- lorsque le buffer contient au moins la taille de la totalité du message, il peut extraire celui-ci et le traiter.

[coyotte507]

Merci beaucoup,

je n'en demandais pas tant