包含标签 网络 的文章

KCP同 UDT/ENET的性能比较

如果不丢包那么 KCP(https://github.com/skywind3000/kcp)和 TCP性能差不多,KCP不会有任何优势,但是网络会卡,造成卡的原因就是丢包和抖动,有同学在内网这样好的环境下没有用任何丢包模拟直接跑,跑出来的数据是差不多的,但是放到公网上,放到3G/4G网络情况下,差距就很明显了,公网在高峰期有平均接近10%的丢包,wifi/3g/4g下更糟糕,这正是造成各种网络卡顿的元凶。

感谢 asio-kcp 的作者 zhangyuan 对 KCP 与 enet, udt做过的一次横向评测,结论如下:

  • ASIO-KCP has good performace in wifi and phone network(3G, 4G).
  • Extra using 20% ~ 50% network flow for speed improvement.
  • The kcp is the first choice for realtime pvp game.
  • The lag is less than 1 second when network lag happen. 3 times better than enet when lag happen.
  • The enet is a good choice if your game allow 2 second lag.
  • UDT is a bad idea. It always sink into badly situation of more than serval seconds lag. And the recovery is not expected.
  • enet has the problem of lack of doc. And it has lots of functions that you may intrest. kcp’s doc is chinese. Good thing is the function detail which is writen in code is english. And you can use asio_kcp which is a good wrap.
  • The kcp is a simple thing. You will write more code if you want more feature.
  • UDT has a perfect doc. UDT may has more bug than others as I feeling.
……

阅读全文

网络程序计时器通常用啥实现?

通常来讲,就是利用 select 的空余时间,来进行时钟检查,不管是 select / poll / epoll/ kevent,以下统称 select,它有一个等待时间作为参数,即没有事件时,最多 wait 多少时间,我们把这个作为网络库的基准频率,比如 10MS,或者 20MS, 25MS, 50MS,都是常用的几个值。

就是说网络库调用 select 等待事件时如果没有事件,那么最长等待 10MS 就返回了,这时再处理完所有网络事件后,就可以来处理时钟数据了。事件处理函数就是这样:

def update_events(milisec = 10):  
	result = selector.select(milisec)  
	for fd, event in result:  
		do something with socket event  
	current = time.time()  
	update_timer(current)

while 1:  
	WAIT_MILLISEC = 10  
	update_events(WAIT_MILLISEC)

关键就是这个两次 select 中间 update_timer 的任务:集合中检查需要唤醒的时钟,并且调用它们的回调函数,来驱动整个服务器的时钟运行,以最简单的扫描法为例:

def update_timer (current):  
	for timer in available_timers:  
	while current >= timer.expires:  
		timer.callback(current)  
		timer.expires += timer.period
……

阅读全文

再谈网游同步技术

实时动作游戏在近年来得到迅猛的发展。而游戏同步问题,成为大家继续解决的核心问题之一。早在 2004年,国内游戏开发还处于慢节奏 RPG满天飞的情况下,我就开始实时动作游戏研究,分别在 2005-2006期间写了一系列相关文章,被好多网站转载:

帧间同步模式:《帧锁定同步算法》(2007): http://www.skywind.me/blog/archives/131

玩法规避模式:《网络游戏同步法则》(2005): http://www.skywind.me/blog/archives/112

预测插值模式:《影子跟随算法》(2007): http://www.skywind.me/blog/archives/1145

如今十年过去,网上越来越多的人开始讨论游戏同步技术了,然而很多文章往往只针对某种特定的游戏情况,而观点又经常以偏概全。很多人并没有真正开发过实时动作游戏,更别说了解同步技术的前世今生了。转载别人的观点并加上自己理解的人很多,实际动过手的人很少。避免给更多人造成无谓的误导,我今天基于先前的实践和对欧美动作游戏,战网游戏,主机游戏(PSN,XBox Live等)网络技术的了解,来对这个问题做一个简单总结:

……

阅读全文

快速可靠协议-KCP

简介

KCP是一个快速可靠协议,能以比 TCP浪费10%-20%的带宽的代价,换取平均延迟降低 30%-40%,且最大延迟降低三倍的传输效果。纯算法实现,并不负责底层协议(如UDP)的收发,需要使用者自己定义下层数据包的发送方式,以 callback的方式提供给 KCP。 连时钟都需要外部传递进来,内部不会有任何一次系统调用。

整个协议只有 ikcp.h, ikcp.c两个源文件,可以方便的集成到用户自己的协议栈中。也许你实现了一个P2P,或者某个基于 UDP的协议,而缺乏一套完善的ARQ可靠协议实现,那么简单的拷贝这两个文件到现有项目中,稍微编写两行代码,即可使用。

技术特性

TCP是为流量设计的(每秒内可以传输多少KB的数据),讲究的是充分利用带宽。而 KCP是为流速设计的(单个数据包从一端发送到一端需要多少时间),以10%-20%带宽浪费的代价换取了比 TCP快30%-40%的传输速度。TCP信道是一条流速很慢,但每秒流量很大的大运河,而KCP是水流湍急的小激流。KCP有正常模式和快速模式两种,通过以下策略达到提高流速的结果:

RTO翻倍vs不翻倍:

TCP超时计算是RTOx2,这样连续丢三次包就变成RTOx8了,十分恐怖,而KCP启动快速模式后不x2,只是x1.5(实验证明1.5这个值相对比较好),提高了传输速度。

选择性重传 vs 全部重传:

TCP丢包时会全部重传从丢的那个包开始以后的数据,KCP是选择性重传,只重传真正丢失的数据包。

快速重传:

发送端发送了1,2,3,4,5几个包,然后收到远端的ACK: 1, 3, 4, 5,当收到ACK3时,KCP知道2被跳过1次,收到ACK4时,知道2被跳过了2次,此时可以认为2号丢失,不用等超时,直接重传2号包,大大改善了丢包时的传输速度。

延迟ACK vs 非延迟ACK:

TCP为了充分利用带宽,延迟发送ACK(NODELAY都没用),这样超时计算会算出较大 RTT时间,延长了丢包时的判断过程。KCP的ACK是否延迟发送可以调节。

UNA vs ACK+UNA:

ARQ模型响应有两种,UNA(此编号前所有包已收到,如TCP)和ACK(该编号包已收到),光用UNA将导致全部重传,光用ACK则丢失成本太高,以往协议都是二选其一,而 KCP协议中,除去单独的 ACK包外,所有包都有UNA信息。

非退让流控:

KCP正常模式同TCP一样使用公平退让法则,即发送窗口大小由:发送缓存大小、接收端剩余接收缓存大小、丢包退让及慢启动这四要素决定。但传送及时性要求很高的小数据时,可选择通过配置跳过后两步,仅用前两项来控制发送频率。以牺牲部分公平性及带宽利用率之代价,换取了开着BT都能流畅传输的效果。

基本使用

……

阅读全文

影子跟随算法(2007年老文一篇)

算法简述

动作类游戏如何在高延迟下实现同步?不同的客户端网络情况,如何实现延迟补偿?十年前开始关注该问题,转眼十年已过,看到大家还在问这类问题,旧文一篇,略作补充(关于游戏同步相关问题还可以见我写于2005年的另外两篇文章,帧锁定算法网游同步法则):

影子跟随算法由普通DR(dead reckoning)算法发展而来,我将其称为“影子跟随”意再表示算法同步策略的主要思想:

1. 屏幕上现实的实体(entity)只是不停的追逐它的“影子”(shadow)。

2. 服务器向各客户端发送各个影子的状态改变(坐标,方向,速度,时间)。

3. 各个客户端收到以后按照当前重新插值修正影子状态。

4. 影子状态是跳变的,但实体追赶影子是连续的,故整个过程是平滑的。

clip_image002

图 1 算法演示

……

阅读全文

帧锁定同步算法

帧锁定算法解决游戏同步

早期 RTS,XBOX360 LIVE游戏常用同步策略是什么?格斗游戏多人联机如何保证流畅性和一致性?如何才能像单机游戏一样编写网游?敬请观看《帧锁定同步算法》 《帧锁定同步算法》转载请注明出处:

http://www.skywind.me/blog/archives/131

算法概念

该算法普遍要求网速RTT要在100ms以内,一般人数不超过8人,在这样的情况下,可以像单机游戏一样编写网络游戏。所有客户端任意时刻逻辑都是统一的,缺点是一个人卡机,所有人等待。

  1. 客户端定时(比如每五帧)上传控制信息。
  2. 服务器收到所有控制信息后广播给所有客户。
  3. 客户端用服务器发来的更新消息中的控制信息进行游戏。
  4. 如果客户端进行到下一个关键帧(5帧后)时没有收到服务器的更新消息则等待。
  5. 如果客户端进行到下一个关键帧时已经接收到了服务器的更新消息,则将上面的数据用于游戏,并采集当前鼠标键盘输入发送给服务器,同时继续进行下去。
  6. 服务端采集到所有数据后再次发送下一个关键帧更新消息。

这个等待关键帧更新数据的过程称为“帧锁定” 应用案例:大部分RTS游戏,街霸II(xbox360),Callus模拟器。

……

阅读全文

网络游戏南北互通问题分析

网络游戏南北互通问题方案

网络游戏用户按接入分,有多数的电信用户,次多数的网通用户,又有处于教育网的学生用户,造成了互联互通上极大的障碍。又由于当今游戏用户数据的越来越强的集中性和游戏服务器的分散性之间无可避免的矛盾,无法将游戏平台划分成为一个个独立的世界。

在上次的文档“QQ游戏服务器分布说明”后又补充了一篇“QQ游戏服务器响应速度”,可以发现QQ游戏服务器除去黑龙江,吉林,辽宁三省的大量网通用户外,在各地相对于电信和网通的访问速度都还是比较迅速的。下面是一些分析:

如果我们设计要求最高的实时性游戏的话,本着200ms的基准是完全合理的。

不同情况和不同游戏对网速的需求

网络情况\属性 响应时间 棋牌类游戏 竞技类游戏 实时性游戏
< 250ms 满足 满足 满足
250ms-450ms 满足 基本满足 N/A
450ms-1000ms 基本满足 难满足 N/A
恶劣 > 1000ms 难满足 N/A N/A
……

阅读全文

网络游戏同步法则

网路的硬件也有限,而人的创造也无限,在公网平均130ms的Latency下,是不存在“完全的”的同步情况。如何通过消除/隐藏延时,将用户带入快速的交互式实时游戏中,体验完美的互动娱乐呢?

以下六点,将助你分清楚哪些我们可以努力,哪些我们不值得努力,弄明白实时游戏中同步问题关键之所在,巧妙的化解与规避游戏,最终在适合普遍用户网络环境中(200ms),实现实时快速互动游戏:

1. 基本情况:

(A) 网络性能指标一:带宽,限制了实时游戏的人数容量
(B) 网络性能指标二:延时,决定了实时游戏的最低反应时间

2. 两个基本原则:

(A) 让所有的用户屏幕上面表现出完全不同的表象是完全没有问题的。
(B) 把这些完全不同表象完全柔和在一个统一的逻辑中也是完全没有问题的。

3. 同步的十二条应对策略:

(A) 最大可能减少游戏中的数据传输
(B) 将阻塞通信放到线程池中实现
(C) 永远不要为了等待某个数据而不让游戏进行下去
(D) 利用预测和插值改进游戏的效果
(E) 当使用预测插值的时候传送的数据不仅包括坐标,还需要速度和加速度
(F) 将输入数据枷锁或者队列化(例如键盘消息队列),直到下次发送数据的时刻,传统的方法是在固定的时间(发送数据前)检测键盘,在游戏的原理上隐藏延时
(G) 使用事件调度表,将需要在所有用户客户端同时发生的事件,提前广播到所有用户
(H) 使用多次攻击来杀死一个精灵,尽量减少一次性的、确定性的、延时敏感的事件
(I) 延长子弹或者火箭在空中飞行的时间(在其飞行的同时,在所有客户端进行预测插值)
(J) 所有物体从一个地方移动到另外一个地方都需要时间,避免诸如“瞬间移动”的设计
(K) 尽量使游戏中所有精灵,飞船或者其他物体,都按照可预测的轨迹运行,比如在移动中增加惯性
(L) 充分发挥创造力,尽最大可能的合并游戏中前后相关的事件,合并游戏中存在的延时此问题,需要在技术上改进的同时也需要策划有所重视,规避一些影响较大的设计,巧妙的隐藏”延时”

4. 同步问题现状:

(A) 重视程度不够:很多人尚未意识到此问题的存在,曾有公司花半年时间打算做一款“松鼠大战”的网络版。
(B) 技术上无彻底解决方案:对于多数程序员,单机游戏技术善未成熟就匆匆步入网络时代。
(C) 研究这个技术需要条件:需要有实力的公司才能提供,无此条件,即便有能力的程序员也无法成功。

5. 目前网游的三大技术难题:

(A) 服务器的响应问题:如何使服务器在支持越来越多的人数的情况下提供最高的响应。
(B) 同步问题:如何在有限的网络响应情况下,实现快速实时类游戏,提供最完美的交互。
(C) 服务器分布式问题:如何在统一用户数据的情况下,利用分部式将各个分散的“世界”统一到一个“世界”中。

谁能真正解决好以上三个问题,配合策划在设计上的突破,将使其他人在至少两年内无法超越。

6. 相关补充:

(A) 网格技术现在还是抄作,真正用到游戏中,还有很多技术难点需要突破(比如:目前网格的单位计算时间是以秒计算).
(B) 其实与很多人想法相反的是现在3D技术早已不是主要的矛盾。而现在国内外对于以上三个问题可以说处于同一个起跑线上,完全有机会取得先机。
(C) 现在解决同步问题已经很紧迫,而同时所需要的环境也已经成熟,只要有所关注,半年之内可以得出较成熟的结论

那么具体怎么解决呢?再下一步怎么办?
这就得自己去实践了,我只说这么多了,哈哈,不然又教懒了那些成天再网上搜方案的人。

转载请著名出处:http://www.skywind.me/

……

阅读全文