Yes, this is clear. Thanks for elaborating but I still think it is a bug.
My real situation is this: I am connected to my companies VPN. This creates a subnet for me in the 172 network. However, I am also connected to my home 192 network. I have clients/consumers in the 172 network and I have clients/consumers in the 192 network.
These clients/consumers do not need to see each other, nor can they, per your explanation.
However, my host is free to communicate with either side.
If my hosts tries to identify its own ip it does some lookup of its ip address. This lookup will either return the 172 or the 192 ip address. So the wrong ip address is communicated to one side of the network.
ECF/Discovery/R_OSGi needs to be smarter and compute the correct ip address for both sides of the network, depending on the client/consumers ip address/network.
I have this "broker machine" that sits between two networks
and thus has network addresses of both. Say 192.* and 18.* If a
service is published in the 192.* network then that network
advertises this in the discovery. The broker sees a remote
services and initiates a r_osgi communication with that client.
However, when the broker supplies its own address it needs to
be smart about the network of the client that it receives the
connect from, or advertise both addresses.
Currently, in the zookeeper/r_osgi impl, this does not handle
correctly. I wonder how this works for other
discovery/distribution providers.
Any suggestions before I file a bug?
Before I say anything about discovery, let me first say that for
distribution what is required is that when the consumer/client of a
remote service receives the metadata that *describes* the remote
service endpoint, the metatdata (which includes the address of the
host) must be sufficient for the client/consumer to communicate with
that service host over some network. What this implies is that *no
matter how* this address is discovered (e.g. via some network
discovery protocol, or it's known in advance, etc) that the address
information must allow for communication with that remote host.
If, however, the host and the consumer are on different subnets then
they can only communicate with each other if the routers that are in
between the subnets are setup to allow hosts on those subnets to
communicate.
So, as an example...TCP defines a reserved address range...for
addresses of the form: 192.168.X.X. Addresses in this address
range (e.g. 192.168.1.100), are 'private addresses', which can only
be accessed on the same subnet.
Let's say that I expose a service via r-osgi from a host that is on
192.168.1.100...e.g:
This service will *only* be available to clients that are also on
the 192.168.1 subnet...because even if this address is
exposed/discovered outside that subnet, the receivers won't be able
to communicate with that host (because 192.168.x.x are reserved
private).
So no matter what happens with discovery (how the endpoint
information is communicated between service hosts and prospective
consumers), the communication between the host and the consumer must
be possible...otherwise it doesn't quite matter what discovery
protocol is used.
For hosts that are dual homed, whether clients/consumers on one
network will be able to 'see' the host (and service) via consumers
on the other network depends upon the routing that's enabled between
the two subnets. But frequently they won't be able to see each
other...because one is a firewalled/private network, and the other
network is connected to the internet.
If this is the relationship between your two subnets (i.e. they
can't normally reach hosts on the other's subnet), then a remote
service that is exposed on one subnet (via whatever discovery
mechanism) won't be accessible from clients on the other
subnet...since the address information that's part of the endpoint
meta-data won't be usable by consumers on the other subnet. The
only exception is the dual-homed system...it will be able to access
services exposed by hosts on either subnet, because it knows about
the addressing for both subnets.
Discovery
Discovery adds another layer of complication to this, because with
discovery protocols the endpoint meta-data is what is
communicated...i.e. the addressing and other service meta-data are
actually sent on the network via some discovery protocol. Different
discovery impls (e.g. zeroconf, slp, zookeeper, dnssd, etc) have
different assumptions/support for internetworking...i.e. for sending
the endpoint metadata outside of the local subnet/lan.
Hope this helps. I guess I'm not quite sure from your description
what the discovery/distribution bug/enhancement would be to support
your use case...so perhaps further information about what you would
like to have happen between the dual-homed host and the hosts on the
two subnets would be helpful for figuring this out.
