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

Ice 2.1.2 / 3.0.0 on OpenSUSE 10


I've been a lurker in the realm of ICE for quite some time now. I've installed ICE 2.1.2 locally and played with the examples coming with the distribution and in Connections, but haven't tried much more (yet). After upgrading my system from SuSE 9.2 to OpenSUSE 10, and after the announcement of ICE 3.0.0, I'm now pushing myself to dig into the matter more deeply. And I run into trouble, e.g., for starters I just can't make ICE 3.0.0 behave like ICE 2.1.2 out-of-the-box.

My setup is as follows:

~/.bashrc exports the following entries

(which is a softlink to either Ice-2.1.2 or Ice-3.0.0)
(which is a softlink to either IceJ-2.1.2 or IceJ-3.0.0)
(which is a softlink to either IcePy-2.1.2 or IcePy-3.0.0)

/etc/hosts has the entries (created by the OpenSUSE installation) localhost linux

The six archives for Ice-C++, Ice-Java, Ice-Python are extracted in $ICE_LOCAL, and three softlinks pointing to the top-directories for C++, Java, and Python are set (a) for version 2.1.2, xor (b) for version 3.0.0. The two C++ code bases compile fine with g++ 4.0.2 (IceJ-2.1.2 fails, because my current setup only has Berkeley DB 4.3.27, but not 4.2.52 installed; IcePy-2.1.2 works fine), but when I try the initial example ./demo/book/printer, I get differing results.

When I set a softlink from $ICE_LOCAL/Ice-2.1.2 to $ICE_LOCAL/Ice and enter $ICE_HOME/demo/book/printer, the invocation

$ ./server --Ice.Trace.Network=2

replies with the output

Network: attempting to bind to tcp socket
Network: accepting tcp connections at 10000

In another shell I invoke

$ ./client --Ice.Trace.Network=2

which gives

Network: trying to establish tcp connection to
Netwok: tcp connection established
local address =
remote address = 10000

and ships "Hello world" to the server shell. Fine.

But when I try to do the same after setting the softlink "Ice" from $ICE_LOCAL/Ice-2.1.2 to $ICE_LOCAL/Ice-3.0.0, the situation is different. Now, the invocation in $ICE_HOME/demo/book/printer

./server --Ice.Trace.Network=2

gives the differing output

Network: attempting to bind to tcp socket
Network: accepting tcp connections at 10000

i.e., the server talks over "localhost" instead of "linux". The client invocation (after "cd $ICE_HOME/demo/book/printer" into the 3.0.0 package path)

./client --Ice.Trace.Network=2


Network: trying to establish tcp connection to

twice, plus

Network.cpp:669: Ice::ConnectionRefusedException:
connection refused: Connection refused

The examples codes are identical (untouched after extracting the source archives) and compiled out-of-the-box. So, I'm stuck and would appreciate your help with the upgrade. Afterwards, I'll get to the Java and Python parts.

Thanks in advance


  • dwayne
    dwayne St. John's, Newfoundland
    Hi Andreas,

    I am sure the issue you are seeing is related to the following change made in Ice 3.0.0:

    - Ice will now listen on all local interfaces if no -h parameter is
    present in the endpoint configuration and no default host has been
    set. It will also listen to all interfaces if the -h parameter is
    set to In such configurations the endpoints published in
    proxies will not contain the loopback interface ( unless
    it is the only local interface present.

    In Ice 2.1.2 if no host was specified for a endpoint, it would just use the host returned by gethostname(). With Ice 3.0.0 if no host is sepcified, it will attempt to bind to all local interfaces (which on linux are obtained using getifaddrs()).

    From the tracing you have posted, it appears that in your setup the list of interfaces returned by getifaddrs() only contains, whereas gethostname() returns I will look into this further.

    Meanwhile you can either add -h <host> params in the endpoint setting in your config files or start your programs with a --Ice.Default.Host=<host> command line option to set the default host.

  • Thank you, Dwayne, for the immediate response. With the server option


    all is fine. The C++ and Java servers/clients talk with each other, and the Python 'hello' example works as well.

    Thanks again!