UDP broadcast/multicast vs unicast comportement (perte de paquets)

J'ai un appareil embarqué (source) qui est l'envoi d'un flux d' (audio) données par blocs de 20 ms (= environ 330 octets) par le biais d'un des paquets UDP. Le réseau volume est donc assez faible, environ 16kBps (pratiquement un peu plus à cause de l'UDP/IP généraux). L'appareil est en cours d'exécution de la lwIP pile (v1.3.2) et se connecte à un réseau WiFi à l'aide d'une solution WiFi de chez H&D sans Fil (HDG104, WiFi G-mode). La destination (évier) est un ordinateur Windows Vista qui est également connecté au réseau WiFi à l'aide d'un dongle USB WiFi (WiFi G-mode). Un programme est en cours d'exécution sur le PC qui me permet de surveiller la quantité de perte de paquets. Je suis également en cours d'exécution Wireshark pour analyser le trafic réseau directement. Pas d'autres clients sont activement l'envoi de données sur le réseau à ce point.

Quand j'envoie les données à l'aide de diffusion ou de multidiffusion de nombreux paquets sont perdus, parfois jusqu'à 15%. Cependant, lorsque je passe à l'aide du protocole UDP unicast, la quantité de paquets perdus est négligeable (< 2%).

Utilisation d'UDP-je m'attendre à des paquets d'être abandonné (qui est OK dans mon application Audio), mais pourquoi dois-je voir une grosse différence de performance entre les Broadcast/Multicast et unicast?

Mon routeur est un WRT54GS (FW v7.50.2) et le PC (évier) est à l'aide d'une trendnet TEW-648UB carte réseau, fonctionnant en WiFi G-mode.

InformationsquelleAutor djbuijs | 2013-06-24
  1. 9

    Cela ressemble, c'est un effet bien connu de problème WiFi:

    Cité de http://www.wi-fiplanet.com/tutorials/article.php/3433451

    La norme 802.11 (Wi-Fi) les normes de spécifier la prise en charge de la multidiffusion dans le cadre des services asynchrones. Un 802.11 poste client, tel qu'un ordinateur portable sans fil ou un PDA (pas d'un point d'accès), le début d'une multidiffusion de livraison en envoyant des paquets de multidiffusion 802.11 unicast trames de données adressées à seulement le point d'accès. Le point d'accès répond avec un 802.11 accusé de réception de la trame envoyée à la station source si aucune erreur n'est trouvée dans le bloc de données.

    Si le client l'envoi de l'image ne marche pas recevoir un accusé de réception, le client va retransmettre la trame. Avec la multidiffusion, la jambe du chemin de données entre le client sans fil au point d'accès comprend la transmission de récupération d'erreur. La norme 802.11 protocoles de s'assurer de la fiabilité entre les stations à la fois de l'infrastructure et ad hoc configurations lors de l'utilisation de monodiffusion la transmission des trames de données.

    Après la réception de la monodiffusion trame de données de la part du client, le point d'accès transmet les données (que le client d'origine veut multicast) que de multidiffusion à l'image, qui contient une adresse de groupe en tant que destination pour les destinataires. Chaque de la destination des stations peut recevoir l'image; cependant, ils ne répondent pas dans les remerciements. En conséquence, la multidiffusion de ne pas assurer l'exhaustivité, la fiabilité des flux de données.

    L'absence des accusés de réception avec la multidiffusion signifie que certaines des données que votre application est l'envoi ne peut pas le faire pour toutes les destinations, et theres aucun signe d'une réception réussie. C'est peut-être bien, même si, pour certaines applications, en particulier celles où son ok pour avoir des lacunes dans les données. Par exemple, la permanence du streaming de télémétrie à partir d'une valve de contrôle du moniteur peut probablement manquer le statut des mises à jour de temps en temps.

    Cet article a plus d'informations:
    http://hal.archives-ouvertes.fr/docs/00/08/44/57/PDF/RR-5947.pdf

    Une très intéressante des effets secondaires de la multidiffusion de mise en œuvre (au WiFi couche MAC) est que, tant que vos récepteurs sont branchés, vous ne rencontrez pas tous les problèmes (en raison de l'accusé de réception sur le côté du récepteur, qui est vraiment une connexion de monodiffusion). Cependant, avec le WiFi récepteurs (comme dans mon cas), la perte de paquets est énorme et totalement inacceptable pour l'audio.

    InformationsquelleAutor djbuijs
  2. 1

    De multidiffusion n'a pas de paquets d'accusé de réception et il n'y a pas de retransmission des paquets perdus. Cela prend tout son sens car il existe de nombreux récepteurs et c'est pas comme si ils peuvent tous répondre à la même époque (l'air est partagé comme coaxial Ethernet). Si ils étaient tous d'envoyer des accusés de réception dans la séquence à l'aide de certains d'interruption régime il mange toute votre bande passante.

    De diffusion UDP avec la perte de paquets est un défi et est généralement résolu en utilisant un certain type de correction des erreurs avant. Récemment, une classe connue sous le nom de fontaine des codes, comme le Raptor-Q, prometteur pour la perte de paquets problème, en particulier lorsqu'il y a plusieurs sources peu fiables pour les données en même temps. (exemple: plusieurs points d'accès wifi couvrant une zone)

    • Merci pour l'ajout, c'est très intéressant. Nous avons considéré la correction des erreurs avant mais je n'ai pas regardé Raptor-Q. Un problème, c'est que pour ma demande du permis de latence est < 300ms. La plupart du temps quand il ya un problème, vous bénéficiez d'une chaîne de paquets perdus qui rend la correction d'erreur difficile. La solution pour nous, s'est avéré être plutôt simple: la plupart des professionnels de l'Accès à des Points d'appui, une fonctionnalité de multidiffusion de Monodiffusion traduction. Vous aurez toujours obtenir quelques pertes de paquets, mais pas autant.
    InformationsquelleAutor Bjarne Vinkelhake