[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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:
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.
| 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.
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 providers
It'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.
Scott
