tnl的ghostobject的通信方式是非常强大的.能以很小代价在多个客户端同步任意多的对象,但是因为其简洁反而不好理解.这里阐述一下.客户端连接的时候自己并没有生成在两边要同步的对象,客户端只是trigger了服务端,使得其在OnconnectionInited 的时候生成在两边要同步的对象.然后服务端再设置该对象为ghostable那么的在下一个服务端的tick()的时候,这个要同步的对象就被broadcast到所有的客户端上去了.那客户端怎么知道这时候来的就是自己能控制的对象而不是其他客户端的呢?因为在server broadcast这个同步对象的时候是通过与不同客户端连接的connection来发送出去的.只要发送的时候判断当前发送的这个同步对象是不是与当前发送用的connection向关联的就行了(该connection设定了 setScopeObject(该object);).相关的就是对应客户端能够控制的.其他的都是被动收来的.
在两端都建立好同步的对象以后. 通信方式从client的同步对象到server 是通过rpc callback的方式直接改该同步对象在server端的对象的.从server到client的话则完全不同.这个是因为从server到client 实际上是广播的方式.故而是通过在server端先在继承下来packupdate函数封装数据.在client时候通过继承unpackupdate来放包装来做的.在运行的时候具体决定要broadcast什么数据是通过在server端通过设置maskbit来确定要传送的数据的.换句话说,原则上客户端不修改本地的同步对象而是通过callserver让server来广播出去(也广播到自己的ghostobject上)
client(RPCEventSend) <-> server(RPCEventReceived) RPC 1...1client(unpack) <- server(pack) broadcast n...1
正因为如此,所以对于一个已经在一个connection上注册的了(事实上是有多个connection都设置一个同步对象为客户端操作对象的可能性的,比如作为录象客户端)同步对象的performScopeQuery的操作直接被该connection callback从而来决定究竟其他的那些需要进行同步的对象应该满足什么样的关系才能被这个connection从server 传递到 client 那里去.
