Re: [Tsp-devel] RE: TSP Request Sample à la volée...

[Ibou de Joie]

Salut à Tous.

On peu vraiment pas etre tranquillement en en vacance à la maison sans
que le stéph de gdisp+ nous fasse un tsunami de neurone avec sa double
connection !!!

Le mécanisme d'URL de Eric m'a l'air complet, et je crois meme qu'il
pourrait marcher avec les clefs à coucher dehors de CORBA (ces fameuses
IOR ), et sans doute pour une vraie URL d'XML-RPC, mais à verifier par
des spécialistes.

Est-ce que ce mécanisme de pourrait pas se généraliser aussi sur le type
du provider ?  "rpctype://localhost:ACTIF le provider Actif type bench,
a contrario du passif type resreader ?" . Car le stef de gdisp aimerait
toujours avoir un moyen de differencier les types de provider avant cnx.
Mais si on dit que l'on vire le namming de TSP, le probleme du typage du
provider saute aussi...

Je suis pour simplifier l'API de TSP en enlevant le connect all. A voir
si Robert ne rale pas trop. Ensuite je pense que une API de connection
de type "NomDuHost:NomDuProvider" suffit pour le besoin actuel, et plus
parlant qur "Host:Numéro". Rajouter un typage de flux
"RPC:NomHost:NomProvider" permetterait de généraliser le truc, mais je
ne suis pas sur que cela soit indispensable, vu que la lib client risque
de devoir choisir à la compile le type de commande (RPC, CORBA, XML) et
donc de n'avoir qu'une seule clef possible... Mais c'est vrai que c'est
beau une URL...

Y++

On Fri, 2004-04-16 at 13:59, address@hidden wrote:
> En fait tout ceci est bel et bien utile.
> 
> Ce à quoi je pense quand je dis 'tordre'
> le coup au broadcast, c'est seulement 
> 'tordre' le coup DANS l'API TSP_consumer.
> 
> Mon point de vue est que l'API TSP consumer
> doit offrir un mécanisme de base:
> 
> TSP_provider_t TSP_consumer_open_session(const char* host_name, int
> tsp_prog_id);
> 
> qui ouvre une 'session' TSP que Stéphane stocke/gère dans l'objet
> opaque TSP_provider_t donc ce seriat peut-être mieux d'appeler
> la fonction 
> TSP_consumer_open_provider
> 
> Donc on identifie un provider de façon unique 
> avec son host et son prog id TSP,
> [c'est une méthode garantie tant qu'on a que des provider RPC,
>  l'idéal serait une méthode avec un truc genre URL]
> 
> ce qui donnerait:
> TSP_provider_t TSP_consumer_open_session(const char* TSP_url);
> 
> avec TSP_url un truc du genre:
> 
> <method>://<hostname>:<id>
> 
> donc par exemple
> 
> rpc://localhost:0  le provider RPC qui tourne sur localhost progid (RPC) 0
> 
> rpcname://localhost:stub_server le provider RPC qui tourne sur localhost et
>                                  dont le nom est 'stub_server'
> 
> 
> etc...
> qu'ensuite on implémente 1 fonction (interne à l'API consumer) qui
> réalise chaque "méthode" d'accés de façon à avoir différents 
> 'services de nommage' je n'y vois pas de pb.
> 
> Dans tous les cas cette fonction de base renvoi un handle particulier
> 'TSP_provider_t' qu'on pourrait utiliser pour faire un truc du genre
> 
> TSP_provider_t TSP_consumer_copy_session(TSP_provider t)
> 
> qui ouvre une nouvelle session à partir des infos d'une session
> déjà ouverte (d'ailleurs on peut déjà coder cette fonction
> sans casser l'existant).
> 
> Ca n'enlève rien à l'intérêt du
> 
> ./provider_joli --tsp-server-number 1 --tsp-server-name 
> provider_joli_cours_de_la_bourse
> 
> Qui est une fonctionnalité complémentaire de la lib côté provider.
> 
> Vos avis.
> Sinon comment vont les Caribous?
> 
> Eric
> 
> -----Original Message-----
> From: Stephane Galles [mailto:address@hidden
> Sent: Fri 4/16/2004 1:23 PM
> To:   tsp-devel
> Cc:   GARAY Stephane; NOULARD, Eric-Syntegra FR; DUFRENNE Yves
> Subject:      Re: TSP Request Sample à la volée...
> 
> J'ai regardé rapidement ton algo, cela me semble OK.
> 
> Concernant l'unicité du nom de provider, on peut raisonnablement penser
> que si tu compte utiliser deux providers sur la même machine, tu dois
> être en mesure de t'assurer que tes deux providers n'aient pas le même nom.
> 
> Même si les noms des providers sont codés en dur, il assez facile de 
> s'assurer de
> ne pas avoir de collision de nom en évitant les noms trop génériques.
> 
> Néanmoins, le problème pourrait se poser dans le cas où on souhaite utiliser
> deux instances du même provider su la même machine. Dans ce cas 
> effectivement
> il faut être capable de distinguer les deux providers.
> 
> Un réponse simple à ce problème serait d'ajouter des arguments de ligne 
> de commande
> TSP pour pouvoir faire un overide du nom d'un provider à son lancement, 
> ce qui
> permet de gagner sur les deux tableaux : le nom codé en dur dans le 
> provider est
> utilisé dans le cas général, et pour les cas particulier où il faut 
> résoudre des collisions
> de nom, les noms peuvent être changés via la ligne de commande au 
> lancement, par
> un mecanisme standard pour tout les providers.
> 
> Prenont l'exemple du lancement de trois providers, dont deux sont 
> identiques, on
> ferait comme cela (ici les deux executables sont nommés provider_joli et 
> provider_chouette)
> On ferait :
> 
> ./provider_chouette --tsp-server-number 0
> ./provider_joli --tsp-server-number 1 --tsp-server-name 
> provider_joli_cours_de_la_bourse
> ./provider_joli --tsp-server-number 2 --tsp-server-name 
> provider_joli_vitesse_du_vent
> 
> Qu'en pensez vous ? Evidemment, toute cette problématique est liée au 
> broadcast initial qui
> ne plait pas à Eric. Donc si on tord le coup au broadcast, tout cela n'a 
> plus d'interet.
> Réactions ?
> 
> Steph
> 
> GARAY Stephane wrote:
> 
> > OK les gars, si je vous comprends bien, voilà ce que je dois faire.
> >  
> > Soient 2 providers, et gdisp+ (au fait j'ai du mal à trouver un autre
> > nom qui déchirerait un peu plus [je reprends le vocable de Duf] ).
> >  
> > Au démarrage de l'outil :
> >  
> > TSP_consumer_connect_all();
> > Boucle sur les providers {
> >    TSP_consumer_get_connected_name(); /* on recupere "P1" et "P2" */
> >    TSP_consumer_request_open();
> >    TSP_consumer_request_information();
> >    TSP_consumer_get_information();
> > }
> >  
> > Au démarrage du sampling, dans le thread de chaque provider :
> >  
> > TSP_consumer_request_sample();
> > TSP_consumer_request_sample_init();
> > Tant que le samling est ON {
> >    TSP_consuler_read_sample();
> > }
> > TSP_consumer_request_sample_destroy();
> >  
> >  
> > Puis lorsque je dois sampler de nouveaux symboles du *premier 
> > *provider *P1* :
> >  
> > TSP_consumer_connect_all();
> > Boucle sur les providers {
> >    TSP_consumer_get_connected_name();
> >    si le nom est P1 {
> >       /* ouverture de la 2ieme session de P1 */
> >       TSP_consumer_request_open();
> >       TSP_consumer_request_sample();
> >       TSP_consumer_request_sample_init();
> >       ...
> >       dans le sampling-thread du provider P1, on
> >       abandonne la premiere session au profit de la deuxieme.
> >       ...
> >       /* fermeture de la 1ere session de P1 */
> >       TSP_consumer_request_sample_destroy();
> >       TSP_consumer_request_close();
> >       TSP_consumer_disconnect_one();
> >    }
> >    sinon {
> >       TSP_consumer_disconnect_one();
> >       /* dans notre cas, on deconnecte la 2ieme session P2 */
> >    }
> > }
> >  
> > *Rem : est-on sur d'avoir l'unicité de nom de provider ???*
> >
> >
> >      -----Message d'origine-----
> >     *De :* address@hidden [mailto:address@hidden
> >     *Envoyé :* jeudi 15 avril 2004 18:55
> >     *À :* GARAY Stephane; DUFRENNE Yves
> >     *Cc :* address@hidden
> >     *Objet :* RE: TSP Request Sample à la volée...
> >
> >     Oui je comprends pourquoi tu ne vois pas pourquoi :))
> >
> >     Ce cochon mais néanmoins très compétent Stéphane Gal. a un peu
> >     dissimulé la chose.
> >
> >     Ce qui est caché c'est le fait que ton TSP_provider_t  est en
> >     fait un pointeur qui contient toutes les données d'une session
> >     TSP.
> >
> >     Suivant les specs un TSP_request_open renvoie un id de session
> >     (si l'open réussi).
> >     Cet id de sesion est utilisé dans toute les requêtes ultérieures
> >     via cette "session" TSP. Cela permet entre autre de gérer une table
> >     des états des consumers côté provider.
> >
> >     Stéphane Gal. a caché cette outillage dans son 'handle' opaque
> >     TSP_provider_t.
> >
> >     C'est en fait l'infame:
> >     TSP_consumer_connect_all qui te cache l'allocation des handles.
> >     Lis le code
> >     src/core/driver/tsp_consumer.c:TSP_consumer_connect_all
> >
> >     et tu verras comment faire plusieurs sessions avec le même
> >     provider.
> >
> >     Je ne saurais que trop conseiller aux concepteurs de consumer
> >     TSP robustes de ne pas s'appuyer sur l'API
> >     (TSP_consumer_connect_all) a qui je couperais
> >     bien le cou sans scrupule.
> >
> >     Mieux vaut gérer sa recherche de provider actif tout seul
> >     voir que les paramètres d'ouverture d'une session TSP soit
> >     SPECIFIER par l'UTILISATEUR.
> >     je veux dire par là que TSP est fait pour faire tourner
> >     les procvider à un endroit et les consumer à un autre donc
> >     on va pas 'scanner' le Voisinage Reseau (TM) du consumer
> >     pour trouver les provider qui l'entoure, ou en tout cas
> >     un consumer velu peut le faire, MAIS sans s'appuyer sur l'API TSP.
> >
> >
> >     -----Original Message-----
> >     From:   GARAY Stephane [mailto:address@hidden
> >     Sent:   Thu 4/15/2004 4:08 PM
> >     To:     NOULARD, Eric-Syntegra FR; DUFRENNE Yves
> >     Cc:     address@hidden
> >     Subject:        RE: TSP Request Sample à la volée...
> >     Si j'ai bien tout compris, tu me demandes de faire une deuxième
> >     connexion
> >     au même provider de type TSP_provider_t .
> >     Je fais cela via la méthode TSP_consumer_request_open. Correct ?
> >     Je ne vois pas comment différencier mes deux connexions après coup...
> >     Moi avoir raté quelque chose ?
> >
> >     Stef.
> >
> >
> >
> 
> 
> 
> 
> ----
> 

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