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

[Stephane Galles]

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.