Re: [ecf-dev] Problem with Service Endpoint matching when using differen

[Peter Hermsdorf <peter.hermsdorf@xxxxxxxxx>]

Hi Scott,

Am 21.07.2018 um 00:11 schrieb Scott Lewis:

When the mapping is done, who/what does the mapping?..and how is it done?   It seems to me that's the problematic case.  Does it map both IP address and port, or just IP address?   Do you know if it's using NAT or some other tech?

Are there other services on this net...e.g. a web server...that are working properly with the addressing properties that you are looking for?   If so, how is that done?   A reverse proxy or load balancing hw or ?

Typically mapping is only done for the ip addresses. Actually i can't tell exactly how it's done. Probably it's custom to every customer....
Other services that work that way are JDBC connections to oracle databases. They don't care if you reach them by hostname or the one ip address or the other ... ;)

from my point of view a unique ID for a remote service could well be ecftcp://server .

Unfortunately it can't be that, because if more than one server used that same identifier and a single client was trying to get to two different service instances there would be no way to tell them apart.

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.

agree on.   For tcp-based comm (generic provider), that id is usually the host:port combination (InetAddress) since that's guaranteed globally unique and doesn't require any additional name mapping.    However, on the network you are targeting it seems that some clients need to use IP address 1 and other clients IP address 2...to access the same server and service.

I suspect that your network topology may require moving to a strict client -> server notion of rpc, rather than using a group topology.   It would mean that all services would be exported by a server and imported by clients, and that no services would be exported by clients or imported by server.

1)  currently we only use "strict" client->server setup, but: i could image use-cases where it could be useful if the server could import services from the clients to realize something like push information to the client from the server (without polling etc)  - but that's probably another story...

If having a strict client->server works for your services, then I would suggest you try the either the JaxRSRemoteService providers [1] which are based upon HttpService (jetty server usually).   It still seems to me that you would need a reverse proxy like nginx to expose the same server to access via multiple IP addresses/networks, and I'm not sure if that's possible on your target network, but nginx is frequently used for that.

2) i don't think it's a good idea to switch to a http based communication - performance wise. i would like to stick with a binary transportation layer rather than have http protocol overhead (remember my kryo serialization implementation)... and we don't have a use case where other services/participants would benefit from a http based communication...
we have a jetty on server side, but it has nothing to deal with the osgi remote services - just provides some jax-rs rest services

With strict client-server it's possible that ROSGi (based upon tcp) would also work, but since I don't yet understand what your address mapping is about (e.g. NAT, etc), and I haven't tried ROSGI under anything other than 'normal' addressing/networking scenarios, I don't feel comfortable suggesting that.   It also seems to me that a tcp reverse proxy might be needed also (a relatively recent nginx feature).

If I'm understanding you right, you will at least need to provide different target IP addresses/port combinations to different clients C1 and C2, right?   I don't see a way to avoid that, unless you provide some other public service that does that...i.e. analogous to DNS but just for your app.   You could do that, btw without too much difficulty...i.e. create a public/internet etcd server, for example (etcd is the http-based discovery protocol that Google uses for Kubernetes).   It would require running yet another server (etcd), maintaining, etc...but at least you don't have to develop it.

3) switching to a different provider is an option, if there is "no" performance problem and this "connection" issue would be solved. additional infrastructure for translating/mapping/proxying is a problem and is at the end no real option.... from my point of view that's the job of the underlying tcp/ip network...

Because of the many questions regarding how the network mapping etc. is done i would like to describe another scenario which shows the same problem, but is probably better reproducible:

Use virtualbox on your host machine and install a virtual machine (e.g. running linux). let's name it server1. deploy a service with the generic provider on server1. the service will bind to the local network interface and use the local name of the linux machine: server1. that means e.g. the endpoint ID is ecftcp://server1.local:3282/server .

in virtualbox on the host machine configure a port mapping from port 3282 into the virtual machine with the same port 3282.

from a network perspective you are now able to reach the service in the linux box from your host machine using tcp localhost:3282.

if you now start a service consumer on your host machine which uses the endpoint ecftcp://localhost:3282/server or the real hostname of the host machine e.g. ecftcp://scotts-machine:3282/server you will get a succesful tcp/ip connection between client and server, but (of course) the service import is not working because of the different endpoint id's ....

i need a solution for that without adding local hostname entries, dns changes and additional servers or infrastructure ;)

sorry to bug you with this issue that long ;)

Thanks again for your comments and hints!

Best regards,
Peter