Callback and Glacier Example?

[feline]

Hi,
I am trying to get the demo/callback example to work via Glacier as described in the manual. I can not get it to work Does anyone have sample configs?

I continually get...

./client: Outgoing.cpp:293: Ice::ObjectNotExistException:
object does not exist
identity: Glacier/router
facet:
operation: getClientProxy

Will IceStorm work via glacier too? My application needs to support Sever to Client callbacks....but my clients maybe behind firewall. As I understand it Glacier is required to get the server side to re-use the client connection.....did I understand that correctly? Any other way to do this?

[benoit]

Originally posted by feline
Hi,
I am trying to get the demo/callback example to work via Glacier as described in the manual. I can not get it to work Does anyone have sample configs?

I continually get...

./client: Outgoing.cpp:293: Ice::ObjectNotExistException:
object does not exist
identity: Glacier/router
facet:
operation: getClientProxy

How did you start Glacier and which configuration file did you use? The following worked for me:

bash$ cd Ice-1.3.0/demo/Ice/callback

<edit the config file and uncomment the following lines>
Ice.Default.Router=Glacier/router:default -p 10005
Callback.Client.Router=Glacier/router:default -p 10005
Callback.Client.Endpoints=

bash$ ../../../bin/glacierrouter --Ice.Config=config &
bash$ ./server &
bash$ ./client

You might want to execute the processes in different terminal windows to better see where the messages are coming from.

Will IceStorm work via glacier too? My application needs to support Sever to Client callbacks....but my clients maybe behind firewall. As I understand it Glacier is required to get the server side to re-use the client connection.....did I understand that correctly? Any other way to do this?

Yes, you're correct. Your server (or IceStorm) needs to go through Glacier to forward callbacks to your client. Glacier will re-use the client connection to forward the request.

Of course, you can also use IceStorm with Glacier. Actually, just like the callback server in the callback demo, IceStorm doesn't have any knowledge of Glacier. It's totally transparent to the server.

Let us know if you need more information or if you still have difficulties running the demo!

Benoit.

[feline]

Thanks for the tips. I followed the example from the manual...is uses port 8000 instead of 10005 to configure the router. And then I was using glacierstarter when I needed glacierrouter. All working as expected now. But I have another question

The documentation indicates that if I want to use callbacks I will need a seperate instance of glacierrouter for each client. Is that true? Is it really feasible to have one router for each client....say 3000 clients at a time?

If I am just using two-way calls (no callback), but the twoway calls do return values and have output arguments....do I still need individual glacier instances...or will one do?

Thanks for the help.

[benoit]

Originally posted by feline
Thanks for the tips. I followed the example from the manual...is uses port 8000 instead of 10005 to configure the router. And then I was using glacierstarter when I needed glacierrouter. All working as expected now. But I have another question

The documentation indicates that if I want to use callbacks I will need a seperate instance of glacierrouter for each client. Is that true? Is it really feasible to have one router for each client....say 3000 clients at a time?

Yes, this is correct -- you need one router instance per client. With this approach, if a router dies (possibly because of a rogue client), other clients are not affected.

Depending on how many machines will be running the routers and depending on how the operating system scales to a high number of processes, this should work. If it doesn't scale, another solution would be to write your own router service (the Ice core provides all the hooks to do this).

If I am just using two-way calls (no callback), but the twoway calls do return values and have output arguments....do I still need individual glacier instances...or will one do?

Thanks for the help.

One will do. Return values and output parameters are always sent over the same connection as the request. But... don't you need callbacks for the chat system for instance (assuming we are still talking about the game chest application here )?

Benoit.

[feline]

If it doesn't scale, another solution would be to write your own router service (the Ice core provides all the hooks to do this).

Is there any information on this? I suspect I do not need all of glacier...only a process which will accept connections and route to the appropriate backend server.....and handle sending the callbacks.


Another question....does AMI re-use the client connection or does the server connect to the client? What about AMI connecting to a AMD server?
Sorry....just trying to understand everything here.

But... don't you need callbacks for the chat system for instance (assuming we are still talking about the game chess application here )?

Yep...it is likely that I will....I can think of some nasty polling solutions, or an AMI trick...but it is not elegant. I am just trying to understand all the connectivity stuff.

One other question....I was thinking of using IceStorm for the chat system....publish/subscribe. I am guessing that uses server side callbacks?

[benoit]

Originally posted by feline
Is there any information on this? I suspect I do not need all of glacier...only a process which will accept connections and route to the appropriate backend server.....and handle sending the callbacks.

I'm afraid the only information available at this time is the Ice-1.3.0/slice/Ice/Router.ice documentation and the Glacier source code. Of course, if you have a commercial need for Ice, we would be more than happy to help .

Another question....does AMI re-use the client connection or does the server connect to the client? What about AMI connecting to a AMD server?
Sorry....just trying to understand everything here.

AMI is not much different from a synchronous two way invocations in this respect. It's just asynchronous, meaning that you can make the request and receive the results later. So to answer to your question, yes, the response and the output parameters of an AMI request will be received over the same connection as the connection used to send the request.

Note that AMI and AMD have nothing to do with callbacks (at least not in the sense we've been discussing so far). It won't help you to send callbacks from your server to your clients. AMI will just allow you to make a request on a server asynchronously.

Yep...it is likely that I will....I can think of some nasty polling solutions, or an AMI trick...but it is not elegant. I am just trying to understand all the connectivity stuff.

I don't think AMI would help but let me know if that's still confusing.

One other question....I was thinking of using IceStorm for the chat system....publish/subscribe. I am guessing that uses server side callbacks?

Yes, your client will have to register a subscriber object with an IceStorm topic. So your client will have to act as a server to receive invocations for this subscriber object from the IceStorm service. If your client is using a router, this shouldn't be a problem -- the invocations from IceStorm will be routed through the connection your client established with the router (you could try this yourself with the IceStorm demo by just changing the subscriber configuration like the callback demo to use a Glacier router, let me know if you need some help with this).

Benoit.