|Re: [ecf-dev] [Discovery] Double Network Address and Remote Services|
On 9/26/2010 3:33 PM, Wim Jongman wrote:
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 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.