Lecture TCP d'un bloc supérieur à la MTU

Version imprimable

16/12/2013, 09h10
schub1015

Lecture TCP d'un bloc supérieur à la MTU

Bonjour,

J'aimerais via une liaison TCP lire des trames dont la longueur n'est pas fixe et qui peuvent atteindre environ 8ko.
Cependant, du fait de la MTU (réglée à 1460 octets), la réception ne peut pas être faite en une seule fois.
Je ne sais pas comment reconstituer la trame complète sachant que je ne sais pas par avance, la taille de celle-ci.

Je vous remercie pour votre aide.
16/12/2013, 17h15
tomlev

Qu'est-ce que tu utilises pour gérer la communication ? Socket, TcpClient ? Montre ton code.

Normalement c'est complètement transparent... tu lis un "flux réseau" qui te permet de faire abstraction du fonctionnement sous-jacent. Tu ne devrais pas avoir à te préoccuper de la MTU.

Merci pour votre réponse.

J'utilise un networkstream d'un TCPClient threadé avec une bouche infini.

J'ai essayé plusieurs solutions mais voici mon dernier code :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
  while (run == true)
  {
       if (suspend == false)
       {
             try
             {
                  if (_driver.TcpClient.Connected)
                  {
                       ns = new NetworkStream(_driver.TcpClient.Client);
                       if (ns != null)
                       {
                          byte[] tabBytes = new byte[8000]; 
                          nbBytes = 0;
                          int nbDonneesTab = 0;
                          if ((nbDonneesTab = await ns.ReadAsync(buffer, 0, buffer.Length)) > 0)
                                  Console.WriteLine(DateTime.Now + "." + DateTime.Now.Millisecond + " : Reception donnees stream  data ok : " + nbDonneesTab);
                       }
                   }
               }
        }
}

J'ai en réception des trames de 8000 octets
Voici les logs correspondants :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
17/12/2013 08:18:08.628 : Reception donnees stream  data ok : 1460
17/12/2013 08:18:08.628 : Reception donnees stream  data ok : 1460
17/12/2013 08:18:08.629 : Reception donnees stream  data ok : 1460
17/12/2013 08:18:08.630 : Reception donnees stream  data ok : 1460
17/12/2013 08:18:08.630 : Reception donnees stream  data ok : 1460
17/12/2013 08:18:08.635 : Reception donnees stream  data ok : 700
 
17/12/2013 08:18:08.718 : Reception donnees stream  data ok : 1460
17/12/2013 08:18:08.718 : Reception donnees stream  data ok : 1460
17/12/2013 08:18:08.719 : Reception donnees stream  data ok : 1460
17/12/2013 08:18:08.719 : Reception donnees stream  data ok : 1460
17/12/2013 08:18:08.720 : Reception donnees stream  data ok : 1460
17/12/2013 08:18:08.721 : Reception donnees stream  data ok : 700
 
17/12/2013 08:18:08.808 : Reception donnees stream  data ok : 1460
17/12/2013 08:18:08.808 : Reception donnees stream  data ok : 1460
17/12/2013 08:18:08.809 : Reception donnees stream  data ok : 1460
17/12/2013 08:18:08.809 : Reception donnees stream  data ok : 1460
17/12/2013 08:18:08.810 : Reception donnees stream  data ok : 1460
17/12/2013 08:18:08.811 : Reception donnees stream  data ok : 700

La MTU est réglée comme par défaut c'est-à-dire 1460 octets.
On voit bien que la MTU bloque les trames à une taille maxi de 1460o.

Avez-vous une idée comment je peux avoir ma trame de 8000 octets en un seul buffer. En sachant que je ne connais pas cette taille normalement, les trames pouvant faire jusqu'à 16ko.

Pour info complémentaires, je suis sous VS2012 en Windows 7.
Je vous remercie pour vos réponses

17/12/2013, 13h48
tomlev

Mais si tu ne sais pas à l'avance quelle est la taille de la trame à recevoir, comment tu peux savoir où t'arrêter ? C'est une connexion permanente sur laquelle tu reçois régulièrement des trames ? Si oui, il faut forcément un moyen pour marquer la fin d'une trame, ou alors connaitre sa longueur...
17/12/2013, 14h30
schub1015

Dans le cas où la trame fait moins de 1460 octets, cela fonctionne très bien.

Le problème lorsque c'est supérieur à 1460o, c'est que je ne sais pas lorsque ma trame originale envoyée est terminée.
17/12/2013, 14h40
tomlev

Citation:

Envoyé par schub1015

Dans le cas où la trame fait moins de 1460 octets, cela fonctionne très bien.

Le problème lorsque c'est supérieur à 1460o, c'est que je ne sais pas lorsque ma trame originale envoyée est terminée.

Bah de toutes façons NetworkStream.Read ne pourra jamais lire plus que le MTU en un seul coup, si tu attends des trames plus longues c'est à toi d'appeler Read en boucle jusqu'à ce que tu aies reçu toutes les données que tu attendais.

S'il n'y a pas de moyen de savoir quand la trame se termine, il n'y a pas de solution, car quand il n'y aura plus de données dispo sur le flux, tu ne pourras pas savoir si c'est parce que tu es au bout de la trame, ou parce que le reste des données n'est pas encore arrivé... Dans ce cas c'est le protocole d'échange qui est à revoir.

Tu es sûr qu'il n'y a pas quelque chose qui t'indique la taille de la trame, ou alors peut-être une séquence qui indique sa fin ?
17/12/2013, 14h43
tomlev

A la rigueur, dans ta boucle tu peux tester _driver.TcpClient.Client.Available pour voir s'il y a encore des données dispo sur le flux, et continuer à boucler tant que c'est le cas.

Mais ce n'est pas très fiable, parce que :
- il est possible que la trame ne soit pas encore entièrement arrivée, et dans ce cas Available renverra 0, bien que tu doives encore recevoir des données pour cette trame
- si la trame suivante arrive aussitôt après, tu ne peux pas savoir où s'arrête la première et où commence la suivante
18/12/2013, 14h00
schub1015

Merci.

Il n'y a d'autres solutions à part utiliser un networkstream ?
Une solution qui permettrait de résoudre mon souci...

Merci pour vos réponses.
18/12/2013, 14h11
tomlev

Citation:

Envoyé par schub1015

Il n'y a d'autres solutions à part utiliser un networkstream ?
Une solution qui permettrait de résoudre mon souci...

Le problème n'est pas lié au NetworkStream, il est lié au fonctionnement du réseau... Quand tu envoies 8000 octets, tu ne peux pas garantir qu'ils vont tous arriver en même temps, donc quand tu en reçois une partie, il te faut un moyen de savoir s'il reste encore des données à recevoir.
18/12/2013, 14h27
ram-0000
Sur un flux TCP tu ne sais JAMAIS le nombre de send et de recv qui vont être faits ou nécessaires.

Si tu as 1000 octets à envoyer, tu vas appeler 1 seule fois la fonction send() (ou équivalent) pour 1000 octets, le noyau va peut être transformer ce send en 2 paquets de 400 et 600 octets

et à l'autre bout, il faudra peut être le recevoir en 3 paquets de 300, 300 et 400 octets (3 appels à la fonction recv() ou équivalent).

Donc dans un flux TCP, il te faut un repère pour connaitre la fin de ton PDU applicatif. Ce peut être :
- La longueur du PDU envoyé en tête de PDU :arrow: beaucoup de protocoles font cela (par exemple X11)
- Un caractère spécial en fin de PDU (attention, ce caractère spécial ne doit JAMAIS être utilisé par le PDU) :arrow: souvent utilisé par les protocoles "texte" (SMTP, HTTP, FTP)
- Des PDU de taille fixe et connue à l'avance :arrow: je n'ai pas d'exemple en tête
Dans tout cela, le MTU n'est pas ton problème, c'est le problème des routeurs intermédiaires et de la stack IP de la dernière machine (pour réassembler). Jamais un problème utilisateur.