Le 25/10/07, Frédéric Blanchet-Momas<[EMAIL PROTECTED]> a écrit : > Bon je viens d'identifier le problème : entre la chaise et l'ecran !!! > > Je viens de me refaire avoir par la résolution de nom du tsp_bb_provider, il > donne comme adresse de réponse toujours celle de son nom qui est donc > 127.0.0.1 (en tout cas sur les système red hat), un petit vi sur /etc/hosts > m'a dépanné
Bingo. C'est ce que j'étais en train d'écrire dans le tracker. > Est il prévus de connecter le provider sur une interface précise (comme le > -i du ping) afin qu'il donne l'adresse réseau de cette carte comme adresse > d'echange des samples ? ou peut etre qu'il donne comme réponse par défault > l'adresse sur laquelle il a reçut les requetes. En fait tu peux regarder les discussions des bugs: https://savannah.nongnu.org/bugs/index.php?19455 https://savannah.nongnu.org/bugs/index.php?17035 et tu verras que pour l'instant la provider lib TSP essayait de trouver l'@IP de la machine sur laquelle le provider s'exécute ce qui pose 2 pb: 1) si la machine a +ieurs IP 2) la résolution de nom est daubée (ton cas) puisque nous faisions l'équivalent de gethostbyname(gethostname()) C'est néanmoins intéressant que le provider renvoie dans l'answer_sample_init (réponse au request_sample_init) l'url i.e. data_address ou le consumer pourra trouver le flux des samples correspondant à sa demande. C'est intéressant car on peut effectivement imaginer que le provider renvoie au consumer une adresse qui soit éventuellement différente de l'adresse de connection au canal de commande. -- Erk _______________________________________________ Tsp-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/tsp-devel
