RE : [Tsp-devel] Re: Auriez vous une id ée la dessus ?

[PAGNOT, Robert]

Salut Erk,

J'ai eu un peu de mal à suivre tes explications.

Ce que je comprends est que le consumer transmet au provider une URI du style tsp:\\host-consumer:port pour que celui-ci puisse connecter la chaussette vers le consumer.

Il s'agit alors d'un problème lié à la configuration réseau IP.

Or, en mode connecté (TCP), il doit y avoir un moyen pour le provider de récupérer l'adresse IP du consumer dans la propre trame de commande RPC/XMLRPC/CORBA/... ? Ceci contournerait tes pbs, mais le consumer doit encore fournir un n° de port.

Autre réponse ... Si ton réseau est zar-bi, à savoir {(DNS) * (reverse DNS) != 1}, tu auras des problèmes ailleurs que dans TSP.

D'autre part, il me semble sain que TSP évite d'utiliser des services DNS, car tous les réseaux n'ont pas forcément un serveur DNS qq part. Moi particulièrement, ch'uis assez fainéant pour ne pas le faire ...

A+

        Robert

-----Original Message-----
From: Eric Noulard [mailto:address@hidden]
Sent: Saturday, July 15, 2006 7:35 PM
To: Stephane GALLES
Cc: TSP Devel
Subject: [Tsp-devel] Re: Auriez vous une idée la dessus ?

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

_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel

---------------------------------------------------------

CE COURRIER ELECTRONIQUE EST A USAGE STRICTEMENT INFORMATIF ET NE SAURAIT ENGAGER DE QUELQUE MANIERE QUE CE SOIT EADS ASTRIUM SAS, NI SES FILIALES.

SI UNE ERREUR DE TRANSMISSION OU UNE ADRESSE ERRONEE A MAL DIRIGE CE COURRIER, MERCI D'EN INFORMER L'EXPEDITEUR EN LUI FAISANT UNE REPONSE PAR COURRIER ELECTRONIQUE DES RECEPTION. SI VOUS N'ETES PAS LE DESTINATAIRE DE CE COURRIER, VOUS NE DEVEZ PAS L'UTILISER, LE CONSERVER, EN FAIRE ETAT, LE DISTRIBUER, LE COPIER, L'IMPRIMER OU EN REVELER LE CONTENU A UNE TIERCE PARTIE.



This email is for information only and will not bind EADS Astrium SAS in any contract or obligation, nor its subsidiaries.

If you have received it in error, please notify the sender by return email. If you are not the addressee of this email, you must not use, keep, disseminate, copy, print or otherwise deal with it.

---------------------------------------------------------