Archived
This forum has been archived. Please start a new discussion on GitHub.
Impossible to return a proxy over a bidirectional connection?
Hi guys,
We use Ice to allow our software to access multiple data stores. That is, we've defined an interface with Ice, and then implement that interface for each backend we want to pull data from -- it works great!
Recently, we've had demand to not only pull data from one of the data stores, but for our application to also *push* data and update what is stored in the backend. I had been reading a lot about Ice, and decided we could achieve this with a very minimal change to the interface by having our application implement the same interface. We already had a few callbacks to allow the backend to notify our application when certain things changed, but we wanted to get rid of the two TCP connections, so figured it was a good time to look at bidirectional connections aswell.
So, that's where we are now. Both application and backend act as Ice client and Ice server over a single TCP connection. Things get a bit hairy though, as the interface includes operations that return proxies. When the backend performs such a request, it ends up with a proxy containing no endpoints, which obviously doesn't work so well.
From what I've read on the forum, I'm getting the impression that it's impossible to return a [functional] proxy over a bidirectional link. I can work around this in the backend implementation by calling ice_getIdentity() on the returned proxy and passing that to Connection.createProxy() to get a functional fixed proxy, but it's quite messy
The purpose of this post is twofold. First, I'm curious to know why it is not possible for the Ice runtime to perform such a workaround for me in the no-endpoint case?
Second, I just wanted to run my thought process by experts to test my assumptions and understanding, in case there is a way to return a functional proxy over a bidirectional link, or the reason I'm ending up with a proxy with no endpoints is because I'm doing something wrong creating the proxy on the application side.
Thanks for your time,
-Rowan
We use Ice to allow our software to access multiple data stores. That is, we've defined an interface with Ice, and then implement that interface for each backend we want to pull data from -- it works great!
Recently, we've had demand to not only pull data from one of the data stores, but for our application to also *push* data and update what is stored in the backend. I had been reading a lot about Ice, and decided we could achieve this with a very minimal change to the interface by having our application implement the same interface. We already had a few callbacks to allow the backend to notify our application when certain things changed, but we wanted to get rid of the two TCP connections, so figured it was a good time to look at bidirectional connections aswell.
So, that's where we are now. Both application and backend act as Ice client and Ice server over a single TCP connection. Things get a bit hairy though, as the interface includes operations that return proxies. When the backend performs such a request, it ends up with a proxy containing no endpoints, which obviously doesn't work so well.
From what I've read on the forum, I'm getting the impression that it's impossible to return a [functional] proxy over a bidirectional link. I can work around this in the backend implementation by calling ice_getIdentity() on the returned proxy and passing that to Connection.createProxy() to get a functional fixed proxy, but it's quite messy
The purpose of this post is twofold. First, I'm curious to know why it is not possible for the Ice runtime to perform such a workaround for me in the no-endpoint case?
Second, I just wanted to run my thought process by experts to test my assumptions and understanding, in case there is a way to return a functional proxy over a bidirectional link, or the reason I'm ending up with a proxy with no endpoints is because I'm doing something wrong creating the proxy on the application side.
Thanks for your time,
-Rowan
0
Comments
-
Hi,
The Ice encoding is "context free": a proxy is un-marshalled without any knowledge on the context of the application that unmarshalls the proxy (the proxy could be un-marhalled from an Ice stream, a file, etc).
Since a bi-directional proxy is tight to an Ice connection, it isn't possible to pass around this proxy through Slice operations (or store the proxy in database) -- there would be no way to maintain the association between the proxy and the connection.
So instead we recommend passing the identity of the Ice object and the receiver is responsible for creating the proxy from this identity using the Ice connection createProxy method. Passing a proxy without endpoints is also an alternative but the receiver will still need to create the bi-dir proxy using an Ice connection for proxies without endpoints.
Cheers,
Benoit.0 -
Aha, so it's not technical impossibile for the runtime to perform such a workaround automatically, but it's not done for the sake of keeping the design/implementation simple and clear, and keeping the components seperate from each other's concerns.
Fair enough, I can get behind that. There's way too much needless complexity in modern software, I certainly wouldn't want you to add to that just to provide me some minor convenience
Thanks for the response (and the library)!
-Rowan0 -
Problems using a proxy passed from server to client (ObjectNotExistException)
Hi,
Searching the forum this was the closest thread that I could find that sounds similar to a problem that I have concerning passing proxies from server to client etc.
I am working on a system where we have two devices, a touch panel and a mobile client, that connect via a glacier2 based server. When a connection is required the mobile talks to the server to establish a connection to the panel.
The Slice for this is
interface PanelAnnounce {
Mobile *announce(string identifier,Panel *proxy);
};
interface MobileAnnounce {
Panel* connect(string panelid, string mobileid, Mobile* mobileProxy);
};
The server that is in the middle arbitrates this connection. The proxy returned by PanelAnnounce::announce is really an icestorm topic. The proxy returned by MobileAnnounce::connect is the Panel's proxy.
The problem I have is with the Panel proxy that is returned by MobileAnnounce::connect ONLY in a C++ application that emulates the mobile client. When I try to use this proxy (ice_ping()) I get an Ice::ObjectNotExistException.
A python test script that emulates a basic mobile client can use the very same proxy without problems. Also an iOS application doesn't have a problem with this proxy either. In addition the panel application which is also a C++ application can use the mobile proxy (icestorm topic) directly without problems.
I assume that I am missing something as this thread alludes to the possibility that a fixed proxy may be created but I am unsure of the details. I've looked at the documentation regarding fixed proxies and the truth is I'm not exactly sure how I am to bind the proxy to a connection. I've tried creating a new proxy using the identity etc. without any luck.
Is there a reason why the python script would work whilst the C++ application that implements the same code would not?
As I have mentioned it is only in the case of my C++ mobile client emulation that I have this problem. It is driving me a little crazy. Any help would be greatly appreciated.
Thanks in advance,
Matthew0 -
Hi Matthew,
Did you try to enable protocol and network tracing to see where the request was sent? Protocol and network tracing can be enabled with Ice.Trace.Protocol=1 and Ice.Trace.Network=3.
I also wonder if this could be a problem with collocation optimization. Is your C++ application also creating an object adapter? You could try running the application with the property Ice.Default.CollocationOptimized set to 0 to disable collocation optimization and see if it helps.
Cheers,
Benoit.0 -
Hi Benoit,
Yes indeed my application is creating an object adapter. I've disabled collocation optimization as you have suggested and it now works correctly!!!
Many many thanks,
Matthew0
