[RPC]Développer des applications RPC

Bonjour,

Pièce jointe 22600
J'aimerais commencer à écrire des applications "Remote Procedure Call" sous Visual C++ 2003. Mais il semble qu'il y a du COM derrière tout ça, faudra-t-il que j'apprends COM d'abord ??
RPC n'est-il pas seulement qu'une sorte de programmation socket client-serveur spécifique mais aussi une technologie appliquant l'IPC (InterProcess Communication)??
Pour bien imaginer ce qu'est une application RPC, pouvez-vous me citer quelques exécutables système Windows qui sont RPC !!

Merci d'avance !

Tu as du bol, je viens justement de potasser le début de la section de MSDN sur RPC.

Et en fait, tu n'as pas besoin d'étudier COM pour utiliser RPC: RPC n'utilise pas COM, c'est COM qui peut utiliser RPC.
Les deux utilisent des interfaces, mais une interface RPC n'est pas une interface COM.

Si tu peux lire l'anglais, tu peux aller voir le lien que de t'ai passé: J'ai lu du début au tutoriel inclus, et je pense que ça devrait te suffire à comprendre.

Pour les applications de Windows, je ne sais pas vraiment des masses, mais beaucoup de services Windows communiquent entre eux par RPC (notamment sur la même machine, juste d'un processus à l'autre, voire d'un contexte COM à l'autre).

Merci pour le lien !
Donc, RPC ne nécessite pas de connaître COM mais pourquoi l'aide se trouve dans Win32 & COM > Networking > Networking protocols ?
Avant de me plonger, je me demande si RPC n'est autre qu'un protocole comme HTTP, TCP, etc ????

Citation:

---

Les deux utilisent des interfaces, mais une interface RPC n'est pas une interface COM.

---

Quand on dit interface en Visual C++, c'est le langage IDL ou quoi ?

RPC, c'est un peu un sur-protocole: En-dessous, ça peut utiliser divers moyens de communication (TCP, tubes nommés, HTTP...).

Pour interface, c'est plus compliqué.

• Une interface n'est pas IDL: IDL est un langage servant à définir des interfaces. Notamment, le logiciel MIDL.exe fourni par microsoft peut prend un fichier IDL en entrée et pond des déclarations C et C++ d'interfaces en sortie.
• Une interface RPC, ce n'est apparemment qu'un ensemble de fonctions, avec lesquelles on n'utilise pas de "pointeur d'interface". Je pense qu'on utilise toujours IDL pour les définir, puisqu'on a forcément besoin du code C généré (les "stubs").
• Une interface COM, c'est ce qu'on utilise quand on manipule des objets COM, et ça s'utilise comme des classes C++ abstraites (des interfaces, quoi) En C et en C++, il existe deux façons possibles de la déclarer:
  
  • Faire générer un fichier par MIDL: Tu peux voir un exemple de ce que ça donne en regardant les fichiers unknwn.idl et unknwn.h de ton SDK. Avec ça, on a droit à toute la puissance d'IDL, permettant d'utiliser les interfaces pour DCOM, OLE Automation, etc.
  • utiliser des macros comme DECLARE_INTERFACE. Tu peux voir un exemple dans le fichier <objbase.h>. Par contre, en faisant ça, on n'a pas droit à pas mal de fonctionnalités données par IDL. Ça suffit généralement pour des interfaces "mineures" avec lesquelles on sait qu'on ne fera jamais de communication inter-processus, etc.
• Avec l'arrivée de .Net, il y a un nouveau type d'interfaces, les interfaces .Net. C'est spécifique à .Net, ça équivaut aux interfaces java, et ça n'est pas utilisable directement en dehors de .Net. Par contre, Microsoft fournit des wrappers pour utiliser des interfaces COM depuis .Net ou inversement.

C'est gentil Médinoc !
Je pense que je dois d'abord connaître ce qu'est une classe abstraite puis une interface (Java et C++).
RPC n'est pas seulement du Microsoft ?

À la base RPC est un standard. Microsoft y a apporté quelques extensions, notamment pour l'utilisation dans DCOM.

Une classe abstraite, c'est une classe qui possède des fonctions virtuelles pures. En conséquence, elle ne peut pas être instanciée directement, on ne peut créer que des objets d'une classe dérivée implémentant toutes ces fonctions.
Une interface .Net ou Java est plus ou moins une classe abstraite particulière: Toutes ses fonctions sont virtuelles pures, et elle ne peut contenir de données. Ce dernier point est très important, car c'est celui qui permet l'héritage multiple d'interfaces dans les systèmes (comme .Net et Java) qui interdisent l'héritage multiple de classes.
Une interface COM, c'est plus abstrait que ça, mais quand on l'utilise en C++, elle s'emploie comme une classe abstraite sans données.

Encore merci pour les éclaircissements sur les classes abstraites !! Si quelqu'un connait des exécutables windows qui utilisent RPC-DCOM, dis-le moi, c'est important pour le comprendre et le tester.

Je trouve que le tutoriel sur MSDN est un bon exemple.

Citation:

---

Envoyé par Médinoc

Tu as du bol, je viens justement de potasser le début de la section de MSDN sur RPC.

---

Quel bol ? Merci Médinoc !!

Bon, j'exagérais un peu en disans "je viens", en fait, je l'avais fait la veille. :D

Je reviens sur ce fil car je ne l'ai pas encore mis en résolu !!

Je résume: en gros, RPC est une couche au dessus du SOCKET, une technique permettant d'appeler une procédure sur une machine distante (peut aussi d'un même processus sur la même machine) comme une procédure locale. Mais comment en développer? Il semble qu'il n'y a pas encore de tuto sur ça sur DEVELOPPEZ; en effet, MSDN explique un peu mais ça reste flou.

Citation:

---

With RPC a client can connect to a server running on another platform. For example: The server could be written for Linux and the client could be written for Win32.

---

Est-ce vrai ? sous Windows ?
Une petite curiosité: en quoi RPC est-il un moyen utilisé par les VIRUS pour se propager surtout sous WINDOWS ??

Une autre citation qui me tracasse

Citation:

---

Comme pour CORBA, les couches COM+ se situent au niveau 5-6-7 du modèle OSI au dessus donc de la couche 4 de TCP/UDP

---

On compare donc ici la technologie COM+ à une couche réseau, pourquoi ? donc est-ce un truc au même titre que SOCKET, RPC, FTP, HTTP et les autres ?

Je ne connais pas assez COM+ pour répondre correctement à ta dernière question, mais je sais que COM+ utilise RPC.

Pour le fait de pouvoir l'utiliser avec Linux, tu ne peux pas évidemment utiliser les même stubs. Mais il me semble que le langage IDL est assez standard pourqu'un fichier IDL serve à la fois à générer les stubs Windows (quand on le traite sous Windows avec MIDL) et les stubs Linux (quand on le traite sous Linux avec je-ne-sais-pas-quoi).

Pour le problème des virus, eh bien, soit c'est parce qu'il y a des failles de sécurité dans l'implémentation Windows de RPC, soit parce que certaines choses sont mal réglées, comme le mot de passe d'un utilisateur: DCOM (qui utilise RPC) implique de se connecter en transmettant (sous forme cryptée) le mot de passe d'un utilisateur pour pouvoir faire diverses choses, donc si celui-ci est trop facile à deviner (attaque par dictionnaire, etc.), un virus peut se connecter avec ce mot de passe et faire un peu ce qu'il veut...

Et hop, voici un article sur l'implémentation de rpc en anglais: http://www.codeproject.com/KB/IP/rpcintro1.aspx

Mais concernant:

Citation:

---

On compare donc ici la technologie COM+ à une couche réseau, pourquoi ? donc est-ce un truc au même titre que SOCKET, RPC, FTP, HTTP et les autres ?

---

Qu'en est-il de COM tout court alors ? de DCOM surtout ?

DCOM est l'extension de COM qui permet d'utiliser RPC vers une autre machine (COM normal n'utilisait RPC que d'un processus à l'autre sur la même machine).

Tu peux utiliser RPC tout court sans avoir à connaître ni COM ni DCOM ni COM+.

Citation:

---

Tu peux utiliser RPC tout court sans avoir à connaître ni COM ni DCOM ni COM+.

---

:king:

Ma prochaine question ce serait faire du RPC avec Windows comme client et Linux comme serveur mais je pense que pour le titre de ce fil, c'est OK !! (résolu)