On 15 Jul 2009, at 15:45, akalaghan wrote:

> Hello,
> I found this very old post
http://tech.groups.yahoo.com/group/xml-rpc/message/2306
> , asking a similar question as I will do in a moment. The only reply
> mentions that there *is* a solution, but not how it looks like.
>
> I have a situation where clients (behind a firewall, blocking
> incoming connections) need to register with a server for the purpose
> of receiving notification of certain events.
>
> The asynchronous client documentation
http://xmlrpc-c.sourceforge.net/doc/libxmlrpc_client++.html#asynch
> together with the example code xmlrpc_asynch_client.c show, how I
> can register a one-time callback. But my understanding is that this
> only waits for the server side procedure to return, upon the return
> the callback is executed, and then the callback can't be executed
> again from the server side.
>
> How can I setup a client-server pair, where the server can execute
> the same client callback repeatedly? A workaround is of course to
> again register the client callback immediately whenever the client
> is calledback from the server. But this causes a large overhead.
>
> Is it possible to use xmlrpc for bidirectional communication, where
> both the client and server can initiate a RPC at any time?
> Preferably using only a single connection that is initially
> established from the client to the server (firewall!) without
> keeping a second connection open for RPCs initiated by the server?
> Theoretically I could come up with such a solution using the basic
> HTTP protocol after *lots* of programming efforts - it is definitely
> possible. But I'd prefer an xmlrpc solution, as I find that protocol
> much easier to apply.

One option is to use JABBER-RPC (http://xmpp.org/extensions/xep-0009.html
). this is XML-RPC using XMPP as a transport mechanism rather then
HTTP. You run a client and a server at both ends so you get full
bidirectional communications. Both ends can be behind firewalls.

There aren't that many implementations about. There's a Groovy
implementation which is a thin wrapper over a very lightweight Java
implementation. (Disclosure: I wrote it). Some time ago I tested it
over GoogleTalk and it worked OK, however I'm not sure what it's
status is today. The guys on the Groovy list are very helpful and may
be able to update you http://groovy.codehaus.org/.

John Wilson