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

Slow callback sample

Hi. I am trying to learn ICE and am a novice to distributed computing. I am using vc#. When I run the Ice/Callback demo it runs great, but when I put the server executable (and all required files) on my web server and configure the config.client to look at the server, the callbacks are taking about 15 seconds. It does this whether I use the server name or its IP address. the server is Windows 2000 Server running IIS 5.0 w/all current updates. My development machine is WindowsXP SP2 w/all current updates The code is the sample code with just the config.client changed. I'm guessing that it must have something to do with a setting of mine on the server, but I'm not sure where to look. Any help would be most appreciated.



  • matthew
    matthew NL, Canada
    Is it each callback that takes 15 seconds, or only the first? A typical cause of this problem is your client publishing unreachable endpoints on the callback proxy. To help fix this I would advise turning on network tracing in your server and client. You can do that by setting the Ice.Trace.Network property.
  • Thanks for the quick response, Matthew. It actually is 15 seconds give or take on every callback, but the initial connection is quick and I know that there is communication in both directions before menu() is called. I disabled my dev machines windows firewall and everything went through like greased lightning. I specified client endpoints in the config.client, but the initialization of the callback goes on another port, then the client uses the port that I specified. It's still just as slow woth the firewall enabled. However - the bidirectional demo remains fast when I move the server onto the web. I'll study that on. But is there a way to specify the port for the initial communication in the callback demo? If so, would it make a difference if I set an exception in the firewall for that port?

    I appreciate your help. Like I said before - I have no real experience with distributed apps, but I can sure see the benefit here. Thanks a bunch

  • matthew
    matthew NL, Canada
    What is highly likely is that you are publishing unreachable addresses. When a call is then made it takes time for the connection to timeout on the unreachable address before trying the reachable address.

    What exactly did you change in the client & server configuration?
  • In the config.server I didn't change anything. As far as endpoint assignment it says

    Callback.Server.Endpoints=tcp -p 10000:udp -p 10000:ssl -p 10001

    The config.Client endpoint assignment originally looked like this

    Callback.Client.CallbackServer=callback:tcp -p 10000:udp -p 10000:ssl -p 10001

    And I changed it to this

    Callback.Client.CallbackServer=callback:tcp -h <my server ip> -p 10000:udp -h <my server ip> -p 10000:ssl -h <my server ip> -p 10001
    Callback.Client.Endpoints=tcp -p 12000:udp:ssl

    Since I was only running over TCP in the test I didn't think it necessary to set the UDP or SSL endpoints. I also turned on the network tracing to level 3 in both the client and server. The initial contact to the server would be on a random port, maybe 3504, which I assumed was assigned by Windows and I saw immediate response on the server. I know that's the easy part. Everything would then be still for 13 to 15 seconds but no trace messages of a timeout (should there be anything visible in the trace?) and the server would send the callback over a random port out and I'd see the response in the client first on the port that I assigned and then to the port from which the communication was initiated.

    Thanks again for your help

  • matthew
    matthew NL, Canada
    A port by itself means nothing. You also need to take into account the the IP address. Most likely you need to change

    Callback.Client.Endpoints=tcp -p 12000:udp:ssl


    Callback.Client.Endpoints=tcp -h <client-ip> -p 12000

    The default behaviour is to publish all possible network interfaces in the proxy which means that if some of them are inaccessible then the call on this proxy will take some time as previously described.
  • Thanks, Matthew. That sped things up tremendously. It got the round trips to 43-4 seconds. I really appreciate you assistance:D
  • That's 3-4 not 43:p