Le 18/07/06, PAGNOT, Robert<[EMAIL PROTECTED]> a écrit :
OK, je ne me souvenais plus de qui se connectait sur qui. Il s'agit donc bien d'un problème de résolution d'@IP côté provider, addresses fournies sous la forme numérique. Si tu as deux cartes Ethernet, est-ce pour deux réseaux bien distincts ? Ou il s'agit d'un redondance de chemin ?
Les 2 sont possibles. Le cas le plus courant (pour l'instant) étant une interface dédiée pour les "tests" ou passe TSP.
Peut-être une solution consisterait à ce que le provider transmette toutes les @IP (désolé pour le changement d'interface ...), démarre les "accept" sur toutes ces @IP, puis ferme les autres dès que l'une d'entre elles est connectée.
Ca c'est pas bête, même si c'est un peu bourrin. Le pb "technique" la dessus c'est que je ne sais pas DE FACON PORTABLE récupérer toutes les adresses @IP d'une machine. D'où pour l'instant a) gethostname --> le nom de la machine b) gethostbyname --> l'@IP associée au nom
Ce comportement me semble obligatoire dans le cas de rédondance de chemin : le consumer tentera le connect sur toutes les @IP jusqu'à obtenir une bonne. Dans le cas de réseaux distincts, cela marche aussi, même si ce n'est pas très élégant : le connect devra être refusé au consumer par défaut de routage.
Je mets tes remarques sur la pile car elles sont bonnes. Toutefois le pb le plus preignant est de détecter si le provider à une conf réseau à la con qui ferait qu'on renvoit une @IP débile du genre 127.0.0.1 parce que la conf locale de la machine provider est daubée. -- Erk _______________________________________________ Tsp-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/tsp-devel
