Wrong network interface used when multiple are available

MirkoWaechterMirkoWaechter Member Mirko WaechterOrganization: University of KarlsruheProject: ArmarX Robot Framework

Hello,

we have PCs with multiple network interfaces and they can only communicate over 1 interface with each other.
This causes the problem that our Ice adapters (not sure if this is the correct term) announce their endpoints over all their possible interfaces. Then Ice tries to connect randomly over any of these IPs to these adapters, but cannot establish a connection and waits for some timeout (which is very high, maybe 5 minutes (which Ice-Property would this be?)). After the timeout it tries again on a different interface.

We can solve this for simple setups by specifying "Ice.Default.Host=". However, this is annoying (e.g. with dhcp) and doesnt work if remote PCs are only reachable via different interfaces.

On a sidenote: we are using IceGrid for every connection. The only IP we are specifying is the host machine on which icegrid is running:

Ice.Default.Locator=IceGrid/Locator:tcp -p 4061 -h localhost
IceGrid.Registry.Client.Endpoints=tcp -p 4061

Is there a solution for this?
Thanks

Answers

  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff

    Hello Mirko,

    The issue you're seeing is due to the endpoint configuration of your object adapters. Since you're using IceGrid, you are describing your object adapters' configuration in adapter descriptors:
    https://doc.zeroc.com/ice/3.7/ice-services/icegrid/icegrid-xml-reference/adapter-descriptor-element
    (you may be using IceGrid GUI to create/edit these descriptors)

    If you object adapter's endpoints configuration is simply "default" or "tcp" or "ssl", it means the object adapter will listen on all available interfaces. And when you resolve an indirect proxy to this object adapter with IceGrid, IceGrid will return all these endpoints (addresses). The solution is to change your object adapter endpoint configuration to specify a single hostname or IP address, for example:

    endpoints="tcp -h 192.168.1.2"
    

    or

    endpoints="tcp -h hostname-for-IP-address"
    

    Also, make sure your IceGrid configuration is what you want:

    Ice.Default.Locator=IceGrid/Locator:tcp -p 4061 -h localhost
    

    This means, contact IceGrid registry on port 4061 on localhost ... this won't work for a remote IceGrid registry.

    IceGrid.Registry.Client.Endpoints=tcp -p 4061
    

    This is the endpoints configuration for the IceGrid registry object adapter named "IceGrid.Registry.Client": it listens on all interfaces on port 4061.

    See https://doc.zeroc.com/ice/3.7/client-side-features/proxies/proxy-and-endpoint-syntax for details about the endpoints syntax.

    Best regards,
    Bernard

  • MirkoWaechterMirkoWaechter Member Mirko WaechterOrganization: University of KarlsruheProject: ArmarX Robot Framework

    Thank you for your help!

    The problem is that the endpoint does not know over which interface it should be reached. It might need to be reachable over both interfaces (depending on the client).

  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff

    Hi Mirko,

    You can list multiple interfaces in your server endpoint configuration, for example:

    endpoints="tcp -h 192.168.1.2:tcp -h 10.0.0.2"
    

    With this example, I assume all clients can reach both interfaces.

    If your clients can only reach one interface - and not always the same interface - it gets more complicated. One solution would be to use two object adapters, one per interface (you could share the servants in these two OAs).

    Another solution would be create your own Locator implementation for your clients. This implementation would forward the request to IceGrid and then filter-out the result to return only endpoints on the client's network.

    Cheers,
    Bernard

  • MirkoWaechterMirkoWaechter Member Mirko WaechterOrganization: University of KarlsruheProject: ArmarX Robot Framework

    Hi Bernard,

    thanks for your help.
    I guess this is then a more fundamental networking problem and we have to adjust our network.

    Cheers
    Mirko

Sign In or Register to comment.