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

[Stephane Galles]

Grouik !

Effectivement, actuellement est mélangée la notion de provider, et celle 
de session sur le provider,
et je pense que le jours où j'ai fait cela j'aurai mieux fait de rester 
coucher. Retrospectivement
cela me parait même être une idée ideuse. Re - Grouik.

Mais qu'est ce qui m'est passé par la tête ? Un résidu du prototypage 
sans doute... et puis c'est resté
comme cela. Quoi de mieux que le temporaire quand il est définitif.

Pour répondre à Steph Gar., actuellement, il faut appeler plusieurs fois 
la fonction
connect_all de maniere à pouvoir obtenir plusieurs connexions, et donc 
sur chacune des
connexions, ouvrir une session.

Bon, l'idée générale serait donc qu'il faudrait que la fonction open 
renvoie un handle sur
la session pour pouvoir les distinguer, puis à partir du open, on 
utiliser le handle de session.

Je dis cela sous toute réserve. Qu'en pensez vous ? Hum... cela 
casserait pas mal
de choses...et les clients en particulier...Faudrait - il faire la modif 
ou bien l'API vous
convient - elle en l'état ?

Sinon, en ce qui concerne la fonction connect_all (une idée de Robert me 
semble - il),
elle ne me semble pas si démoniaque que cela.

L'idée est que cela permet d'avoir un naming service pour pas chère. 
Quand tu obtients
ton tableau de provider, tu peut leur demander leur petit nom et ne 
prendre que celui
qui t'interesse. En gros c'est un serveur de naming collaboratif !

L'autre solution pour eviter le broadcast serait donc de s'assurer que 
le client connaisse
l'ID du provider à qui il va se connecter. Pourquoi pas, le seul 
problème est que cette information
dépend de l'ID que tu a attribué à ton provider sur la ligne de 
commande, alors que le nom
du serveur lui ne change pas.

Ou alors, on fait à l'ancienne :  des serveur différents ont des RPC ID 
différents, et le client
retrouve directement le serveur par cet ID. Cela manque un peu de 
poesie, mais c'est imparable.

Stephane Gal.


address@hidden wrote:

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