|Re: [ecf-dev] Problem with Service Endpoint matching when using different network names|
sorry for being late with my answer. See my comments inline.
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:Correct
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?In most installations the server has one IP address. Sometimes we can use this IP address when accessing the server trough VPN, sometimes there is a mapping somewhere in between...
from my point of view a unique ID for a remote service could well be ecftcp://server .
But the challenge here is probably to split the "do the network connection" code from "match the correct service" code, since as far as I can tell the endpoint ID (ecftcp://foo1.bar.com:3282/server) is used for both parts.
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)?I would like to avoid to having different ways/options/configuration to connect to remote services since that would mean a more or less complicated configuration for developers and consultants connecting to remote services running at the customer
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?No, all installations are on premise at the customers
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.I'm open to use/adapt a different distribution provider when that solves the problem.
My main "wish" would be to decouple the "raw" network connection (use any IP that works or any hostname that works - in term of getting a network connection) and not mix that with the actual service that is then consumed/provided at that network location.
If that does not work well with the generic provider, which one would suit best and what needs to be changed?
Thanks for your hints!