|Re: [ecf-dev] Problem with Service Endpoint matching when using different network names|
Hi Peter, On 6/29/2018 12:09 AM, Peter Hermsdorf wrote:
| e.g.. clients in the local network of the server can use a local DNS to connect to the server by a locally known host name. We have other clients connecting via a remote network (VPN tunnel) and sometimes we can't use the local DNS setup trough that tunnel, but just the IP address or a completely different hostname for network configuration reasons.Hi Scott, thanks for your suggestions. I'm afraid to say that this does not solve all issues for us.If i understand you correct, you were describing different ways to change the service endpoint on the server to match the one that the client uses to connect to the exported service on the server.The problem is, we have setups where different client machines use different network names to connect to the same server instance.
I see. So external clients are using VPN addressing and internal clients LAN addresses. Correct? And you would like a single server(s) (with 1...or multiple nics?), to host remote service(s) to both types of clients....internal and external. Something like this:
C1-->addr:foo1.bar.com:1234-->VPN-->IP1 addr of server1-->Server1-->Serviceinstance
| C2-> IP1 (or IP2?) addr of server1---| Seem right?For the moment, forget about the dns names. What do the IP addresses/port look like for your C1 and C2? e.g. what does C1, C2 server address look like, what are IP1 and IP2, does the Server1 have multiple nics (IP1/IP2) or just one?
I think what we need is a completely hostname (and port) agnostic way to match the service endpoints between the client and the server.In other words: one thing is to define the network target (by hostname or IP and port) and the other thing would be to match the remote service once the client and server are connected by network (via the service name and version etc.).
Not sure if this is what you are suggesting...but there could be a remote service to do that matching between client and endpoint, I suppose.
Modifying a single generic provider to do this could be difficult. The main reason for this is that the generic provider has the notion of a group of connected processes... .the server's unique group name must consist of *some* address that is understood as unique among all group members connected within a particularly container instance ...e.g. ecftcp://foo1.bar.com:3282/server is the 'name/ID' of the server in the group connected that container instance (and it's unique ID).
However, it's quite possible to export a single service with multiple generic provider container instances...e.g. couldn't you export service with a container for VPN clients, and another that exports the same service using 'internal' addressing (with different IP and port)?
As for other distribution providersIt's possible that R0SGi could work for this, but the VPN might still present a problem.
You could use one of the http-based providers (e.g. Jersey or CXF) in combination with the generic provider...e.g. you could export with both generic and http-based distribution providers simultaneously to expose the remote service via two (or more) different transports.
Also: Is it possible to consider alternative network topologies? e.g. having both an external and internal servers? or running the service outside vpn/in cloud?
We can continue to chat here, or if you would like contact me directly at slewis at composent.com or scottslewis at gmail.com. If we can work something out, I could assist your development or do custom development or both.
I'm willing to implement some code to do that, if you could point me in the right direction....
I'm happy to point you in the right direction, but I have a feeling that there could be multiple ways to deal with this, so there might not be just one 'right direction'. Let's keep discussing.
Back to the top