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
