Bibliothèque RPC multi-plateforme C++

Question

Voici la tâche: Imaginez, nous avons une application et un plug-in pour cela (bibliothèque dynamique). L'interface entre l'application et le plug-in est complètement définie. Maintenant, j'ai besoin d'exécuter l'application et le plug-in sur différents ordinateurs. J'ai écrit un bouchon pour le plug-in sur un ordinateur où les applications réelles sont en cours d'exécution. Et l'application le charge et appelle ses fonctions comme s'il s'agissait d'un plug-in natif. Sur l'autre ordinateur, il y a un bouchon à la place de l'application réelle, qui charge le plug-in natif. Maintenant, j'ai besoin d'organiser RPC entre mes bouchons sur le réseau, quel que soit le transport même. Habituellement, ce n'est pas difficile. Mais il sont quelques restrictions:

1. fiche d'application-en interaction peut être reenterable (par exemple, l'application appelle f1() des appels plug-in, dans le plug-in f1() g1() de l'application, dans g1() application appelle f2() de plug-in et ainsi de suite ...)
2. Toute reenteration doit être exécuté exactement par le même fil, qui a commencé la séquence

où puis-je trouver un cross bibliothèque C++ RPC de plate-forme avec de telles fonctionnalités?

Answer 1

La restriction n ° 1 est parfaitement raisonnable, tant qu'aucune des fonctions sur l'une ou l'autre des machines n'affecte le verrouillage d'un mutex sur un RPC.

Je ne suis pas entièrement sûr que le # 2 est possible - supposons que vos appels bloquent; quand g1() appelle f2(), le mécanisme RPC ne peut pas exécuter f2() sur le même thread que f1(), car f1() est bloqué indirectement en attendant son résultat!

Si vos appels sont à la place asynchrones, il est possible d'interroger le système RPC en attendant la fin de f1() et de le faire exécuter f2() dans le même thread. Vous ne devriez pas faire cela, cependant; cela signifie que tout appel asynchrone en attente d'achèvement RPC peut soudainement "bloquer" lorsque le RPC invoqué est poussé sur la pile.

Y a-t-il une raison particulière pour laquelle vous voulez ce comportement?

Dans tous les cas, googling "cross platform rpc" donne pas mal de résultats; J'imagine que n'importe lequel d'entre eux correspondrait à votre facture si vous ignorez la deuxième restriction. XML-RPC est l'un des meilleurs résultats, et il y a un certain nombre de mises en œuvre de C:

http://www.xmlrpc.com/directory/1568/implementations

EDIT: Après quelques recherches sur Google, je ne peux pas trouver une seule bibliothèque qui fait exactement ce que vous êtes demander. Ils semblent tous être bloquants ou asynchrones multithread. Si vous avez vraiment besoin d'implémenter la restriction # 2, vous devrez le faire à la main. L'utilisation de boost::asio serait un bon point de départ pour une communication multiplateforme. Je ne vois toujours pas la différence entre ce que vous voulez faire et appeler la fonction de gestionnaire dans un deuxième fil alors que le premier est en train de bloquer, cependant ...