Migrating objects between machines

[Nis Baggesen]

Does Ice have any build in features that would be useful for binding to an object which might migrate between different host machines.

Specifically I have a game character object which will be controlled by a remote client. Over the course of the game this character will move between different locations, and these locations typically reside on different hosts.

Naturally the object has to do some reregistering after is has been transfered, but it would be practical if I didn't have to keep track of all the proxies that point to the object, and update them by hand.

I was thinking of seperating the communication using IceStorm, but 1) of all I didn't know what impact that might have on bandwidth (At the very least I would then be sending the information twice), 2) I don't know how useful IceStorm would be for actually controlling the remote object and 3) a few of the methds I use are currently two-way which seems incompatible with IceStorm - but I might be able to change that.

However it would be more practical if the object could somehow just reregister at the locator service, but since it would have changed adapter I don't assume that the old indirect proxies would be able to find it. I might do it using direct object registration, but I'm going to have a lot of these objects (They do have unique identites) so I don't know if that would be impractical.

mvh

Nis

[michi]

If you have control over both client and server side, an easy way to implement migration is to use classes instead of interfaces. To migrate a class instance, simply pass it as a parameter to somewhere else, where the class will be instantiated on receipt, and destroy the instance at the sender end.

Cheers,

Michi.

[seth.piezas]

So this would take care of location registration as well? No need to do anything except install a factory? (is that necessary)

[Nis Baggesen]

Well the actual migration wasn't my problem, because as you describe that is simply a matter of sending the object to the other server. The problem is more one of a 'forwarding address' so that all the clients who knew where the object _was_ are somehow informed of the objects new location. Preferably without me having to keep check of all the clients that know of the objects existence.

mvh

Nis

[benoit]

See this thread for a similar discussion.

Another option that you might want to consider would be to not migrate your objects at all. Migrating objects might be tricky and inefficient if you have large objects. Furthermore, if your object migrates often, the clients making requests on your object will have to retrieve the new location of your object often. The location mechanism might become a bottleneck in such a scenario...

I'm not sure I understand what you mean about using IceStorm. Can you detail a little more?

Benoit.

[Nis Baggesen]

Originally Posted by benoit

See this thread for a similar discussion.

Thanks - I'll look into that.

Originally Posted by benoit

Another option that you might want to consider would be to not migrate your objects at all. Migrating objects might be tricky and inefficient if you have large objects. Furthermore, if your object migrates often, the clients making requests on your object will have to retrieve the new location of your object often. The location mechanism might become a bottleneck in such a scenario...

I don't think not migrating the object is an option as the object needs to have a very close connection with the location it is running on.

Originally Posted by benoit

I'm not sure I understand what you mean about using IceStorm. Can you detail a little more?

Benoit.

Well it was a vague idea of having topics for the object - A 'control' topic which the object would subscribe to and the client publish to (the client needs to be a server anyway, so no problem there), and a 'report' topic where the object is the publisher and the client the subscriber. When the object migrates it would simply resubscribe its new proxy to the 'control' topic, and retrieve the proxy for the 'report' topic again. While it was migrating the control commands the send by the client would be ignore at the object wasn't currently subscribing, and the object would generate any feedback on the 'report' topic. By splitting up the communication this way the object should be able to migrate without worrying about how many clients might know it, as this registration is handled by the IceStorm controller which isn't moving anywhere. Hope this made the idea a bit clearer.

This seemed reasonably elegant except for the issues mentioned above, but if htere is some basic flaw I'd be happy to hear it

[Nis Baggesen]

Originally Posted by benoit

See this thread for a similar discussion.

That thread seemed to answer most of my questions. Thanks for bringing it to my attention. I still think I'll try out my IceStorm idea for some cases, but otherwise direct object registration seems to solve most of my concerns.

mvh

Nis