Archived

This forum has been archived. Please start a new discussion on GitHub.

network disconnected

Hi there,

I have a server/client simple application running on the same machine and so I don't specify "-h" in the proxy string (that means localhost is used, right) and the client can connect to the server properly and I have a callback interface created on the client side and passed to the server. The server will periodically "ice_ping" the client to make sure that the callback is still valid and good.

Everything is fine but if I unplug the network cable, the "Ice_ping" failed!?

Why does it fail if network cable is unplugged since everything is running locally?

Thanks
Alex

Comments

  • I have a server/client simple application running on the same machine and so I don't specify "-h" in the proxy string (that means localhost is used, right)

    For the client, it means loopback. For the server, it means listen on all available interfaces, including loopback.
    Everything is fine but if I unplug the network cable, the "Ice_ping" failed!?

    Why does it fail if network cable is unplugged since everything is running locally?

    Not sure what is going there, off-hand. Run client and server with --Ice.Trace.Network=2 and --Ice.Warn.Connections=1.

    This will allow you to see which endpoints are actually used and trace any exceptional stuff going on with the connection.

    Cheers,

    Michi.
  • My app is a c# windows app; where does the tracking info go since I don't see anything new in the "output" window in VS2008?

    Btw, the server got the Ice.ConnectFailException (when calling "ice_ping" to the client's callback interface) and the inner exception is "A socket operation was attempted to an unreachable host 172.22.64.101:2992" where 172.22.64.101 is my machine's IP address when network cable is connected. When the cable is unplugged, of course, 172.22.64.101 is no longer valid and the localhost (used to be 127.0.0.1) should be used instead. So, whey the ice_ping use the IP address instead of the localhost to test?

    Also, I create the callback on the client slide as below, do I miss anything?

    Thanks
    Alex

    _adapter = this.IceCommunicator.createObjectAdapterWithEndpoints("callback", "tcp");
    _adapter.add(eventHandler, this.IceCommunicator.stringToIdentity(identity));
    _adapter.activate();

    _cbProxy = _adapter.createProxy(this.IceCommunicator.stringToIdentity(identity));
    _instrumentEventHandlerPrx = InstrumentEventHandlerPrxHelper.uncheckedCast(_cbProxy);

    michi wrote: »
    For the client, it means loopback. For the server, it means listen on all available interfaces, including loopback.



    Not sure what is going there, off-hand. Run client and server with --Ice.Trace.Network=2 and --Ice.Warn.Connections=1.

    This will allow you to see which endpoints are actually used and trace any exceptional stuff going on with the connection.

    Cheers,

    Michi.
  • Also, is the "ice_ping" the best way to test if the objectprx is still good?
  • My app is a c# windows app; where does the tracking info go since I don't see anything new in the "output" window in VS2008?

    If you start the app on the command line, the output goes to stdout. If you start the app from the debugger in VS, the output goes into the command window that is started by VS.
    Btw, the server got the Ice.ConnectFailException (when calling "ice_ping" to the client's callback interface) and the inner exception is "A socket operation was attempted to an unreachable host 172.22.64.101:2992" where 172.22.64.101 is my machine's IP address when network cable is connected. When the cable is unplugged, of course, 172.22.64.101 is no longer valid and the localhost (used to be 127.0.0.1) should be used instead. So, whey the ice_ping use the IP address instead of the localhost to test?

    Your client provides a callback object to the server, so the client acts as a server. If you do not specify a host for the client's adapter, the adapter listens for incoming requests on loopback and all available network interfaces. However, the address that is published in the proxy the client creates does not include loopback. That is because loopback is not added to the endpoints in a proxy, unless the loopback adapter is the only available interface.

    So, the proxy created by the client only includes the client's real IP adapter, but not the loopback adapter, and the server talks to the client via the real IP adapter.

    If you want to ensure that client and server really talk via loopback only, you need to specify -h 127.0.0.1 as the adapter endpoint for both the client's and the server's adapter.

    Cheers,

    Michi.
  • It works! Thanks
  • Similar Problems with IceStorm

    Hey Everyone,
    I'm working on a distributed robotics framework, and we're using IceStorm for the communication framework. One of our projects is an autonomous submarine with a single computer which uses this framework to tie together a bunch of separate processes (e.g. the vision subsystems, the controller, etc..). Everything works fine when the onboard computer is connected via an ethernet tether to an external computer, but when we pull out the tether all processes relying on IceStorm pause. We're working in the latest version of Ubuntu on an Congatec XTX945 Module (http://www.congatec.com/x945.html).

    We've made a temporary fix by just leaving a small ethernet switch connected to the internal computer inside the submarine, but we now need the extra space. Is there a command line argument I can pass to icebox to ensure that it only uses the localhost interface?

    Thanks!
    Rand Voorhies
    University of Southern California: iLab
  • benoit
    benoit Rennes, France
    Hi,

    Sounds like an interesting project! So if I understand it correctly, all your processes are running locally and should use the loopback interface only, is this correct?

    If this is the case, you should explicitly specify the IP address that your IceBox services and server should listen on if you don't want them to listen on all available network interfaces. This can easily be done by adding "-h 127.0.0.1" to the endpoint configuration of your services. For example:
    IceStorm.TopicManager.Endpoints=default -p 10000 -h 127.0.0.1
    IceStorm.Publish.Endpoints=default -h 127.0.0.1
    

    Another simpler way to do this is to set the Ice.Default.Host property to 127.0.0.1. This way, all endpoints which do not explicitly specify a host with -h will use by default 127.0.0.1.

    If you still have troubles, could you describe a little more the deployment (is everything running on the same machine? if not, can you describe the network environment?) and post your configuration files? Please also specify which Ice version you're using.

    Cheers,
    Benoit.