J'ai écrit une application C ++ (en cours d'exécution sur Linux) qui sert un flux RTP d'environ 400 Kbps. Pour la plupart des destinations, cela fonctionne bien, mais une perte de paquets d'expérimentation des destinations. Les destinations problématiques semblent avoir une connexion plus lente en commun, mais elle devrait être suffisamment rapide pour le flux que j'envoie.
Étant donné que ces destinations sont capables de recevoir des flux RTP similaires pour d'autres applications sans perte de paquets, ma demande pourrait être en défaut.
J'ai déjà vérifié quelques éléments: - Dans un Tcpdump, je vois tous les paquets RTP sur la machine d'envoi - Il y a un tampon d'envoi UDP en place (j'ai essayé des tailles entre 64kb et 300kb) - Les paquets RTP restent surtout en dessous de 1400 octets pour éviter la fragmentation
Que peut une application d'envoi pour minimiser la possibilité de perte de paquets et quelle serait la meilleure façon de déboguer une telle situation?
5 Réponses :
Ce n'est peut-être pas la réponse que vous voulez, mais si j'avais des problèmes de perte de paquets, j'essaierais de changer de demande pour utiliser TCP et que la perte de paquets est la plus préoccupante de mon esprit.
Une grande partie du point de RTP est de tirer parti de la sémantique UDP; en particulier permettant des paquets perdus sans calmer le reste du flux.
Oups! Mon mauvais pour être ignorant de RTP. Je vais aller lire là-dessus maintenant. Merci pour l'information!
Vous devriez essayer de réduire le taux que vous envoyez des paquets. Une connexion lente peut signifier toutes sortes de choses, et essayer d'envoyer des paquets informatiques (petit ou grand) à un taux élevé ne vous aidera pas.
NetStat a plusieurs options utiles pour déboguer la situation.
premier est NetStat -su (Dump UDP Statistiques): P>
dima@linux-z8mw:/media> netstat -ua Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State udp 0 0 *:bootpc *:* udp 0 0 *:40134 *:* udp 0 0 *:737 *:* udp 0 0 *:mdns *:*
Quelques bons conseils ici, mais je ne suis pas sûr qu'il l'aidera. La perte de paquets réelle se produit probablement sur un routeur ISP où il ne peut pas voir les statistiques.
En effet, je ne vois aucune perte de paquets avec NetStat sur l'envoi de la machine. Malheureusement, le chemin de la destination implique beaucoup d'équipement de réseau que je ne peux pas accéder directement.
La sortie MTR semble très intéressante, mais elle ne semble pas déclencher la même perte de paquets que mon application.
N'envoyez pas de paquets dans de gros morceaux de mer.
La perte de paquets est généralement causée par des routeurs lents avec des tailles tampons de paquets limitées. Le routeur lent peut être capable de gérer 1 Mbps très bien s'il a le temps d'envoyer, 10 paquets avant de recevoir 10 encore 10, mais si le côté de l'expéditeur de 100 Mbps l'envoie un gros morceau de 50 paquets, il n'a pas d'autre choix que de tomber 40 d'entre eux.
Essayez de diffuser l'envoi de sorte que vous n'écrivez que ce qui est nécessaire pour écrire à chaque période. Si vous devez écrire un paquet tous les cinquième d'une seconde, faites-le ainsi au lieu d'écrire 5 paquets par seconde.
RTP utilise généralement UDP , qui est intrinsèquement pertinent. Les paquets pourraient être perdus n'importe où entre l'expéditeur et le récepteur, donc le débogage local ne vous montrera rien d'utile.
choses évidentes à faire:
Si tout échoue, Wireshark est votre ami. Cela vous donnera une image réelle de la quantité de données - et quand elle est envoyée par votre application.
Un très petit tampon UDP n'enverrait-il pas que les paquets sont automatiquement perdus sur la machine d'envoi dès que le moindre retard est-il?
@Gene - c'est très peu probable. Bien que UDP ne garantit pas que les paquets reçoivent, il devrait certainement garantir que le paquet est «envoyé» sous une forme. Et si cela n'a pas été envoyé, NetStat vous montrerait que, je pense. [Lorsque vous dites "tampon UDP", qu'est-ce que vous voulez dire? Je pensais que UDP n'était généralement pas tamponné ...?]
Chaque prise (et ceci s'applique également aux sockets UDP) a un tampon d'envoi où les données sont stockées jusqu'à ce que la pile réseau l'envoie. L'application peut influencer la taille de ce tampon avec setsockopt (SO_SNDBUF). Lorsque le tampon est complet, le bloc de routines TCP et UDP est supprimé.
@Gene, selon W.Richard Stevens, le tampon d'envoi UDP ne détermine que la taille maximale du datagramme pouvant être envoyée. Il ne tamponne pas plusieurs datagrammes.
Il n'y a pas de restriction de taille pour un datagramme ... cela peut être aussi grand que 1 Mo. Il sera divisé en taille de paquets, puis manipulée.