标题: [Unity 组件参考手册]桌面：网络参考指南之最小化网络带宽 [打印本页] 作者: . 时间: 2013-2-19 17:09 标题: [Unity 组件参考手册]桌面：网络参考指南之最小化网络带宽 It is important to think about what kind of data you are sending across the network. Ideally, you should be sending the absolute minimum amount of data to make your game work correctly on all clients.理解你通过网络传输的数据是非常重要的。理论上来说，你应该发送足够让你的游戏能在所有客户端正常工作的最少量的数据。
How data is synchronized 数据是怎么同步的How you decide to synchronize data affects the bandwidth you use. You have a choice of using either Unreliable or Reliable Delta Compression in each Network View.你该如何决定影响你使用的带宽的同步数据呢？你在每一个NetworkView都可以做出一个选择，使用不可靠的数据，或者使用可靠的延迟的压缩数据。Unreliable means everything is sent during each iteration of the network update loop. This update loop is ***cuted according to what is set by Network.sendRate, by default 15 times per second. By using Unreliable you ensure frequent updates of information and you don't care if updates are dropped or delayed. Dropped or delayed packets are ignored. For objects which frequently change state this might be the best way of synchronizing.不可靠意味着在网络更新循环的每一个反复之间每一条数据都会被发送。更新循环执行的频率是通过Network.sendRate统一进行配置，默认是每秒15次。通过使用不可靠方式你可以确信顺序的更新，你不需要关心是否更新被丢失或者延迟。丢失和延迟的包会被忽略。对于顺序改变的状态来说这是最好的同步方式。Bear in mind amount of data that is constantly being sent out. For example, if you are synchronizing a transform you are sending 9 float values, 36 Bytes per update or 288 Bytes per second. For the server, if ***nning with 8 clients, this means he receives (8*36*15) 4,320 KBytes/s or 34,6Kbits/s and has to transmit (8*7*36*15) 30,2 KBytes/s or 242Kbits/s.连续发出的数据的量让人印象深刻。例如，如果你同步一个transform将发送9个浮点值。每次更新36个字节或者每秒288个字节。杜宇服务器来说，如果运行8个客户端，这意味着它将接收（8*36*15）4.320K字节每秒或者34.6K位每秒,然后传输(8*7*36*15)30.2K字节每秒或者242K位每秒。You can have a dramatic effect on the bandwidth by decreasing the send rate of the network updates. This depends on you game but for fast paced game this should be quite high (like 15).你能通过减少网络更新的发送速率来获得带宽的可观优化。这取决于你的游戏，但对于进展快速的游戏来说15仍然显得很少。Reliable Delta Compressed means that data is sent reliably and in order, if out of order packets arrive they are held back until the correct packet is there. Data is also delta compressed which means only the difference between the last sent state and the current state is sent. If the difference is nothing then nothing is sent. This greatly decreases the bandwidth used by objects depending on how static they are during a game. A static object send no updates at all. This can however affect the latency of the state synchronization, packets might arrive delayed because they needed to be resent. In this case nothing is received at all until the dropped packet arrives. Using interpolation decreases the effect of dropped packets.RDC(可靠的延迟的压缩)意味着数据被可靠的次序的发送，如果包到达的次序错乱他们能被缓存直到当前次序的包到达。数据同时也是被压缩和延迟的，这意味着只有最后发送的数据和当前的数据不同的时候才会产生发送。如果没有不同，则没有发送，这巨大的减少了带宽的使用，当然基于这些对象在游戏过程中大部分时间是静态的。一个完全静态的对象根本不会发送任何更新。这是能影响状态同步的潜在因素。包可能会延迟因为他们可能丢失。在任何丢失的包被重发并接收到之前整个处理过程会被冰冻。你可以使用插值的方法来减少丢失的包所带来的影响。
What data is synchronized 什么数据需要同步It is important to try and think creatively on how your game can be synchronized so it appears to be the same on all clients. It might not be necessary for everything to be exactly the same, a good example is synchronizing animation. When you have, for example, a character which has all sorts of animation, like walking, ***nning, jumping etc. You want all this to appear the same but it isn't necessary to be exactly the same. If you directly put an Animation component as an observed component in a Network View then it is exactly synchronized. It sends time, state and the enable boolean. This generates a lot of traffic as time constantly changes but there is an easy and efficient alternative way of doing this. You can make a network animation script which is serializes only a single char variable, and then in the animation script you send a message to this network script and tell it what the current animation state is. Only the single char variable is sent each time that animation changes, which is nothing compared to ***te force synchronizing the animation.据顶你的游戏如何同步已使得它看起来在所有客户端是一致的是必须尽力思考并需要创造力的问题。并不需要游戏中每件事物都显得一致，一个好的例子是同步动作。当你发生动作时，例如一个角色有各种各样的动作，像行走，跑动，跳跃等等。你希望所有这些动作都显得一致但并不需要完全的一致。如果你直接放置一个动画组件作为一个网络视图上的观察者属性所引用的组件，那么它会被完全的同步。发送时间，状态和使能。随着时间连续的改变这会导致巨大的传输量。还有一个简单有效的可选途径。你能使一个网络动画脚本只传输一个简单的字符变量，然后在动画脚本中发送一条消息给这个网络脚本，告诉它当前的动画状态。每次当动画变化时只是一个单个的字符变量，这和完整的动画同步没有任何区别。
When to synchronize dataIs it really necessary to always keep a game completely in sync on all clients? Think about a game where there are large buildings all over the place or big race tracks which go into forests or over and under hills. When one client is nowhere in sight of another client there is no need to keep them synchronized with each other. This can greatly decrease the load on the server as he no longer needs to tell everyone about everyone else. This is sometimes called using Relevant Sets. You have a set of relevancy for each client which defines what data he needs to receive. At the moment this can, however, only be done with RPCs as their destination scope has greater control. You can direct them to specific network players, based on your own logic on who should get them.一个游戏总是保持在所有客户端完全同步是不必要，游戏中或许存在很大的建筑物覆盖区域或者有覆盖在林中或是山间的很长的跑道.当一个客户端不在另一个客户端的视野中时，根本不需要在他们之间同步任何数据。这种做法有时被叫相关集合，能巨大的减少服务器的负载。任何时刻，你均有个和每个客户端之间的定义了该客户端需要接收什么类型的同步的数据的相关集合。然而，在此时此刻，只有当他们的目标范围获得了更大的控制的时候才通过RPC来执行同步。你能为一个特殊的网络玩家指定集合。基于你自定义的关于谁应该获得数据的逻辑。
Level loading 读取关卡One exception for when to worry about bandwidth is during startup or level loading. Here it is fine to send bulks of data to initialize the game, each client just waits until everybody is ready. You could even send textures or picture data so players can really customize their avatars.恐怕在读取关卡时关于带宽会有一个例外。这时候为初始化游戏而传输大量的数据是比较好的。每一个客户端都会等待直到每一个客户端都准备好。甚至当用户自定义自己的化身的时候，你还能发送纹理或者图片数据。 【来源：互联网】
更多精彩教程，尽在web3D纳金网http://www.narkii.com/college/