用具体事例来说，举个例子：聊天。一个游戏如此设定，一个玩家当使用“当前频道”时，只能让周围50米的玩家收到。
于是。玩家A输入了一堆话，这个时候客户端接收，并立即发送到服务器端。
这个时候任何客户端是没办法看到聊天信息的，包括A端（假定是这么设定的，这个就是有的时候你网络卡的时候，明明按了回车，对话框却不冒出来任何聊天信息的原因）。
时间在流逝，服务器开始跑队列，并跑到这个地方了，于是它开始运算，第一是判断这句聊天对话是当前频道，世界频道还是其他，判定结果是当前，于是执行当前频道的处理：读取这个玩家所在位置，搜索这个位置方圆50米的其他玩家，向这些玩家 包括A端广播聊天信息（假如还有黑名单功能，还要剔除黑名单玩家;假如付费用户字体还有特殊颜，还有传播这个对话的风格）。
所有客户端收到信息，然后在聊天频道里播放这条信息。于是大家都看到了。
年度报告怎么看具体来说，理想上的网游（当然还包括股票交易是这种类型），个人倾向于所有逻辑处理全放服务器端，而客户端就像个媒体播放器。
这是因为如同某本书讲得，客户端是掌握在对手中，如果让你服务器只起到数据交换作用，那么外挂就可以彻底糟蹋你的游戏。
在理想基础上，客户端做的事就是表演，根据服务器和用户的输入处理，进行各种场景，动作与特效的播放。包括绘制角（动态物件），绘制场景（相对静态物件），绘制光照，物件，光照排序，动态物件动画的播放。袁巴元
当然这是基于理想基础之上的，实际上的制作会有很多变化。
比如休闲游戏，因为它要求响应比较迅速（比如泡泡堂，加速后的角跑起来的速度飞快，你怎么保证其他客户端能够实时看到对方所在位置。不然就炸不到了），所以这种需求之下，客户端开始承接更多的活计，比如客户端不单是播放功能，还加上了判断，先执行了客户端的判断去追求表演的流畅性。
当然，为了安全，最后数据一样要通过服务器验证，验证不通过就纠正回来。又因为纠正很粗暴，所以还开始增加一些纠正机制，让纠正的过程看上去柔和些，比如WOW里面，有时候你会看到其他怪物或角拖着速度线飞快的移动到其他地方，那就是柔和纠正机制。
三国演义人物简介根据情况不同，客户端做的事情都有不同。
服务至少要做验证。
网游一般来说数据传输量是几KB每秒呢？
答：
相对于网络游戏来说，数据传输量在一定程度上可以忽略，而更注重数据来回时间。在一般情况下，比如说WOW里面，200MS延迟就开始变黄。也就是说在一般时间要求不是很极端的，比如KOF97转到MMO，200可以默认为一个普通MMO的标准线。
而基本上这整个这个过程，包括玩家位置信息，包括玩家聊天内容，大小不可能超过1KB，
就算是加密后，也是这种数据量在正常情况下是可以忽略的。这个也是一般网络游戏的传输数据标准。跟重要的是两个参数，第一玩家信息包传送到服务器并服务器返回的时间；第二服务器处理事件的周期。
而除了UI位置这些琐碎无关于角的信息，其他信息都应该保存在服务器端。
保存在客户端的应该是资源，包括角模型，动画，场景，特效等，部分游戏也将大量文本保存在客户端，比如任务对话。
而重要信息，特别是任何将对自己或其他玩家有影响有改动的信息都应该放在服务器端。比如角的经验，甚至比如你接到的任务（如果你保存在客户端，你换台机，以前接到的任务就都没了）。
至于客户端向服务器什么时候发送消息，多少频率，那一般是个长连接，只要信息量没超过KB，影响都不太大。实际上，只要你登录以后，服务器端和客户端就一直在相互通信，哪怕你不动，服务器都会因为你有可能接受到聊天信息而不停的给你塞消息。所以这个还是让程序去头疼，他们是专业。
事情大体上就是这样。
jyp周子瑜但是两者之间的数据是不能忽略的。如果两个人都进入了对方的视野而且做了动作，那服务器就要向每个人发送两个人物的状态数据。同样的，如果视野内有N个人，就要发送N*N个人物状态数据。
有两件事很考验服务器的网络带宽：
1.视野内有上百人在边跑边放技能。
2.N多人刷世界频道。
网络游戏的高延迟是由带宽不足引起的数据阻塞造成的。我知道400人在线的RO私服用10Mbps带宽就足以保证不卡，但动辄几千人的网游需要多少带宽还真不好说。
上面的表述还要纠正一下
嗯，量的积累确实是一个问题。
你的例子中：N*M的状态数据，首先，所有状态数据不一定要提前发送，可以即查即发，比如玩家在查看其他人的状态才查得到他的状态，再次，那也是KB档次而已，即使个别漏包都不成问题。
最重要的一点就是无限多人会战，先拖当的必然是客户端。这个例子比较极端了。N多人刷世界频道，那也不是很严重的问题，如果真觉得有压力，可以限制说话间隔。何况这个问题解决还可以通过机制改善来做，比如聊天专用服务器等。
最终那还是程序头疼的问题。所以我忽略掉了这块。如果真的在项目中，有这个需求，确实是需要慎重考虑的。
客户端是皮，服务器端是脑，网络是牵线。
客户端难么，难在更好的表现画面，什么多层材质，置换贴图，即时光影，各种各样的Shader，现在这些东西越来越花哨了。
服务器端在多线程控制，因为每个用户与它相应的代理之间都占用一个线程，也就是有多少个连接就有多少个线程，在分配这些线程的时候，要保证用户这端没有等待的感觉。
跟公平性有关的计算机，都应该在服务端计算。 比如：属性，攻击伤害，判定。
跟个人操作有关洗的计算，都应该在客户端计算。比如：按键，鼠标，摄像机。
例如，如果“行走”是在客户端计算的话，确实是降低服务器的负荷。但是如果有人使用“变速外挂”怎么办？ 所以，走路也应该在服务器的负荷。但是如果有人使用“变速外挂”怎么办？ 所以，走路也应该在服务器上计算才算公平。
对游戏的可玩性没有决定性的影响的功能，都可以放在客户端。
快手牌牌琦大号封多久一般的游戏资源，动画骨骼嘛的，全部放在客户端。
有些安全性要求很高的数据，放在服务器端，比如，人物等级/经验什么的，客户端不停的以服务器为基准同步。
还有些居中的数据，随便处理了。
比如，聊天一般就服务器做个记录，主要是客户端在屏蔽词过滤。服务器端作个延迟安全性判断，一般不会有大问题。
格斗游戏比较特殊，对网络延迟要求很高，20ms是基准线。所以，什么技能攻击力/命中/移动速度/伤害范围全部是客户端在计算，服务器最多做下延迟校验。
总之，根据实际情况来划分客户端与服务器段功能。
如果这么你会面临服务端信息数据处理的并发问题，非常容易造成服务器系统崩溃，设计程序必须要考虑极限情况的可能发生的事情，假如服务器中有1000人在同一个200毫秒内用世界频道喊出一句话，也就是说，每个人的话被其他999个看到，服务器就要发送给999个其他用户，总量就是99*999=998801。这将近100万条的信息发送要在200毫秒内完成。”
以上描述的状态，在成熟的MMORPG系统设计里是应该竭力避免发生的情况。如果按照这种策略来设计网游系统，就相当与网络通讯里最忌讳的广播风暴！
李昕岳这是任何一种现有网络设施都无法承受的崩溃极限行为，所以，在真正的大型多人在线角扮演的网游系统实施当中，这种情况一定是会被首先排除掉的。
2.楼提到“相当于网络游戏来说，数据传输量在一定程度上可以忽略，而更注重数据来回间。
”【狗刨学习网】
这个说法本身就是问题，原因就说2点吧。
第一，数据传输量的大小将直接影响到服务对该数据量的处理，如果细说涉及到计算机原理和工作状态下的微观世界，涉及到CPU的工作频率及总线频率和时钟频率；打个吃葡萄比方比较好理解，加入整个葡萄放嘴里，吃完后吐皮和子出来，一个一个吃容易的，如果让你一次放十个葡萄进嘴里会如何呢？
第二，服务器和客户之间通过网络连接，之间需要经过若干个路由，而每次客户端和服务端之间的通讯传输都可以走不同的路径，或经10个路由后到达，或经过18个路由到达。
并受网络环境和条件带宽的影响甚大。在打个比方，穿越城市中心闹市区，一辆摩托车还是一辆大卡车块？
3楼中前半段阐述的基本概念是正确的，后半段不正确。服务端对用户端的操作进行验证是需要消耗服务器系统资源（CPU处理器），这个验证的过程包括了多种判断，其中最主要的判断验证是否有用加速齿轮类的东东进行作弊，更有一种判断是否使用外挂瞬移，
等等等等，这些判断中进行还可能发生死锁或溢出。
而需要纠正的是，WOW中那个速度线是特效，代表的是某个角使用了技能，而这个信息是需要告诉其他玩家的。而不是什么验证不通过就纠正回来的什么纠正机制。
4.楼“服务器端固定周期处理一次所有聊天信息，比如200毫秒，客户端送到的时候，正好上一个200毫秒过去了”于是排在下一个200毫秒的队列里。这个时候任何客户端是没办法看到聊天信息的，包括A端（假定是这么设定的，这个就是有的时候你网络卡的时候，明明按了回车，对话框却不冒出任何聊天信息的原因）。”
如果这么你会面临服务端信息数据处理的并发问题，非常容易造成服务器系统崩溃，设计程序必须要考虑极限情况的可能发生的事情，假如服务其中有1000人在同一个200毫秒内用世界频道喊出一句话，也就是说，每个人的话被其他999个人看到，服务端就要发送给999个其他用户，总量就是999*999=998801.这将近100万条的信息发送要在200毫秒内完成。如果是一台支持2000人在线的服务器呢？4000人在线的呢？而且都要在200毫秒内完成。
5楼就不说了，重复的东西。
6楼
“至于客户端向服务端什么时候发送消息，多少频率，那一般是个长连接，只要信息量没超过KB，影响都不太大。实际上，只要你登录以后，服务器端和客户端就一直在相互通信。哪怕你不动，服务器都不会因为你有可能接受到聊天信息而不停的给你塞消息。”
有点累了，就说结果吧。这样做的而结果将导致服务器的效率低下，负载严重加剧。最终导致让程序员做头疼的什么负载均衡系统。负载均衡控制。。。。。。而最终得到的效果甚微。
发布评论