[Tsp-devel] Re: Auriez vous une idée la dessu s ?

[Eric Noulard]

Le 15/07/06, Stephane GALLES<address@hidden> a écrit :
> Eric Noulard wrote:
> >
> > d'ailleurs a bien y réflécir je ne vois pas pourquoi on ferait
> > pas un gethostname à la place du gethostbyname...
> > enfin je m'éloigne de la question initiale.
>
> Effectivement, il faudrait peut être ce prémunir de ce problème, car
> cela a l'air relativement courant les hichiers hosts 'étranges'

Stéph,

(je cc la liste car le sujet pourrait en intéresser d'autres)

En fait le pb de fond est le suivant:

1) un consumer "devrait" pouvoir ouvrir une session TSP
   avec l'@IP du provider

     ruby_tsp_consumer_qui_dechire -u xmlrpc://132.45.67.233 -x maconf.xml

2)  Cette première étape acheminant la REQUEST OPEN ne pose pas de pb.
    Ensuite
         REQUEST SAMPLE  x fois
    puis finalement
          REQUEST SAMPLE INIT

    Et là on est bien emmerdé car on doit renvoyer une
    adresse + N° de port pour que le consumer puisse recevoir le flux TSP.
    un truc du genre:
        hyperion:45678   (dans answer_sample->data_address)

3) Comme (malheureusement) la request_open
    ne contient pas l'URL EFFECTIVEMENT utilisée le consumer
    on fait un gethostbyname pour "retrouver" le nom de la machine.

    Ensuite on décide de renvoyer soit la valeur "symbolique"
    du host du provider ou la valeur numérique (@IP)
     en faisant un gethostbyaddr...

Le pb:
     1) si on renvoit la symbolique il se peut que le consumer
          ne puisse pas faire la résolution DNS car il ne connait que l'@IP
          du provider

     2) si on renvoit l'@IP numérique on est bien embêté pour renvoyer
          la bonne:
                a) si /etc/hosts (ou son équivalent) est pourri car
                     je n'ai pas trouvé comment chopper l'@IP sans
                     faire un    gethostbyaddr (qui finit par faire
un lookup dans /etchosts)
                b) si la machine possède +ieurs @IP on est  bien
                     embêté pour choisir...

Y'a un pb encore 3 anomalies (liées entre elles) ouvertes à ce sujet:

https://savannah.nongnu.org/bugs/?func=detailitem&item_id=14783
https://savannah.nongnu.org/bugs/?func=detailitem&item_id=14770
https://savannah.nongnu.org/bugs/?func=detailitem&item_id=17035

Si toi (ou d'autres) ont des idées sur une solution "propre" à ce pb
je suis preneur.

Sinon pour examiner ce genre de pb j'ai mis en conf
un petit prog de test:

tsp_check_host_and_ip

(src/util/libutil/tsp_check_host_and_ip.c)

Ca permet de vérifier "visuellement" la "cohérence" de la résolution
inverse et directe, par exemple chez moi:

$ tsp_check_host_and_ip
hostname is  <tsp_demo> (as reported by gethostname)
@IP returned is <192.168.0.2> <addrtype= AF_INET> (as reported by gethostbyname)
hostname returned is <tsp_demo.bordeneuve.fr> for @IP <192.168.0.2>
<addrtype= AF_INET> (as reported by gethostbyaddr)
$


--
Erk