Re: [ecf-dev] [Discovery] Double Network Address and Remote Services

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Wim,

On 9/26/2010 3:33 PM, Wim Jongman wrote:

Hi,

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:

r-osgi://192.168.1.100:9278

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.

Scott

Regards,

Wim

Caused by: java.net.ConnectException: Connection timed out: connect

        at java.net.PlainSocketImpl.socketConnect(Native Method)

        at java.net.PlainSocketImpl.doConnect(Unknown Source)

        at java.net.PlainSocketImpl.connectToAddress(Unknown Source)

        at java.net.PlainSocketImpl.connect(Unknown Source)

        at java.net.SocksSocketImpl.connect(Unknown Source)

        at java.net.Socket.connect(Unknown Source)

        at java.net.Socket.connect(Unknown Source)

        at java.net.Socket.<init>(Unknown Source)

        at java.net.Socket.<init>(Unknown Source)

        at ch.ethz.iks.r_osgi.impl.TCPChannelFactory$TCPChannel.<init>(TCPChannelFactory.java:171)

        at ch.ethz.iks.r_osgi.impl.TCPChannelFactory.getConnection(TCPChannelFactory.java:76)

        at ch.ethz.iks.r_osgi.impl.ChannelEndpointImpl.<init>(ChannelEndpointImpl.java:212)

        at ch.ethz.iks.r_osgi.impl.RemoteOSGiServiceImpl.connect(RemoteOSGiServiceImpl.java:683)

        at org.eclipse.ecf.internal.provider.r_osgi.R_OSGiRemoteServiceContainer.doConnect(R_OSGiRemoteServiceContainer.java:545)

        at org.eclipse.ecf.internal.provider.r_osgi.R_OSGiRemoteServiceContainer.connect(R_OSGiRemoteServiceContainer.java:526)

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev