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" <technic...@hahd.fr> 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/
