appels de procédure à distance

Est-ce que quelqu’un connaît un bon moyen de faire des appels de procédure à distance dans des environnements Windows (non .net)?

Je ne peux pas trouver beaucoup d’informations sur la façon de le faire et le msdn n’a que la version .net.

Modifier:

Merci pour les réponses fournies jusqu’ici. Ce dont j’ai besoin est de communiquer avec un service sur le même ordinateur qui enverra des rapports de progression au “client”. La raison d’être de RPC est due aux outlook et à la façon dont les services ne peuvent pas parler aux applications normales à moins qu’ils utilisent RPC ou des tuyaux. En regardant dans les pipes, elles semblent être entièrement basées sur du texte et j’avais l’impression que rpc pouvait transmettre des valeurs fortement typées.

Je vais aussi regarder dans DCOM.

Si vous êtes seulement intéressé par le dialog entre les processus sur le même ordinateur, boost :: interprocess est un moyen génial d’obtenir un canal à travers lequel ils peuvent communiquer.

Un plus grand nombre de solutions spécifiques à Windows est un fichier mappé en mémoire partagée et des mutexes / signaux globaux ou des canaux nommés .

Les tampons boost :: serialize et google protocol sont des moyens de convertir les données que vous envoyez entre les processus en chaînes binarys moins dépendantes de la mise en forme de la structure et d’autres éléments pouvant différer entre les différents exécutables.

boost :: interprocess, boost :: serialize et les tampons de protocole devraient être indépendants de la plate-forme, donc techniquement, cela pourrait également fonctionner sur Linux / Mac!

DCOM dispose d’un mécanisme d’appel de procédure à distance basé sur DCE RPC. Si vous créez votre système en tant que composant COM ou placez un wrapper COM sur l’API que vous souhaitez exposer, vous pouvez l’utiliser. Au-delà de cela, vous voudrez peut-être approfondir votre question avec un aperçu plus précis des spécificités du problème. Je ne sais pas vraiment si le problème a des aspects qui pourraient empêcher l’utilisation de DCOM.

Une autre approche consisterait à placer un wrapper de service Web autour de l’application. Les services Web (certainement ceux basés sur SOAP ou XML-RPC) ne sont en réalité qu’un mécanisme RPC utilisant HTTP comme protocole de transport.

Il y a plus d’infos ici:
Obtenir “Microsoft Platform SDK pour Windows Server 2003 R2”, après avoir installé les exemples d’affichage dans le dossier … \ Samples \ NetDS \ RPC
sdk_NetDS_RPC.exe – exemple source soapsdk.exe – exemples MS
Plus de liens:
Tracer les appels RPC et notifier les événements COM + à votre programme
FastRpc
RPC sécurisé
Une bibliothèque RPC légère basée sur XML et HTTP.
ancienne aide, mais utile RPC.HLP
[MS-RPCE]: Extensions de protocole d’appel de procédure à distance
[MS-RPCH]: Spécification d’appel de protocole à distance via HTTP
[MS-COM]: Spécification du protocole du modèle d’object composant Plus (COM +) DCOM

Vous pouvez appeler le code à distance sur Windows de différentes manières. sockets, DCom etc … A un moment donné, Microsoft supportait rpcgen (basé sur DCE RPC) ce qui vous permettait de définir des appels d’API distants et son compilateur écrirait le code de colle. C’était la couche sous-jacente dans DCOM.

Il n’est pas compatible avec UNIX ONC-RPC qui est plus facile à utiliser et plus standard. Vous pourriez vouloir regarder l’ un des kits d’outils ONC_RPC si quelque chose comme DCOM n’est pas pour vous.

Tony

Oui, je suis d’accord avec Isalamon – il suffit d’utiliser le vrai RPC déjà intégré à MIDL. Vous pouvez obtenir un livre O’Reilly sur DCE RPC. Si vous êtes sur le même ordinateur, utilisez simplement un hôte de liaison de ncalrpc.

Voici quelque chose que nous avons utilisé en 1996 chez Cheyenne Software sur Windows NT pour l’antivirus InocuLAN. C’est du RPC pur, pas de la couche OO. J’espère qu’il est toujours disponible dans Windows plus récent.

Eh bien, en fonction de la complexité, des frais généraux et de la vitesse inverse, ces possibilités me viennent à l’esprit:

SOAP (que vous avez déjà exclu)
Corba
DCOM (DCE)
échange de messages XML
ONC-RPC (SunRPC)
échange de messages de type HTTP
échange de messages de type telnet (orienté ligne)

Pour tous, vous serez plus ou moins prêt à utiliser des bibliothèques, des paquets, etc.

Certains de ces éléments peuvent sembler étranges, mais en réalité, nous utilisons souvent HTTP ou Telnet pour RPC. La raison en est que vous n’avez pas besoin d’environnements sophistiqués à tester, n’importe quel logiciel étranger peut facilement s’y adapter. Celles-ci rendent également les services de votre programme facilement utilisables depuis un WebBrowser, une session telnet ou un autre programme qui lui ouvre simplement un socket et envoie la demande. Par exemple, la plupart de mes programmes incluent un argument de ligne de commande –scripting, qui ouvre un port telnet via lequel vous pouvez envoyer l’access à l’intégralité du modèle d’object via un langage JavaScript. Cela peut également être utilisé pour contrôler toute application à distance très facilement – sans aucun effort. Si vous avez déjà écrit un tel framework, il peut être réutilisé pour chaque nouvelle application (voir à quoi cela ressemble)

Je dois admettre que toutes mes applications sont écrites dans un environnement où tous les éléments ci-dessus sont déjà inclus et prêts à être utilisés, à la fois en tant que clients et en tant que serveurs.

Résumé: utilisez la chose la plus simple, qui fait le travail. Vous n’avez pas besoin de Corba ou SOAP à moins que votre application doive être intégrée dans une telle infrastructure.