Archived

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

Creating Proxies with Multiple Ethernet Interfaces

Imagine the following slice definition:

interface Listener {
void raise();
};

interface Server {
void registerListener( Listener* );
};

System X has a Server proxy pointing to system Y. X needs to register itself as a Listener on Y. X has multiple ethernet interfaces. Y may be on any one of these interfaces. X has added a Listener object to its adapter, which is listening on all interfaces. X needs to send Y a proxy with an address that is visible to Y. Is there an easy way to create a proxy on X that is on the correct interface, the one that is visible to Y?

Comments

  • If an object adapter has multiple endpoints, by default, all its endpoints are published in proxies. If you do not want all of the endpoints to appear in the adapter's proxies, you can use the <adapter-name>.PublishedEndpoints property to control which ones are visible.

    Cheers,

    Michi.
  • Thank you for your prompt response. The trouble is that the endpoints I want to have published change based upon the Server with which I am registering a Listener. For example, imagine a network setup where a given system has the following interfaces that are connected to the given subnets:

    eth0: 10.0.1.23 => 10.0.1.*
    eth1: 10.0.2.98 => 10.0.2.*
    eth2: 10.1.17.3 => 10.1.*

    Note also that these networks are not bridged. In other words, 10.0.2.11 cannot connect to 10.0.1.23.

    So, if the Server is at 10.0.1.90, the endpoint for the Listener proxy would need to be 10.0.1.23. If the Server has an IP address of 10.1.89.2, then the Listener proxy would need to point at 10.1.17.3. If I were only registering Listeners with one Server, I could simply modify the published endpoints setting. The trouble though is that I am communicating with multiple Server proxies which may all be on different subnets.
  • I see your point. Have you considered using bidirectional connections for your callbacks? That would eliminate the endpoint issue entirely because the callback would always be made via the connection opened by the client. This also avoids having two connections between each client-server pair, so it saves a little on resources.

    Cheers,

    Michi.
  • Awesome! That is exactly what I'm looking for.