Newbie's question: wondering how to design to make this work...

[sjinny]

If I want to make a MMO game based on ICE, which is a Client/Server software, and is has such an architecture:
In the server there would be a SCENE-TREE( a Quadtree for example ), and the client would have a scene-tree which is a part of the server's scene-tree.
So the question is how to notice the clients the changes of the servers' scene-tree, or in other words is there any mechanism in ICE to help to synchronize the server's scene-tree and the clients' scene-trees ?

Sorry about my poor English... ^_^

[michi]

A common way of dealing with this type of issue is to use the observer pattern: have the client register an observer callback object; when the scene graph changes, the server can invoke operations on the callback object in the client to notify the client of a change.

Another option would be to use IceStorm to distribute events to clients that contain the relevant information.

Cheers,

Michi.

[sjinny]

Tanks, Michi.
In your reply it seems that there's no complete mechanism for synchronize data structure on the internet, and from the "Distributed Programming with Ice" i saw that when using ICE to develop program on the net the developers still have to consider the network communication for synchronize data structures.So I suggest to make ICE handle the synchronization of the data structure on the internet, that will make the ICE users to develop network programs as local programs.

[michi]

So I suggest to make ICE handle the synchronization of the data structure on the internet, that will make the ICE users to develop network programs as local programs.

I'm afraid that's impossible. For distributed systems, guaranteeing that data structures remain synchronized across different nodes is impossible. (Yes, impossible, even in the presence of a distributed transaction service--all a transaction service can do is make it less likely that this happens and, if it does happen, alert you to the fact that it has happened.)

Also, even though Ice makes it easy to write distributed applications, you cannot write a distributed application as if it were a non-distributed application. For one, such programs will generally perform poorly if the distribution boundaries are placed incorrectly, due to the vasly longer latency of a remote call compared to a local call. Also, distribution adds many additional error scenarios that cannot arise in non-distributed programs.

Trying to make distributed programming as simple as non-distributed programming is simply impossible.

Cheers,

Michi.

[sjinny]

I see ...
continuing reading doc ...

[joel vennin]

A common way of dealing with this type of issue is to use the observer pattern: have the client register an observer callback object; when the scene graph changes, the server can invoke operations on the callback object in the client to notify the client of a change.

Another option would be to use IceStorm to distribute events to clients that contain the relevant information.

Cheers,

Michi.

I've following the discussion, and i have a question around the observer pattern. I've a little problem with it. In fact when the server try to invoke an operation on the callback, if on the client side the user decide to debug its application and setting a break point on the callback, the server becomes blocked. So all other operations on the server side are blocked.

So I would like to know the better way to avoid this problem.

Thank you

Joël

[matthew]

There are several ways to avoid this issue:
- Use timeouts on the server side.
- Use oneway calls on the server side.
- Use AMI on the server side.

Note that if you use oneway or AMI you can still encounter blocking if the TCP/IP buffers fill up. There are lots of articles in the newsletter on this topic. You can also view the FAQs online - http://www.zeroc.com/faq.