Archived

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

Multiple network interfaces

Hi Zeroc, I have a question on how to best handle multiple network interfaces as well as dynamically changing ipaddresses. In Ice 3.1.0 that Ice supports an OA that listens on multiple interfaces using "-h 0.0.0.0" for the endpoint. The issue that I see is that it appears that the multiple interfaces are only added at the time the OA was created. If a network interface is created or deleted after the OA is created or the ipaddress is modified after the OA is created it isn't processed. For example, if I start a simple ICE program on a multi NIC system with one interface disabled, and then enable the second NIC, an OA endpoint is not dynamically added for the second NIC. If both NICS are enabled and then the server started both endpoints are created. I don't think it is possible to add/remove endpoints from an OA after the OA is created.

My thought is to create a class NetworkInterface that would periodically query the status of network interfaces using getifaddrs on Linux. If a new interface is detected or modified a new OA would be created and all objects would be added to it. If an interface is deleted, then the OA associated with that interface would be destroyed.

Does that seem like a reasonable alternative or do you think there are better approaches I should consider?

Thanks --Roland

Comments

  • marc
    marc Florida
    We had a recent internal discussion about whether we should add the ability for an OA to add and remove endpoints dynamically when IP interfaces change. While technically this can be done, the problem is that proxies that have been published before the interface change will become invalid if endpoints are removed.

    You can certainly work around this problem with the solution you propose. However, you will have the same conceptual problem, that old proxies won't work anymore (except if you only add endpoints, but never remove any).
  • Client to Server with multiple endpoints - should it just work?

    I have a server that listens on two NICs. The client initiates a connection to the server via a proxy constructed by the client to one of the NICs on the server. The server then hands back a proxy to the client - a proxy with both endpoints available on the server. Now, if the client can reach both NICs on the server, my connections using the proxy that got handed back by the server always succeed. However, if one of the NICs is not routable by the client, then my invocations back to the server sometimes fail. I am using bi-directional connections, and make the 'registerClient' client call via a one way invocation.

    This is Ice-3.2.0, client and server both running on Windows XP. Should the proxy with multiple endpoints just work?
  • Further analysis

    I ran one other experiement - make both NICs on the server reachable by the client. I then used TCPview to look at connections. Interesting thing, is that there doesn't seem to be a preferred order for which the client establishes connections to the sender based on the endpoints in the proxy to the server. How does Ice determine which server endpoint to open a connection on based on the endpoints in the proxy?
  • Your observation is corredt, by default, Ice uses "Random Endpoint Selection":
    http://www.zeroc.com/doc/Ice-3.2.1/manual/Connections.38.3.html#76915

    Alternatively, you can configure your proxy for "Ordered Endpoint Selection".
  • benoit
    benoit Rennes, France
    gsalazar wrote: »
    I have a server that listens on two NICs. The client initiates a connection to the server via a proxy constructed by the client to one of the NICs on the server. The server then hands back a proxy to the client - a proxy with both endpoints available on the server. Now, if the client can reach both NICs on the server, my connections using the proxy that got handed back by the server always succeed. However, if one of the NICs is not routable by the client, then my invocations back to the server sometimes fail. I am using bi-directional connections, and make the 'registerClient' client call via a one way invocation.

    This is Ice-3.2.0, client and server both running on Windows XP. Should the proxy with multiple endpoints just work?

    The Ice runtime should try both endpoints (by default, using a random order to select which endpoint to try first). If one of the endpoint is reachable it should succeed. You should enable network and retry tracing to investigate why the invocation fails. Set the following properties in your client configuration file:
    Ice.Trace.Network=2
    Ice.Trace.Retry=2
    

    Could you detail a little more how you're using bi-directional connections? If you post the traces of your client here, we'll be happy to look at them (or you can also email them at support@zeroc.com).

    Finally, I recommend taking a look at Matthew's "Connection Management in Ice" article from the Connections
    newsletter issue #14
    to better understand how connection establishment and connection reuse work.

    Cheers,
    Benoit.