Re: [FRnOG] [TECH]Tester la perte de paquets réseaux.
Perso, je prendrais une trace tcpdump côté serveur et côté slave simultanément. Ensuite, tu les fusionnes, et tu utilises le comparateur de wireshark pour voir s’il y a des anomalies. Ceci dit, comme cela a déjà été dit, UDP sans ack sans flag et sans Seq comme RTP, c’est un peu foufou. Pourquoi de l’UDP d’ailleurs ? Ca serait pas plus propre que les slave établissent une connexion TCP (avec keepalive) vers un petit daemon sur le serveur, qui sait ainsi quel slave est connecté ? Le 9 nov. 2014 à 13:43, Eugène Ngontang a écrit : > Bonjour la liste. > > J'ai un petit problème, beaucoup plus d'ordre stratégique que technique, > mais j'aimerais avoir vos suggestions d'experts. > > En effet nous avons mis en place des systèmes sous Linux pour un client, > avec un concept de synchronisation où l'on a un poste master, et deux > slaves, le tout forme un groupe de synchronisation. > Chacun des équipements est équipé d'un serveur X, pour la diffusion de > contenus sur des écrans géants. Sur le principe, à des instants précis le > master envoie des paquets de synchro en UDP pour qu'ils affichent en même > temps (tous les trois ou tous les deux s'il n'a envoyé qu'à un seul slave. > > Bien le client constate des problèmes de synchro sur le terrain dans les > groupes de synchro, et je suis appelé à prouver qu'il y a des pertes de > paquets sur le réseau du clients. > Les systèmes sont tous sur le même réseau local. > > ALors avec un *tcpdump* je ne peux rien voir d'important dans ce que je > chercher vu que c'est de l'UDP, et les paquets que je capture n'ont aucun > flag indicatif. > > J'ai utilisé *iperf* pour envoyé des paquet en udp depuis le master au > slave à *10Mb/s* pendant *10 secondes*, et je n'ai vu aucune perte de > paquets. > > J'envisage donc de planifier le test sur une plus longue période, et à des > instants précis, où l'on est susceptible d'avoir de la désynchro. > > Vous, comment vous planifieriez un tel test? > Et aussi vu que les machines sont sur le même LAN, est-ce pertinent de > pencher sur une perte de paquets? > Quels éléments réuniriez-vous pour une telle analyse? > > Merci beaucoup pour votre attention et votre aide. > > Cordialement, > Eugène NG > > -- > ngont...@epitech.net > sympav...@gmail.com > > *Aux hommes il faut un chef, et au* > > * chef il faut des hommes!L'habit ne fait pas le moine, mais lorsqu'on te > voit on te juge!* > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE:[FRnOG] [TECH]Tester la perte de paquets réseaux.
Bonjour, selon la nature des switches, le broadcast local (255.255.255.255) peut être limité (ControlPlane policy) car considéré comme un DDOS. et comme l'on fait remarqué certain, UDP ne garantie rien, et de plus sur un réseau Ethernet non garantie. => il faut : - RTP et RTCP pour géré les retransmissions et les controle de flux - mettre de la QOS pour garantir un minimum (jitter et latence) et surtout, on ne met jamais 2 équipements de diffusion vidéo (type streaming) cote à cote pour comparer , car il y aura toujours une différence dans la diffusion.. (on dépend de chaque composant , exemple: composant éléctronique,..) Thierry Thierry Martin Senior Engineer Expert Dimension Data France Tel: +33 1 4975 8852 Mob: +33 6 6023 6611 Fax: +33 1 4975 8629 thierry.mar...@dimensiondata.com Zone Orlytech - 20 avenue Louis Blériot (adresse postale 91781 Wissous Cedex), Paray Vieille Poste, 91550, France. Dimension Data is an NTT Group company. For further information about Dimension Data, please go to www.dimensiondata.com<http://www.dimensiondata.com/> Follow us on Social Media Blog<http://blog.dimensiondata.com> Facebook<http://www.facebook.com/pages/Dimension-Data-Europe/208242309194429> LinkedIn<http://www.linkedin.com/company/dimension-data> Twitter<http://twitter.com/DimensionData> P please consider the environment before printing this email [cid:488f8e.png@22364fc5.498ec296][cid:image8fdb15.PNG@261a1359.4ca6eaa1] De : frnog-requ...@frnog.org [frnog-requ...@frnog.org] de la part de Paul Rolland (ポール・ロラン) [rol+fr...@witbe.net] Envoyé : dimanche 9 novembre 2014 15:40 À : frnog@frnog.org Objet : Re: [FRnOG] [TECH]Tester la perte de paquets réseaux. Bonjour, On Sun, 9 Nov 2014 15:18:43 +0100 Eugène Ngontang wrote: > bon choix. Après j'ai pu voir que les paquets sont envoyer à l'adresse > 255.255.255.255 sur le port 2325. Ils ont peut-être plus tabler sur la > diffusion que la synchro. Ton traffic est envoye vers cette adresse ??? Il serait peut-etre utile de regarder dans ce cas ce que disent les switchs qui sont supposes faire passer ce traffic... Un petit coup de chaud sur les CPU n'est pas a exclure. Paul --- Liste de diffusion du FRnOG http://www.frnog.org/ itevomcid --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH]Tester la perte de paquets réseaux.
Hello, As-tu vérifier qu'il n'y avait pas d'erreur au niveau des interfaces réseaux ? - un /sbin/ifconfig pour les machines - vérifie également au niveau des équipements réseaux (switch/routeur) sur toutes la chaines entre tes 2 machines. Concernant le broadcast, tu peux avoir des protections au niveau des switchs (limiter la diffussion en % d'utilisation de l'interface) ++ Sylvain Le 9 novembre 2014 15:40, Paul Rolland (ポール・ロラン) a écrit : > Bonjour, > > On Sun, 9 Nov 2014 15:18:43 +0100 > Eugène Ngontang wrote: > >> bon choix. Après j'ai pu voir que les paquets sont envoyer à l'adresse >> 255.255.255.255 sur le port 2325. Ils ont peut-être plus tabler sur la >> diffusion que la synchro. > > Ton traffic est envoye vers cette adresse ??? > Il serait peut-etre utile de regarder dans ce cas ce que disent les switchs > qui sont supposes faire passer ce traffic... Un petit coup de chaud sur les > CPU n'est pas a exclure. > > Paul > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH]Tester la perte de paquets réseaux.
Bonjour, On Sun, 9 Nov 2014 15:18:43 +0100 Eugène Ngontang wrote: > bon choix. Après j'ai pu voir que les paquets sont envoyer à l'adresse > 255.255.255.255 sur le port 2325. Ils ont peut-être plus tabler sur la > diffusion que la synchro. Ton traffic est envoye vers cette adresse ??? Il serait peut-etre utile de regarder dans ce cas ce que disent les switchs qui sont supposes faire passer ce traffic... Un petit coup de chaud sur les CPU n'est pas a exclure. Paul --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH]Tester la perte de paquets réseaux.
Bonjour à tous. Merci pour vos réponses. Je tiens à préciser que je ne suis ni le concepteur, ni le développeur du programme réseau. Je connais très bien les différences entre UDP et TCP, et j'ai bien été le premier à faire remarquer que l'UDP était pas forcément un bon choix. Après j'ai pu voir que les paquets sont envoyer à l'adresse 255.255.255.255 sur le port 2325. Ils ont peut-être plus tabler sur la diffusion que la synchro. Toujours est-il que ce pourquoi je suis sollicité c'est l'analyse et la détection de perte de paquets. Le client essaye de faire comprendre que c'est à notre niveau (ce qui serait donc un problème applicatif), ma boîte veut montrer que c'est sur le réseau du client. Moi je suis appelé à le montrer et j'ai des théoriciens au mileu qui ne font que émettre et me transmettre des demandes. Je n'ai pas toutes les billes mais j'essaye de réfléchir avec ma tête avant d'y consacrer du temps. Merci encore de votre aide, mon but est d'être le plus efficace et objectif possible. Cordialement, Eugène NG. Le 9 nov. 2014 14:50, "technicien hahd" a écrit : > On Sunday 09 November 2014 13:43:15 Eugène Ngontang wrote: > > Bonjour la liste. > > > > J'ai un petit problème, beaucoup plus d'ordre stratégique que technique, > > mais j'aimerais avoir vos suggestions d'experts. > > > > En effet nous avons mis en place des systèmes sous Linux pour un client, > > avec un concept de synchronisation où l'on a un poste master, et deux > > slaves, le tout forme un groupe de synchronisation. > > Chacun des équipements est équipé d'un serveur X, pour la diffusion de > > contenus sur des écrans géants. Sur le principe, à des instants précis le > > master envoie des paquets de synchro en UDP pour qu'ils affichent en même > > temps (tous les trois ou tous les deux s'il n'a envoyé qu'à un seul > slave. > > > > Bien le client constate des problèmes de synchro sur le terrain dans les > > groupes de synchro, et je suis appelé à prouver qu'il y a des pertes de > > paquets sur le réseau du clients. > > Les systèmes sont tous sur le même réseau local. > > > > ALors avec un *tcpdump* je ne peux rien voir d'important dans ce que je > > chercher vu que c'est de l'UDP, et les paquets que je capture n'ont aucun > > flag indicatif. > > > > J'ai utilisé *iperf* pour envoyé des paquet en udp depuis le master au > > slave à *10Mb/s* pendant *10 secondes*, et je n'ai vu aucune perte de > > paquets. > > > > J'envisage donc de planifier le test sur une plus longue période, et à > des > > instants précis, où l'on est susceptible d'avoir de la désynchro. > > > > Vous, comment vous planifieriez un tel test? > > Et aussi vu que les machines sont sur le même LAN, est-ce pertinent de > > pencher sur une perte de paquets? > > Quels éléments réuniriez-vous pour une telle analyse? > > > > Merci beaucoup pour votre attention et votre aide. > > > > Cordialement, > > Eugène NG > > Bonjour Eugène, > > Quelques pistes pour toi: > > L'UDP ne garantissant pas ni la livraison des paquets, ni l'ordre des > paquets > ce n'est pas évident, mais heureusement il y a RTP à la rescousse. > RTP offre la possibilité de détecter la perte de paquets, les problème de > latence, les paquets dupliqués et tout ça en utilisant UDP. > > Si il ne s'agit pas d'un réseau dédié à cette application, il peut être > judicieux de monitorer la latence et la montée en charge TCP pour les > problèmes de congestion. > > Si ce n'est déjà le cas, tu peux tester en utilisant mplayer pour voir si > le > problème persiste avec une solution alternative: > http://www.mplayerhq.hu/DOCS/HTML/en/networksync.html > > Un wireshark à chaque extremité au lieu de tcpdump. > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH]Tester la perte de paquets réseaux.
On Sunday 09 November 2014 13:43:15 Eugène Ngontang wrote: > Bonjour la liste. > > J'ai un petit problème, beaucoup plus d'ordre stratégique que technique, > mais j'aimerais avoir vos suggestions d'experts. > > En effet nous avons mis en place des systèmes sous Linux pour un client, > avec un concept de synchronisation où l'on a un poste master, et deux > slaves, le tout forme un groupe de synchronisation. > Chacun des équipements est équipé d'un serveur X, pour la diffusion de > contenus sur des écrans géants. Sur le principe, à des instants précis le > master envoie des paquets de synchro en UDP pour qu'ils affichent en même > temps (tous les trois ou tous les deux s'il n'a envoyé qu'à un seul slave. > > Bien le client constate des problèmes de synchro sur le terrain dans les > groupes de synchro, et je suis appelé à prouver qu'il y a des pertes de > paquets sur le réseau du clients. > Les systèmes sont tous sur le même réseau local. > > ALors avec un *tcpdump* je ne peux rien voir d'important dans ce que je > chercher vu que c'est de l'UDP, et les paquets que je capture n'ont aucun > flag indicatif. > > J'ai utilisé *iperf* pour envoyé des paquet en udp depuis le master au > slave à *10Mb/s* pendant *10 secondes*, et je n'ai vu aucune perte de > paquets. > > J'envisage donc de planifier le test sur une plus longue période, et à des > instants précis, où l'on est susceptible d'avoir de la désynchro. > > Vous, comment vous planifieriez un tel test? > Et aussi vu que les machines sont sur le même LAN, est-ce pertinent de > pencher sur une perte de paquets? > Quels éléments réuniriez-vous pour une telle analyse? > > Merci beaucoup pour votre attention et votre aide. > > Cordialement, > Eugène NG Bonjour Eugène, Quelques pistes pour toi: L'UDP ne garantissant pas ni la livraison des paquets, ni l'ordre des paquets ce n'est pas évident, mais heureusement il y a RTP à la rescousse. RTP offre la possibilité de détecter la perte de paquets, les problème de latence, les paquets dupliqués et tout ça en utilisant UDP. Si il ne s'agit pas d'un réseau dédié à cette application, il peut être judicieux de monitorer la latence et la montée en charge TCP pour les problèmes de congestion. Si ce n'est déjà le cas, tu peux tester en utilisant mplayer pour voir si le problème persiste avec une solution alternative: http://www.mplayerhq.hu/DOCS/HTML/en/networksync.html Un wireshark à chaque extremité au lieu de tcpdump. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH]Tester la perte de paquets réseaux.
Un proto stateless pour de la synchro, superbe idée … Envoyé depuis Windows Mail De : Eugène Ngontang Envoyé : dimanche 9 novembre 2014 13:45 À : frnog@frnog.org Bonjour la liste. J'ai un petit problème, beaucoup plus d'ordre stratégique que technique, mais j'aimerais avoir vos suggestions d'experts. En effet nous avons mis en place des systèmes sous Linux pour un client, avec un concept de synchronisation où l'on a un poste master, et deux slaves, le tout forme un groupe de synchronisation. Chacun des équipements est équipé d'un serveur X, pour la diffusion de contenus sur des écrans géants. Sur le principe, à des instants précis le master envoie des paquets de synchro en UDP pour qu'ils affichent en même temps (tous les trois ou tous les deux s'il n'a envoyé qu'à un seul slave. Bien le client constate des problèmes de synchro sur le terrain dans les groupes de synchro, et je suis appelé à prouver qu'il y a des pertes de paquets sur le réseau du clients. Les systèmes sont tous sur le même réseau local. ALors avec un *tcpdump* je ne peux rien voir d'important dans ce que je chercher vu que c'est de l'UDP, et les paquets que je capture n'ont aucun flag indicatif. J'ai utilisé *iperf* pour envoyé des paquet en udp depuis le master au slave à *10Mb/s* pendant *10 secondes*, et je n'ai vu aucune perte de paquets. J'envisage donc de planifier le test sur une plus longue période, et à des instants précis, où l'on est susceptible d'avoir de la désynchro. Vous, comment vous planifieriez un tel test? Et aussi vu que les machines sont sur le même LAN, est-ce pertinent de pencher sur une perte de paquets? Quels éléments réuniriez-vous pour une telle analyse? Merci beaucoup pour votre attention et votre aide. Cordialement, Eugène NG -- ngont...@epitech.net sympav...@gmail.com *Aux hommes il faut un chef, et au* * chef il faut des hommes!L'habit ne fait pas le moine, mais lorsqu'on te voit on te juge!* --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH]Tester la perte de paquets réseaux.
Bonjour la liste. J'ai un petit problème, beaucoup plus d'ordre stratégique que technique, mais j'aimerais avoir vos suggestions d'experts. En effet nous avons mis en place des systèmes sous Linux pour un client, avec un concept de synchronisation où l'on a un poste master, et deux slaves, le tout forme un groupe de synchronisation. Chacun des équipements est équipé d'un serveur X, pour la diffusion de contenus sur des écrans géants. Sur le principe, à des instants précis le master envoie des paquets de synchro en UDP pour qu'ils affichent en même temps (tous les trois ou tous les deux s'il n'a envoyé qu'à un seul slave. Bien le client constate des problèmes de synchro sur le terrain dans les groupes de synchro, et je suis appelé à prouver qu'il y a des pertes de paquets sur le réseau du clients. Les systèmes sont tous sur le même réseau local. ALors avec un *tcpdump* je ne peux rien voir d'important dans ce que je chercher vu que c'est de l'UDP, et les paquets que je capture n'ont aucun flag indicatif. J'ai utilisé *iperf* pour envoyé des paquet en udp depuis le master au slave à *10Mb/s* pendant *10 secondes*, et je n'ai vu aucune perte de paquets. J'envisage donc de planifier le test sur une plus longue période, et à des instants précis, où l'on est susceptible d'avoir de la désynchro. Vous, comment vous planifieriez un tel test? Et aussi vu que les machines sont sur le même LAN, est-ce pertinent de pencher sur une perte de paquets? Quels éléments réuniriez-vous pour une telle analyse? Merci beaucoup pour votre attention et votre aide. Cordialement, Eugène NG -- ngont...@epitech.net sympav...@gmail.com *Aux hommes il faut un chef, et au* * chef il faut des hommes!L'habit ne fait pas le moine, mais lorsqu'on te voit on te juge!* --- Liste de diffusion du FRnOG http://www.frnog.org/
