Archived
This forum has been archived. Please start a new discussion on GitHub.
Server-Initiated Async
Hi,
I am wondering how one might implement the following with Ice.
Several clients connect to a server. The clients all get a reference to an object. One of the clients calls a function on the object indicating that the object's state should be changed. The server then wants to notify ALL clients that the state of the object to which they hold a reference has changed.
Thanks in advance,
-- Andrew Bell
andrew.bell.ia@gmail.com
I am wondering how one might implement the following with Ice.
Several clients connect to a server. The clients all get a reference to an object. One of the clients calls a function on the object indicating that the object's state should be changed. The server then wants to notify ALL clients that the state of the object to which they hold a reference has changed.
Thanks in advance,
-- Andrew Bell
andrew.bell.ia@gmail.com
0
Comments
-
Hi,
There are many ways to implement this:- The object could notify the interested parties directly via callbacks.
- The object could publish an event with IceStorm.
- A servant locator could also initiate the notification after the request is dispatched to the servant. For example, the locator could examine the invocation mode (in Ice::Current) and send notifications for idempotent and mutating requests. This avoids the need for the servant to perform the notification itself, but may result in excessive notifications (i.e., the servant may be the best judge of when a notification is required).
- Mark0 -
CallbackThe object could notify the interested parties directly via callbacks.
Thanks for the info.
Sorry for missing things that are in the documentation - it is a little lengthy:)0 -
Hi,
I think you might be confusing two different types of callbacks. An AMD callback is strictly a local object that a server eventually invokes to complete an asynchronous request. When I mentioned callbacks in my previous post, I meant a proxy that the client supplies to the server so that the client can receive notification callbacks.
Regardless of whether your server uses AMD, it must have some way to notify the interested parties about changes to its state. Like I said, that can be done via direct callbacks on client-supplied proxies, or indirectly via IceStorm or some other intermediary.
Take care,
- Mark0 -
Adapter on Client?
How does the client supply a proxy to the server? Can I create an adapter and tie it to a servant on the client using the same connection that the client has already established with the server? Am I misreading your suggestion? Could you please elaborate a little.
Thanks,
-- Andrew Bell
andrew.bell.ia@gmail.com0 -
How does the client supply a proxy to the server?Can I create an adapter and tie it to a servant on the client using the same connection that the client has already established with the server?
In the next release of Ice, you'll be able to establish bi-directional connections without using Glacier2.
Take care,
- Mark0 -
An Ice application can be a client, a server, or both a client and a server. If your client needs to receive callbacks, then it must also be a server. This means the client must create an object adapter, add a servant, and create a proxy that can be passed to the server.
So your "client" has to have a well known port to which the "server" can connect in order for it to behave as a server?
-- Andrew Bell
andrew.bell.ia@gmail.com0 -
So your "client" has to have a well known port to which the "server" can connect in order for it to behave as a server?
If you don't use Glacier2, then your client must create an adapter with at least one endpoint. Whether that endpoint uses a fixed port or a system-assigned port really depends on the needs of your application. For example, if the callback proxy your client gives to the server is expected to remain valid across restarts of the client process, then your client should use an endpoint with a fixed port, or use an indirect proxy via IcePack.
- Mark0