Support for endpoint filtering

[bentoi]

For clients which are also servers (such as an IceStorm subscriber) and where the network configuration of the machine where it's running is not very well defined, using bi-directional connection is the easiest.

Opening and listening on a port is always more problematic. Not only you have to solve the firewall issues, you also indeed need to figure out the right IP to listen on. In the IceStorm use-case, it would make sense for the subscriber to listen on ADDRANY.

We could provide a configuration to filter in or out range of IPs. Another solution could be to provide an API to allow creating the correct proxy. For instance, here, you'd typically want to pass the IP address of the outgoing interface that was used for the client connection in the endpoints of the subscriber proxy provided to IceStorm.

Similarly, a server listening on multiple network interfaces that returns proxies to clients would typically want to return proxies to those clients with IP addresses based on the client connection rather than returning all the IP addresses of the server machine.

So we could have something like:

IceStorm::TopicPrx topic = topicManager->getTopic("test");
Ice::ObjectPrx prx = objectAdapter->addWithUUID(new SubscriberI());

//
// Filter the endpoints of the proxy to only keep the endpoint for the network interface
// used to establish the connection to IceStorm.
//
prx = prx->ice_endpoints(Ice::filterEndpoints(prx->ice_getEndpoints(), topic->ice_getConnection())));
topic->subcribeAndGetPublisher(prx, QoS());
Another example:
CarPrx
FactoryI::createCar(const Ice::Current& current)
{
    Ice::ObjectPrx prx = current.adapter->addWithUUID(new CarI());

    //
    // Filter the endpoints of the proxy to only keep the endpoint for the network interface
    // used by the client to contact this boject.
    //
    return prx->ice_endpoints(Ice::filterEndpoints(prx->ice_getEndpoints(), current.con));
}

The filterEndpoints implementation would either check the IP addresses with the connection information (Ice::ConnectionInfo) but then it wouldn't be "transport neutral" anymore (the user can actually already implement such a method). Another option is to delegate this filtering to the transport implementation by adding a method on the endpoint interface.

[bernardnormier]

This proposal is mixing up two different issues.

For the proxy returned by a server, the issue is largely fixed by the default published endpoints (implemented in Ice 3.8). Relative proxies provide an even better solution but would require a new encoding revision. See https://docs.icerpc.dev/slice2/language-guide/using-proxies-as-slice-types#relative-proxy