Blobject subclass examples?

[bartley]

I'm trying to get dynamic Ice working so I can do dynamic invocation and dispatch, but am a little clueless on how to implement some of the required methods.

The manual says I need to implement ice_id(), ice_ids(), ice_isA(string id), and ice_ping(), but unfortunately gives almost no indication of how to do that. I couldn't find any examples in the demos, either.

It seems like ice_id() is pretty straightforward, and I thought ice_ids() was, too, until I tried it out on some other proxy (which isn't a subclass of Blobject) and saw that it makes all kinds of calls to Glacier2. Why? Does my implementation need to do the same thing? And what do I do for ice_ping()?

Sorry if I'm just missing something or being dumb.

thanks,

chris

[mes]

Hi Chris,

Originally Posted by bartley

The manual says I need to implement ice_id(), ice_ids(), ice_isA(string id), and ice_ping(), but unfortunately gives almost no indication of how to do that.

When using dynamic Ice in a request-forwarding application, you need to determine the proper semantics for these operations. For example, if the requests from a client are forwarded to a single server, then you might consider simply forwarding these operations as well and returning the server's replies directly to the client.

This strategy is not always appropriate, however. For example, in the case of IceStorm, there can be any number of receivers, and the value returned by ice_ids() could be different for each of them, so it makes no sense for IceStorm to forward this operation. (Not to mention the fact that the receivers might be using UDP, which makes twoway invocations impossible.)

Another possibility is to declare that your relay does not support the operations ice_id(), ice_ids() and ice_isA(). The implication here is that clients must not use checked casts or call these operations directly.

With regard to ice_ping(), you need to decide whether the relay can determine if the object indicated by the given identity is available without consulting the back-end server, or whether this operation must also be forwarded.

As you can see, the behavior is highly application-dependent.

Hope that helps,
- Mark

[bartley]

Thanks, Mark, that helped a lot. I got it working now, thanks! Not sure if my design is quite right, but I'll worry about that tomorrow.

For now, I have a couple questions regarding return values. I want for the robot to be able to pass back return values to the GUI client (through the relay server, and using dynamic ice). I tried a simple test and got an UnmarshalOutOfBoundsException. After some forums searches, I found a post (http://www.zeroc.com/vbulletin/showt...?p=881#post881) from you that explained that the exception often comes from invoking a twoway operation on a oneway proxy. That was exactly my problem (thanks again!).

So, two questions:

1. Is there some way to detect whether the operation that I'm passing along with ice_invoke needs to be oneway or twoway (i.e. has a return value)? I'm wondering if that would enable me to set up the proxy as oneway by default (to get the throughput benefit and avoid network latency problems), but switch to twoway when necessary?
2. Would it be possible for (a future version of) Ice to throw a TwowayOnlyException instead of an UnmarshalOutOfBoundsException when making the mistake I did? That might help people track down the problem more quickly. Just a thought...maybe I'm misunderstanding the purpose of TwowayOnlyException.

thanks again!

chris

[mes]

Hi,

Originally Posted by bartley

Is there some way to detect whether the operation that I'm passing along with ice_invoke needs to be oneway or twoway (i.e. has a return value)? I'm wondering if that would enable me to set up the proxy as oneway by default (to get the throughput benefit and avoid network latency problems), but switch to twoway when necessary?

The Ice protocol doesn't include anything that you could use to determine whether the request was sent with a oneway or twoway proxy, so you have to assume that all requests are twoway.

Since only the client can know how an operation is invoked, Glacier2 allows a client to control the router's forwarding behavior with the use of a specially-recognized request context, and you could use a similar strategy. In fact, if you are using Glacier2 as the front-end for your relay, your relay could recognize the same request context ("_fwd"). Be aware that Glacier2 must be configured to forward request contexts.

Would it be possible for (a future version of) Ice to throw a TwowayOnlyException instead of an UnmarshalOutOfBoundsException when making the mistake I did? That might help people track down the problem more quickly. Just a thought...maybe I'm misunderstanding the purpose of TwowayOnlyException.

This is not possible when you're operating at the ice_invoke level. When making regular typed invocations, the generated code knows whether an operation can be invoked as a oneway and takes the necessary precautions, but a generic relay does not know the parameters and return type of the operation being invoked and therefore cannot determine whether a oneway is safe.

Take care,
- Mark