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

[Eric.NOULARD]

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