Hello,
I'd like to have some advice on a small project I need to get done as soon
as possible.
Until now we have been using the plain SOCKET protocol to communicate with
clients due to the fact that it's the only option if the server is unable to
connect to the client (NAT, firewall, etc.). I need to use the update()
method to receive messages. The problem with this is that clients still need
full internet capability. However, we are gaining some customers who [will
not/can not] change their firewall configuration because of this, and only
let HTTP traffic pass through their proxies.
I've already started rewriting the XMLRPC plugin to support the apache
xml-rpc library version 3, as the old one (v2) is quite outdated. The normal
(non-callback) calls would be done exactly like now.
My idea about emulating callbacks _without the server needing to connect to
the client_ (but with a better response time and less overhead) would be the
following:
1) client issues XMLRPC request to server (can be considered something like
polling)
2) server does not return from call before:
a) at least one message is waiting to be sent to the client
or
b) some "timeout" seconds elapses (defaults in the order of 10-30, could
be adjusted)
This way, the client only needs to poll every "timeout" seconds if there is
no traffic. The average latency of messages is reduced as the server can
return the message(s) as the return value of the current poll() call almost
immediately when some message(s) are to be sent to the client.
My question is how I could implement this polling mechanism in the plugin
(so that I don't need to rewrite anything in the application), meaning that
I'd like to keep it working this way:
...
xmlBlasterConnection.connect(qos, listener);
and getting all messages as updates through "listener", just like with
SOCKET.
thanks in advance,
Balázs Póka
