Re: [xmlblaster] proposed xmlrpc plugin
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) Exactly this feature is implemented already on server side. The java and C++ client libs support it via XmlBlasterAccess.receive() (see below). All other clients can use it as well with the plain XML Qos markup, see http://www.xmlblaster.org/xmlBlaster/doc/requirements/engine.qos.queryspec.QueueQuery.html /** * This method synchronously accesses maxEntries messages from any xmlBlaster server side queue. * * This is a convenience method which uses get() with a specific Qos. * Important note: * Currently you shouldn't use unlimited timeout==-1 as this could * lead to a server side thread leak on client disconnect. * As a workaround please use a loop and a timeout of for example 6 * and just ignore returned arrays of length 0. * * @param oid The identifier like *"topic/hello" to access a history queue, *"client/joe" to access a subject queue or *"client/joe/session/1" *to access a callback queue. *The string must follow the formatting rule of ContextNode.java * @param maxEntries The maximum number of entries to retrieve * @param timeout The time to wait until return. *If you choose a negative value it will block until the maxEntries *has been reached. *If the value is '0' (i.e. zero) it will not wait and will correspond to a non-blocking get. *If the value is positive it will block until the specified amount in milliseconds *has elapsed or when the maxEntries has been reached (whichever comes first). * @param consumable Expressed with 'true' or 'false'. *If true the entries returned are deleted from the queue * @return An array of messages, is never null but may be an array of length=0 if no message is delivered * @see org.xmlBlaster.util.context.ContextNode * @see href="http://www.xmlblaster.org/xmlBlaster/doc/requirements/engine.qos.queryspec.QueueQuery.html";>engine.qos.queryspec.QueueQuery requirement * @see javax.jms.MessageConsumer#receive */ MsgUnit[] receive(String oid, int maxEntries, long timeout, boolean consumable) throws XmlBlasterException; regards Marcel 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 -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] proposed xmlrpc plugin
Hi! 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. All right, thanks, I'll see what I can do using that. Cool that you update the xmlrpc protocol ! I found it quite necessary, because it has extended features I need (like gzip compression, HTTP proxy support) which were either not part of the XML-RPC specification or not implemented in version 2.x. I'll get back to you when its working. Regards, Balázs
Re: [xmlblaster] proposed xmlrpc plugin
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
[xmlblaster] proposed xmlrpc plugin
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
[xmlblaster] xmlBlaster release 1.6.1
Dear Ladies and Gentlemen, we would like to announce xmlBlaster release 1.6.1 If is a bug fix release. It is released after massive testing (Java/C/C++) and a lot of feed back of our partners and users. For more details please visit http://www.xmlblaster.org/xmlBlaster/CHANGES http://www.xmlblaster.org/xmlBlaster/RELEASE_NOTES enjoy, the xmlBlaster maintainers
