[Tsp-devel] Re: appel RPC mono-argument une autre explication....

[Erk]

Je réponds tardivement à un mail de Robert
qui étais arrivé dans "la mauvaise boite mail"...

>   Date: Thu, 13 Apr 2006 09:02:45 +0200
> From: "PAGNOT, Robert" <address@hidden>
> Subject: RE : [Tsp-devel] appel RPC mono-argument une autre explication... .
>     To: "Eric NOULARD (address@hidden)" <address@hidden>


>Que fais-tu des petits-indians, alors ?
>       Robert

En fait quand je parle d'encoder la requête "entier" c'est bien
prendre une structure C et la transformer en une suite
d'octet que l'on peut envoyer sur une chaussette
"a la message CORBA"

Donc OUI il faut encoder la structure C à l'expédition
et la décoder à l'arrivée, de la même façon que l'aurait fait
RPC.
On peut d'ailleurs utiliser un encdage XDR puis après
celà SI ON utiliser RPC pour transmettre le paquet on
l'envoi dans un opaque (qui ne touche pas à l'endianité puisqu'elle est
déjà gérée).

L'idée est donc que la requête "encodée" peut être transmise
sans considération d'endianité, l'avantage serait justement
d'utiliser des encodages comme CDR qui inclus une indication
sur l'endianité utilisée par l'encodage. Comme ça en général
l'expéditeur ne touche pas à ses indiens et celui qui reçoit
doit "vérifier l'endianité" et "eventuellement" décodé si ses indiens
à lui sont différents.

Evidemment c'est un peu "refaire XDR/RPC/XML-RPC" etc...
sauf que la requête encodée peut être plus facilement transmise
sur une bête socket, ou HTTP, FTP ou SSH/SSL ... sans
dépendre du RPC et de ses amis portmap etc...

Reste le souci des protocoles "text" comme XMLRPC il faudrait
encoder la requête encodée :)) en base64 (par exemple) ce qui
risque de faire un message un peu gros.

Si on est capable de "générer" les fonctions d'encodage à partir
d'un IDL (CORBA en l'occurence) ça coute pas très cher.

C'est pas pour tout de suite mais l'idée me tente.

Eric
Le 12/04/06, Erk<address@hidden> a écrit :
> Je ne sais pas si vous vous souvenez
> mais j'avais posé la question au moment
> du rajout des requêtes async_read/write et filtered_info
> temps du pourquoi avoir spécifié
> des interface RPC avec 1 seul argument qui englobe
> toute la requête.
>
> Une bonne réponse de Stéphane Galles avait été
> de dire que certains rpcgen  ne géraient pas le multi-paramètre
> (d'ailleurs on doit ajouter le -N à rpcgen pour qu'il
>  accepte le multi-argument qui est un comportement "new-style")
>
> Du coup les request_filtered_info et autre async_read/write
> ont plusieurs paramètres...
>
> Malheureusement,
> une autre "bonne" raison qui m'avait échappé et je m'en excuse
> justifiait ce choix.
>
> Le dialogue TSP asynchrone a été conçu sous la forme
> de request --> answer
> chaque request étant une structure qui obtient en retour une
> autre structure answer.
>
> En fait chacune de ces structures représente UN MESSAGE
> formaté (et encodable en XDR ou autre chose) que l'on souhaite
> ensuite envoyer via un canal de commande: RPC ou autre chose....
>
> Avec mes ajouts j'ai mélangé l'encodage des reqêtes avec
> l'envoi par le canal de commande, shame on me :((
>
> Cela reprends tout son sens avec un deuxième canal de commande
> et encore plus avec le generateur de code en préparation.
>
> Chaque MESSAGE TSP (request ou answer) peut être envoyé
> encodé directement sur un quelconque canal de commande qui
> l'encodera comme il l'entends.
>
> Je pense que dans la période de refactoring qui se pointe
> et qui pourrait nous amener vers TSP 1.0 il serait souhaitable
> de rester dans l'esprit du
>
> answer TSP_send_request(request)
>
> On peut même imaginer des versions "minimales" de canal
> de commande où l'on implémente qu'UN SEUL APPEL:
>
> encoded_answer TSP_send_encoded_request(encoded_request)
>
> et qui permettrait d'envoyer une requête TSP pré-encodée
> (XDR, CDR, etc...)
>
> le canal de commande ne verrait qu'un buffer d'octet
> struct encoded_request {
>      int             encoded_size;
>      opaque    buffer<>;
> }
>
> de cette façon rajouter une nouvelle requête ne nécessite
> "même" pas la mise à jour de l'API de commande.
>
> On doit "juste" créer (i.e. générer à partir de l'IDL) les fonctions
> d'encodage des différentes requêtes/réponses TSP .
>
>
> --
> Erk
>


--
Erk