2010-07-19 9 views
1

J'ai un serveur distant qui gère différentes commandes, dont l'une est une méthode de récupération d'événement.XMLRPCPP traitant de manière asynchrone plusieurs appels?

L'extraction d'événement renvoie immédiatement s'il y a un ou plusieurs événements répertoriés dans la file d'attente prêts à être traités. Si la file d'attente d'événements est vide, cette méthode ne retourne pas avant un délai de quelques secondes. De cette façon, je ne rencontre aucun délai d'attente HTTP/socket. Au moment où un événement devient disponible, la méthode revient tout de suite. De cette façon, le client ne fait que des connexions au serveur et le serveur n'a pas besoin de se connecter au client. Ce mécanisme d'événement fonctionne bien. J'utilise la bibliothèque boost pour gérer les files d'attente, les notifications d'événements, etc.

Voici le problème. Pendant que le serveur reste en arrière en revenant de la méthode de récupération d'événement, pendant ce temps, je ne peux pas émettre d'autres commandes. Dans le code source, XmlRpcDispatch.cpp, je vois dans la méthode "work", une simple boucle qui utilise un appel bloquant pour "select". On dirait que lorsque la gestion d'une méthode est occupée, aucune autre demande n'est traitée. Question: Est-ce que je ne vois pas quelque chose et XmlRpcpp (xmlrpC++) peut-il gérer plusieurs requêtes de façon asynchrone? Est-ce que quelqu'un sait d'une meilleure bibliothèque xmlrpc pour C++? Je ne suppose pas que la bibliothèque Boost a un composant qui me permet d'émettre des commandes à distance? En fait, je ne me soucie pas de la fonctionnalité XML ou over-HTTP. J'ai simplement besoin d'émettre des commandes (asynchrones) sur TCP sous n'importe quelle forme. Je me réjouis de toute contribution que quelqu'un pourrait offrir.

Répondre

1

J'ai eu quelques problèmes avec XMLRPC aussi, et étudié de nombreuses solutions comme gSOAP et XMLRPC++, mais à la fin je lui ai donné et écrit l'ensemble HTTP + XMLRPC à partir de zéro en utilisant Boost.ASIO et TinyXML++ (plus tard, je swaped TinyXML à expat). Ce n'était pas vraiment beaucoup de travail; Je l'ai fait moi-même dans environ une semaine, à partir de zéro et se terminant avec de nombreux appels RPC entièrement mis en œuvre.

Boost.ASIO a donné d'excellents résultats. Il est, comme son nom l'indique, totalement asynchrone, et avec d'excellentes performances avec peu de surcharge, ce qui était pour moi important car il fonctionnait dans un environnement embarqué (MIPS). Plus tard, et cela pourrait être votre cas, j'ai changé XML à Google's Protocol-buffers, et était encore plus heureux. Son API, ainsi que ses conteneurs de messages, sont tous sécurisés (par exemple, vous envoyez un int et un float, et il n'est jamais converti en chaîne et en retour, comme c'est le cas avec XML), et une fois que vous avez compris , ce qui ne prend pas très longtemps, sa solution très productive.

Mon recomendation: si vous pouvez fossé XML, aller avec Boost.ASIO + Protobuf
Si vous avez besoin XML: Boost.ASIO + Expat

Faire ce genre de choses à partir de zéro est vraiment la peine.

+0

J'envisage d'utiliser boost asio. J'espère que je peux écrire des ints et des chaînes dans le flux à partir de la fin C++, et le recevoir sur la fin Java en utilisant des lectures DataInputStream. – Mike

+0

@Mike alors je suggère fortement d'utiliser XML ou protobuf; parce qu'il y a peut-être quelques pièges à faire en faisant cela, et ils vont tous les deux s'occuper de ça pour vous. – Gianni

+0

@Gianni. En cours d'exécution avec un problème avec asio. J'ai une file d'attente d'événements qui, lorsqu'elle est vide, et lorsqu'elle est interrogée à l'aide de la communication socket, attend un moment avant de retourner et signale la file d'attente est vide, ou se réveille et signale le contenu de la file d'attente. Ainsi, le client a deux connexions au serveur.Un pour émettre des instructions, l'autre pour obtenir (attendre) des événements. Le problème est que lorsque vous utilisez asio, lorsqu'une session est en attente, l'autre n'accepte aucune commande. Donc, en d'autres termes, une session accapare l'autre. Tellement pour être asynchrone? – Mike