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

[Eric Noulard]

Le 17/07/06, PAGNOT, Robert <address@hidden> a écrit :
> Salut Erk,
>
> J'ai eu un peu de mal à suivre tes explications.

Ben je m'en excuse c'est que je ne suis pas très clair.

> 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.

      Tout a fait exact c'est le data_address de l'answer_sample_init
      qui répond à request_sample_init (i.e. envoi la purée de sample)

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

       Oui et Non voir après.

> 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/... ?

C'est théoriquement possible mais intrusif dans la couche de commande utilisé.
La lib ONC-RPC connait la socket utilisé mais ne donne pas d'outils
(que je connaisse) pour celui qui l'utilise.

TSP fait appel à la lib RPC mais la lib RPC ne donne pas à TSP le moyen
de savoir quel est l'@IP de l'appelant.

Ensuite le pb ici est de savoir "par quelle @IP" le consumer a contacté le
provider. Donc je cherche ici l'@IP du provider qui correspond à celle
utilisé par le consumer pour l'appeler.

Dans le cas simple c'est l'@IP unique du provider que l'on récupère
en faisant:

gethostname qui donne le nom de machine
puis
gethostbyname qui donne l'@IP à partir du nom.

Si ta machine provider a +ieurs @IP tu n'es pas sur de renvoyer la bonne...
Si ta resolution nom-->@IP locale au provider est daubé même combat.

(Attention au fait que la résolution nom-->@IP ne devrait jamais faire
appel au DNS mais à un lookup local dans /etc/hosts ou équivalent sous Win32)

> Ceci contournerait tes pbs, mais le consumer doit encore fournir un n° de port.

Attention c'est le provider qui choisi où (@IP + port) le consumer doit
se connecter et pas le contraire.

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

 Oui c'est clair, si il y a du NAT aussi etc...
L'idée étant quand même que si le consumer a réussi à t'envoyer
ses request_XXX c'est qu'il te voit.
Maintenant tu ne sais pas comment et par quel chemin.

> 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.

OUI et c'est exactement pour ça que j'ai fait des changements pour que
le provider renvoit une adresse de socket numérique:

10.45.67.89:56884
au lieu de
monprovider.reseau.org:56884

parce que dans bien des cas le consumer ne sait pas résoudre:
monprovider.reseau.org --> 10.45.67.89 vu qu'il a fait qqchose du genre:

tsp_consumer -u rpc://10.45.67.89

> Moi particulièrement, ch'uis assez fainéant pour ne pas le faire ...

Ca m'étonne pas de toi.

Quoiqu'il en soit "DNS" est largement exagéré
Il s'agit de renseigner un fichier /etc/hosts qui décrivent
les machines mises en jeu dans les connexions TSP.
Le seul truc c'est qu'en TSP 0.6.x il fallait le faire sur
la/les machines provider ET consumer.

En TSP 0.7.x et 0.8.x il FAUT le faire sur la machine provider.

Ceci me semble assez peu contraignant, une machine provider doit
avoir une conf réseau "propre" qui lui permet de se "résoudre"
lui même:

address@hidden --> mon nom
ET
mon nom --> mon @ip

reste le pb des machine avec +ieurs cartes réseaux.
Et là je pense qu'on échappera pas à un paramètre de conf car
je ne vois pas sur quel critère décider que le flux TSP doit
passer par l'une ou l'autre des I/F réseau dispo.

Et le pb ultime, j'ai 2 I/F réseau (et donc 2 @IP) et toutes
les 2 peuvent faire passer du TSP.

Quelle adresse je donne au consumer ?

J'espère que c'est plus clair.

--
Erk