| Re: [ecf-dev] Problem with Service Endpoint matching when using different network names |
|
Hi Peter,
On 7/26/2018 1:41 AM, Peter Hermsdorf wrote:
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 ... ;) Given the smiley, I'm not sure if you are joking but here's the rub: JDBC connections are point-to-point (strict client-server)...and so the addressing is relatively simple. Part of its simplicity is that it creates isolation between clients, but with DB connections that's generally what you want. However, the ECF generic provider...and some of the others...provides a group model, where every process (clients and server) can both export and import remote services as opposed to server-export and client-import only. Just to explain a little more: In a group model (i.e. ECF container), every process in the group has to a) have a unique identity; b) agree (membership) to use the same ID to refer to the same process. So in the three group members case: Serverid -> ecftcp://some.name:3333/server Client1id -> 1 Client2id -> 2 When the two clients connect to this server, all three processes receive the IDs of the other two processes...i.e. Server gets 1, 2, Client1 gets serverid, 2; and Client2 gets serverid and 1. Note that if the Client1 serverid != Client2 serverid (i.e. the clients are on different networks) then it violates b above. This seems to be your situation with the generic provider. All I'm saying is that the introduction of NAT, firewalls, proxies, VPNs, etc changes the addressing. This is less of a problem for client-server communication because there are only two processes 'aware' of each other instead of a group. When I wrote the generic provider (originally > 14 years ago), the addressing introduced by NAT, VPN, etc wasn't nearly as prevalent. I *could* have introduced some additional connection/group join protocol to associate some separate/unique name (uuid, etc) with the server ip address, so that clients didn't use some.name:3333. However, at that time I didn't anticipate it would be necessary, and so I didn't do that...using the (guaranteed unique) some.name:3333 to both identify the process and client uses to connect to the server. In retrospect it would have been nice if I did, but OTOH given the complexity involved in doing it in the 'general case' I'm kind of glad I didn't :). It's possible that a new/extended generic container could be created that had this additional protocol to have connected clients use a non-ip-based name for the server in the group. It would probably be necessary, however, to first understand what the name mapping was doing for a given network topology (i.e. your customer) at least if one was interested in keeping the 'group' nature (i.e. not be 'strict client-server' at the service level). As we've been discussing, another option is to use a strict client-server topology rather than a group, and use or create a distribution provider based upon a strict client-server model. See below for more comments about this. <stuff deleted> Indeed it is :). 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... Given that you already have a jetty server working in this topology, perhaps it would be worth it to give it a try with the JaxRSProvider...and see how the performance is for a test service. I understand the concern about performance with http...especially if you are sending lots of messages. However, as you know jetty/websockets, caching proxies, hw, etc., etc have improved the performance of http under many usage scenarios so maybe it will be less of a problem than you think. Another thought: Once you were confident that a strict client-server model would get you want you want in terms of connection, you could create a simple websocket-or-regular-socket-based distribution provider based upon your Kyro serialization provider [1] or at least starting from that. With Photon I've tried to make it easier to create new distribution providers (more/more useful abstract classes). There are a other providers at [2] that you could model from (e.g. Chronicle, grcp, etc) or just use a simple socket connection based upon the trivial provider [3]. You can also combine multiple distribution providers if you need to (i.e. some services with JaxRS, others with a custom-socket-based distribution provider for others). <stuff deleted> That would be very nice, but unfortunately these days with NAT, VPN, etc we are not dealing with just one tcp/ip network :).
Thanks, this is helpful.
Right. See explanation above for why this is the case with a group model/generic distribution provider. So, if you can give up the group model and the ability to export services from peers...and it sounds like you can...then you should be able to give one of the JaxRSProviders a try. If tcp is needed for your required performance, then to be safe, I would suggest trying a very very small Java application to create a socket connection, read and write a few bytes and make sure that your target network will allow such client-server comm, as many VPN networks limit traffic by port and/or protocol, etc. This is one reason it's so hard for me or anyone to create a 'general' socket provider that will work on any VPN, NAT, network, etc. They can be configured in ways that will allow some things (e.g. odbc, http over specific ports) and not allow others (e.g. socket comm over port xxxx). If the Java socket app works in your target environment then I would suggest creating a very simple new distribution provider starting with the trivial provider [3]. If you decide to do this I can/will help and would welcome it, but for full-effort on it I would need some additional arrangement.
Ok. Regards, Scott [1] https://github.com/ECF/kryo-serialization [2] https://github.com/ECF [3] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/examples/bundles/org.eclipse.ecf.examples.provider.trivial |