Re: [xmlblaster] proposed xmlrpc plugin

[Michele Laghi <michele at laghi.eu>]

Hi Póka,
there is something quite similar to what you want to implement: its the
persitent http connection described at:

http://www.xmlblaster.org/xmlBlaster/doc/requirements/client.browser.html

or also the new code for the org.xmlBlaster.protocol.http.ajax.AjaxServlet

(particularly look at the updatePollBlocking part). Here an ajax client
invokes the servlet: the servlet waits until at least x messages (x
would be one here) are available and then returns. Since some proxies
may close never returning connections a timeout can be given: after that
time the function returns and the client part can invoke it again.

I think there you can find the similarities to XmlRpc.

Cool that you update the xmlrpc protocol !

Regards
Michele


Póka Balázs wrote:
> 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