c++ et RPC, quelques questions

Bonjour,

je ne trouve pas beaucoup de documentation sur le RPC. J'ai trouvé quelques exemples, mais rien qui ne réponde à mes questions. En espérant que certains d'entre vous connaissent le RPC, je vous les pose donc (les questions):

1. Le principe du RPC c'est:
a. Une application A qui tourne sur un serveur S
b. Un stub qui fais le lien entre l'OS du serveur S et mon appication A
c. Un client C qui appelle les fonctions définies dans le stub
Le reste, ce sont les OS qui s'en occupent.

Est-ce bien résumé?

2. Si, depuis mon client C, je souhaite appeler des fonctions appartenant à plusieurs programmes différents sur le serveur S, dois-je créer un stub pour chaque application? (Ou est-ce qu'un seul stub permet d'utiliser plusieurs applications?)

3. Si, à la place d'application (exécutables) j'ai des dlls. Est-ce tout de même faisable d'appeler les fonctions de ces dll via RPC? Si oui, dois-je faire un stub pour chaque dll?

4. Avez-vous des liens intéressants concernant le RPC?

Merci par avance :)

Citation:

---

Envoyé par r0d

4. Avez-vous des liens intéressants concernant le RPC?

---

tutoriel gSoap:roll:

:aie:

Non mais d'après ce que j'ai compris, gSoap c'est pas vraiment du RPC, c'est carrément du webService. Ici, je veux qu'un ordinateur appelle des fonctionnalités présentes sur d'autres ordinateurs, mais dans le même réseau local, il n'y a donc pas besoin de passer par gSoap (et d'experience, et même si gSoap est très bien, si on peut s'en passer c'est pas plus mal).

Or si je ne m'abuse, les OS implémentent déjà leurs services RPC. C'est donc cette solution qui m'intéresse pour l'instant, car bien plus simple, et donc moins compliquée (non ce n'est pas une contrepèterie).

RPC est un terme assez générique. On parle souvent de RPC même au sein de la même machine, entre deux applications différentes.

Soap est un moyen de faire du RPC, Java offre un bon support du xml-rpc, dbus permet de faire du RPC, mais sans support réseau me semble-t-il, côté windows on utilise plutôt COM/Corba, côté .Net, plutôt les webservices, mais il me semble qu'il y a quelque chose dans les WCF pour faire du RPC à travers réseau...

Bref, comme tu dis, le sujet est vaste, et peut-être faudrait-il mieux que tu détailles un peu plus ton environnement si tu ne veux te retrouver avec une bibliothèque à lire ;).

Citation:

---

Or si je ne m'abuse, les OS implémentent déjà leurs services RPC. C'est donc cette solution qui m'intéresse pour l'instant, car bien plus simple, et donc moins compliquée (non ce n'est pas une contrepèterie).

---

A part windows, pour les autres, je ne vois pas.

Pour moi, RPC ce n'est jamais qu'un moyen de presenter une API client/serveur a l'aide de generateurs de code et de bibliotheques pour en simplifier l'implementation. Le cout, c'est que les appels sont des points de synchronisation et donc qu'on ne peut pas faire autre chose en attendant la fin de la fonction appelee, sauf a tapper dans les threads.

En passant, j'avais l'impression que c'etait passe de mode.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Pour moi, RPC ce n'est jamais qu'un moyen de presenter une API client/serveur a l'aide de generateurs de code et de bibliotheques pour en simplifier l'implementation. Le cout, c'est que les appels sont des points de synchronisation et donc qu'on ne peut pas faire autre chose en attendant la fin de la fonction appelee, sauf a tapper dans les threads.

---

gSoap gère très bien (et de façon simple) les threads, donc ce n'est pas vraiment un problème.

En revanche, l'utilisation de gSoap rend plus difficile la maintenance, car à chaque modif de l'interface, il faut générer à nouveau le client/serveur et le recompiler.

Corba n'est pas gratuit il me semble non?

Citation:

---

Envoyé par white_tentacle

[...]peut-être faudrait-il mieux que tu détailles un peu plus ton environnement si tu ne veux te retrouver avec une bibliothèque à lire ;).

---

En fait c'est simple: je vais avoir tout un tas de serveurs (je ne sais pas exactement combien, disons entre 20 et 100), sur lesquels seront installés plusieurs applications A1, A2, ..., An. Je voudrais avoir un point d'entrée, un web service gSoap, qui reçoit des pétitions, les dispatche aux serveurs, et retourne le résultat sous forme de chaine de caractères.

Et en fait, je voudrais éviter de faire un client/serveur SOAP pour chaque application An. Je ne parviens pas à trouver des infos, mais il me semblait qu'il existait des solutions plus simples.

Citation:

---

Envoyé par r0d

gSoap gère très bien (et de façon simple) les threads, donc ce n'est pas vraiment un problème.

---

Fondamentalement on cree un probleme en forcant une synchro non necessaire (pas toujours, mais si elle est necessaire, les threads n'arrangent rien) et apres on introduit les threads pour le masquer.

Citation:

---

Corba n'est pas gratuit il me semble non?

---

http://docs.huihoo.com/corba/free_corba.html

Aucune idee de l'utilisabilite pratique de ces libs.

Citation:

---

Envoyé par white_tentacle

A part windows, pour les autres, je ne vois pas.

---

Et sais-tu comment on fait? (pour faire du RPc en natif, en c++, sous Windows)

Citation:

---

Envoyé par Jean-Marc.Bourguet

En passant, j'avais l'impression que c'etait passe de mode.

---

Argh. Et quelles sont les alternatives?

Citation:

---

Envoyé par r0d

Argh. Et quelles sont les alternatives?

---

Aucune idee: ce n'est pas mon domaine. Mon impression est basee sur le fait que je n'entends plus RPC des qu'on parle de reseau, comme ce le fut a un moment donne.

De ma petite expérience et de ce que j'ai appris, dés le moment où la communication n'est pas triviale et simple, ou demande de hautes performances, le RPC est une solution à écarter.

Ceci dit, je ne suis pas non plus spécialiste.

Citation:

---

Envoyé par r0d

Et sais-tu comment on fait? (pour faire du RPc en natif, en c++, sous Windows)

---

MSDN est ton ami : Remote Procedure Call