J'ai un petit programme de test qui envoie beaucoup de paquets UDP entre client-> Server-> Client (test Ping / Pong). Les paquets sont des formes fixes à chaque exécution (la dernière exécution est une taille maximale autorisée de paquet UDP) Je remplisse les paquets avec des données aléatoires, à l'exception du début de chaque paquet contenant le numéro de paquet. Je ne suis donc intéressé que si je reçois tous les paquets au client.
J'utilise SendTo () et RECVFROM () et je ne lis que la taille de (Packet_Number) (qui est dans ce cas une int). Qu'advient-il du reste des données? Cela se retrouve-t-il à Fairyland (se fait défoncer)? Ou le nouveau paquet qui arrive est-il annexé à cette "vieille" données?
(à l'aide de Linux)
3 Réponses :
Je n'ai pas testé cela, mais de mon interprétation de la page man, Il y a deux façons de détecter la troncature:
Utilisez le drapeau Utiliser Pour éviter la contraction, utilisez un tampon 64K. Les packages UDP ne peuvent pas être plus gros que cela (champ de longueur de 16 bits dans le protocole). msg_trunc RECVFROM retournera ensuite la taille réelle de l'emballage, même s'il ne correspondait pas au tampon fourni. Vous pouvez donc simplement vérifier si la valeur de retour est plus grande que le len que vous avez donné comme argument.
recvmsg et vérifier la structure renvoyée pour le drapeau msg_trunc
Chaque lecture de la prise UDP DE-QUESUES Un Datagramme entier OFF BERNELLE SOCKET DE RECEVOIR BUFFE SOIITE N'importe quelle taille de tampon de zone utilisateur. C'est:
J'espère que cela aide.
msg_trunc , donc RECV (2) retournera toute la longueur de datagramme, pas seulement la partie que vous avez lu dans votre tampon Userland.
Pour répondre à votre première question, les données ne se mis au rebut?
Oui. Les protocoles IP et ARP entrent en jeu lorsque votre paquet est plus grand que le MTU de chemin. Le MTU Path est l'unité de transmission maximale du chemin entre votre client et le serveur. En supposant que votre carte réseau est une carte Ethernet standard, votre MTU maximale est 1500. Maintenant, laisse supposer que le MTU entier chemin entre votre client et le serveur est 1500. Dans ce scénario, si vous envoyez tout paquet qui est supérieure à 1472 octets (1500 - (en-tête 20 octet ip) - (en-tête UDP 8 octets)) puis la fragmentation IP se produira. Ce qui sera alors arriver est que la couche IP coupera le paquet en fragments pour répondre à la MTU de la liaison Ethernet. Maintenant, avant que les données peuvent être envoyées, l'adresse MAC des besoins de destination à résoudre. Donc, tout d'un coup, le protocole ARP recevra des fragments IP multiples demandant la même adresse IP à la résolution d'adresse MAC. Qu'est-ce qui alors arriver est que ARP lancera une requête ARP pour la première paquet reçu et attendre la réponse ARP. En attendant, ARP annulera tous les fragments la même requête ARP et la file d'attente que le dernier fragment est arrivé. Par conséquent, si vous envoyez plus de paquets que 1472 octets, ne vous attendez pas à recevoir tout le paquet à l'autre bout si votre cache ARP est vide.
Le paquet nouvellement arrivé get ajouté à
Non, ce ne soit pas ajouté. UDP est un protocole de datagramme avec des limites strictes de message. Par conséquent, chaque paquet arrivant est considéré comme un datagrammes autonome complet; les données ne sera pas jointe.
La question n'a rien à voir avec le MTU - c'est entièrement à propos de l'API des sockets (et l'effet de faire une lecture courte).
@CAF - Si vous relisez la question, il indique que: (la dernière exécution est une taille maximale admissible du paquet UDP), ce qui signifie que la longueur est définie sur la taille de paquets maximale "théorique" de l'UDP. Veuillez lire Richard Stevens Book, TCP / IP illustré: les protocoles. Section 11.9 - L'interaction entre UDP et ARP. Vous comprendriez pourquoi j'ai mentionné MTU et ARP.
Correction pour la postérité: la réponse ci-dessus est embrouillée. ARP ne traite pas des fragments IP. Il est vrai que ARP est utilisé pour trouver l'adresse MAC du prochain saut (s'il s'agit d'un datagramme unicast). Mais ARP est un protocole totalement séparé. Aucun de la Datagramme IP ne sera envoyé jusqu'à ce que l'adresse MAC de destination soit connue (ARP d'abord, puis IP). Il pourrait être abandonné si l'ARP prend trop de temps depuis que UDP n'est pas fiable. Mais alors tout le temps serait tombé. Le récepteur ne reçoit pas de fragments qui le conduiraient à déposer également tout le datagramme, mais ce n'est pas une conséquence de l'ARP.