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

[PAGNOT, Robert]

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 ?

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.

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.

A+

        Robert


-----Original Message-----
From: Eric Noulard [mailto:address@hidden
Sent: Tuesday, July 18, 2006 9:01 AM
To: TSP Devel
Subject: Re: RE : [Tsp-devel] Re: Auriez vous une idée la dessus ?


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


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

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