Just an update, I tested the problem on a LAN using the client example: java javaclients.HelloWorldSubscribe - session.name client/joe/session/1 -dispatch/callback/retries -1 -plugin/socket/hostname 192.168.0.3
connecting to a default server setup with no xmlBlaster.properties file: java -jar lib/xmlBlaster.jar I 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 appearing on 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? On 11/29/06, Marcel Ruff < [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 > 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
