Marcel Ruff
Thu, 30 Nov 2006 00:36:28 -0800
Matthew Monson wrote:
Just an update, I tested the problem on a LAN using the client example:java javaclients.HelloWorldSubscribe - session.name <http://session.name/> client/joe/session/1 -dispatch/callback/retries -1 -plugin/socket/hostname 192.168.0.3 <http://192.168.0.3>connecting to a default server setup with no xmlBlaster.properties file: java -jar lib/xmlBlaster.jarI pulled out the network cable and plugged it back in, reconnected successfully.I then pulled out the network cable and changed my IP address and plugged it back in and the client could NOT reconnect to the server, still nothing appearingon the server logs. I then pulled the cable out and changed my IP address back to what it was plugged it back in and the client reconnected successfully. Bug?
Thanks for this details, that is exactly what i suspected. I'll have a look at this a.s.a.p, regards Marcel
On 11/29/06, *Marcel Ruff* < [EMAIL PROTECTED] <[EMAIL PROTECTED]>> wrote:Brad Clements wrote: > On 29 Nov 2006 at 14:28, Marcel Ruff wrote: > > >> Ok, >> >> thanks for the details! >> >> I will try the case of changing client side IP address with a java client >> as soon as i find time for it and come back to this issue, >> > > When using the socket protocol, why does a subscribe need to specify the client's > IP address in the callback specification? > > I thought the socket protocol ignored the callback IP, even though it's required.. > > If it's not ignored, would it be reasonable for the socket protocol to specify 0.0.0.0 <http://0.0.0.0> > as the IP (any port #) which means "send callbacks to my current end-point" > Yes, the callback address is simply ignored on server side, as we tunnel the response back in the same socket. It could be useful when we want to force the server to open a separate connection for callbacks (similar to XMLRPC etc.) but this feature was never implemented. Marcel