精华内容
下载资源
问答
  • 通过分析TPSN同步协议和星型网络结构特征,针对无线传感器网络低功耗的特点及其对时钟同步算法精度要求,提出了一种广播式TPSN同步协议和节点本地时钟自校正相结合方法。
  • 通过精简IEEE1588协议发送follow-up报文,来降低ZigBee网络开销,同时改变了同步信息发起者,由主节点换成从节点,从而适应了ZigBee网络节点即时加入和即时离开的特点。通过实际试验测定,该算法适合于无线...
  • 在明确光纤时频同步技术原理与技术特点的基础上,分别介绍了光纤时间同步、频率同步、网络化同步等主要技术现状,指出地基时频网络建设重难点。对制约光纤时频同步技术实用化问题进行了分析,认为商用网络中远...
  • 0 引言 无线跳频自组织网络是以跳频通信作为无线传输信道,以自组织方式进行组网的一种军事...跳频同步技术是跳频自组网的一种常用机制,现已成为跳频组网中不可或缺的技术手段。对这种网络的同步接入技术,国内外一直
  • 应用ATM和DWDM技术同步光纤网络通信网,熊伟,朱有产,分析传统同步光纤网络(SONET)通信网的特点。采用异步转移模式(ATM)和传输技术密集波分复用(DWDM)对基础通信网络进行标准化改造。将时分
  • 将P2P技术引入了网络数据库领域,可以很好地实现网络数据库系统高效率、大容量及...本文在明确P2P网络特点的基础上,重点研究了P2P数据库同步系统,涉及到系统体系结构、数据库信息同步的策略及数据节点状态表维护等。
  • 美国国家半导体公司(National Semiconductor Corporation)推出一款全新电压模式同步降压控制器,其特点是可以驱动多种不同高电流负载点应用,特别是打印机、电信、网络联系及嵌入式计算等设备中。  这款型号...
  • 美国国家半导体公司(National Semiconductor Corporation)宣布推出一款全新电压模式同步降压控制器,其特点是可以驱动多种不同高电流负载点应用,特别是打印机、电信、网络联系及嵌入式计算等设备中。...
  • TD-SCDMA技术特点浅析

    2020-03-04 21:39:20
    TD-SCDMA系统综合采用了联合检测、智能天线和上行同步等先进技术,系统内多址和多径干扰得到了极大缓解,从而有效地提高了频谱利用率,进而提高了整个系统容量。具体来讲,联合检测和上行同步可极大降低小区内...
  •  LM2853是国半SIMPLE SWITCHER高效率同步降压稳压器系列最新型号产品,其特点是电源转换效率高达95%。这系列芯片还有其他型号产品可供选择,例如LM3100是一款1.5A的同步降压稳压器,输入电压介于4.5V与36V之间,...
  •  LM2853 降压稳压器是NS SIMPLE SWITCHER 高效率同步稳压器系列最新型号产品,其特点是电源转换效率高达 95%。这系列芯片还有其他型号产品可供选择,例如 LM3100 是一款 1.5A 的同步降压稳压器,输入电压介于 4.5...
  • 本文将结合一个实际案例,讲解Oracle复制技术在分布式信息系统中的同步应用,希望通过这篇文章,大家能更好理解Oracle复制技术。  引言  基于WAN分布式管理信息系统是当前跨多地域企事业单位...

    本文将结合一个实际案例,讲解Oracle复制技术在分布式信息系统中的同步应用,希望通过这篇文章,大家能更好的理解Oracle复制技术。

      引言

      基于WAN的分布式管理信息系统是当前跨多地域企事业单位信息处理的首选。福建省运政管理信息系统是覆盖全省14个市运管处、84个县运管所的WAN分布式网络管理系统,根据业务特点和实际应用特征,全省数据存储分为二级,在省局中心设立全省数据存储中心,各市处设立本市处数据存储中心,省局数据中心又分内网数据中心和外网数据中心。本文运用Oracle高级复制技术实现各数据中心的数据同步。

      1 Oracle高级复制技术

      Oracle高级复制,也称为对称复制,有基于整个表的复制和基于部分表的复制两种复制方法。这两种复制主要是通过多主复制和可更新快照复制两种机制实现的。同时还可以将这两种复制机制结合起来以满足不断变化的业务需求。

      1.1多主复制

      多主复制方法支持全表在各个主节点间的对称复制,允许所有主节点对主表有更新操作的权力。任何—个主节点上的复制表的更新都会被传播并直接应用到其他所有主表。一个主节点出现问题,不会影响其他主节点之间的传播。

      多主复制采用一种称为“延迟远程过程调用(deferred remoteprocedure calls RPCs)”机制。各节点之间变化的传播,既可以以基于事件的方式立即传播,也可以从某个特定的时间点(如在网络空闲)开始传播。在传播变化时,如果其中的一个远端系统没有准备好,传播变化的延迟远程过程调用就会保存在其本地队列中,等到系统准备好以后再执行。

      1.2可更新快照复制

      Oracle将只读快照机制扩展为一种允许快照可更新的对称复制。快照更新的传播方式也是采用了和多主复制一样的延迟远程过程调用机制。

      快照是对出现在特定时刻的数据的复制,既可以是包含一个主表的完全拷贝,也可以是满足基于值的选择标准的主表中行的子集。快照在主节点的刷新是按照一定的时间间隔或用户单独请求进行的。最后一次刷新后主表的任何变化也同样被传播并应用到快照。多个快照的刷新是在一个一致的事务中完成的,这就确保了数据和引用的完整性。

      1.3混合配置

      可以将多主复制和可更新快照结合在一起,构成一种新的混合配置,这种配置可以完成对全表或子表的复制。例如,一个系统具有两个不同地理区域的中心节点,这两个不同的地理区域下面还有一些分支机构,可以把两个中心节点看作是互为备份节点,采用多主复制方法在两个中心节点之间复制数据,同时采用只读或可更新快照复制方法在区域范围中的主节点之间复制全表或主表。这种配置的一个显著好处就是当其中的一个中心发生问题时,快照的主节点可以被重新定义到另一个良好的中心节点上,从而提高了系统的可靠性。

      1.4过程级复制

      这种复制方法主要应用在存在大量数据以及采取批处理方式操作数据的情况。

      2实际应用

      2.1福建省运输管理局网络环境

      福建省运输管理局根据系统业务的需要,建立了全省的省、市、县业务VPN三级网络系统,各数据中心均采用oracle数据库系统,整个数据的存储采用二级分布存储,以确保全省业务数据存储的快速、稳定、安全。全省数据中心分布如图1。

     

    全省数据中心分布图

     

      各级数据中心的存储原则:省局数据中心(内网)汇集全省各市运管处的所有业务数据,为各市实现异地备份,提供跨地市数据查询,协助完成异地执法稽查,通过内外网数据交换,实现内网相关数据流向外网,外网提交的数据进入内网,为公众提供数据查询与业务力、理等服务。各市运管处只为本市所辖县的运管所提供存储服务,并将数据汇集到省局数据中心,出现数据故障时自动从省局读取数据进行数据恢复。

      基于以上的数据存储原则,整个数据同步机制主要采用Oracle复制技术的可更新快照机制。省局的数据库系统设置为主数据库,各市处的数据库系统设置为从数据库,所以整个分布式数据库系统是“一主多从”的结构。使用Oracle系统中的增量复制技术,定时或手动进行主数据库与从数据库的数据更新。从数据库复制到主数据库的是全部数据,只要从数据库中的数据有变化,就会反映到主数据库中;主数据库复制到从数据库的是与本市相关的业务数据。省局内网与外网数据中心、省局与省厅之间数据交换同样采用可更新快照要制实现。

      2.2数据复制以及各中心的数据同步过程

      数据库复制操作可以由各市处数据库发起,发起的方式可以是定时自动复制也可以是手动复制。实现数据复制可以用命令方式或用Oracle系统的Advanced replication manger来定制。下面采用命令方式,以省局和厦门两点为例描述主从数据中心节点的数据同步复制的操作步骤。

      2.2.1实现数据库复制的前提

      (1)用system身份登录各数据库,查看v$option视图,如果其中Advanced replication为TRUE,则支持高级复制功能,否则不支持。

      (2)打开tnsnames.ora文件,设置数据库初始化参数要求:

      ①db_domain=fjysgl.com.cn,/指明数据库的域名(默认的是WORLD),这里用fjysgl.com.cn。

      ②global_names=true//它要求链接(database link)和被连接的数据库名称一致,因而全局数据库名为:db_name+”.”+db_domain。

      ③有跟数据库job执行有关的参数。

      job_queue processes=l //定义SNP进程的启动个数为n,系统缺省值为0,正常定义范围为0—36,根据任务的多少,可以配置不同的数值。 job_queue_interval=60 //定义系统每隔N秒唤醒该进程一次,系统缺省值为60秒,正常范围为1~3600秒。 distributed_transactions=lO open._links=4

      2.2.2实现数据库的同步复制操作

      省局数据中心与厦门市处数据中心的具体配置如表1所示。

      (1)确认网络畅通,两中心数据库服务器之间可以互相访问,在tnsnames.ora里设置数据库连接字符串。

      ①修改厦门市处数据库连接字符串。

      fjyg=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS= (PROTOCOL=TCP)(HOST=10.1.1.3)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=f]yg)))

      运行$tnsping fjyg,出现以下提示符:

      Attempting 10 contact(ADDRESS=(PROTOCOL=TCP) (HOST=10.1.1.3)(PORT=1521))

      OK(10毫秒)则表明有厦门市处数据库可以访问省局中心数据库。

      ②在省局数据库作同样类似配置,并确认$tnsping xm是通的。

      (2)改数据库全局名称,建公共的数据库链接。

      ①用system身份登录xm数据库:

      alter database rename global_name t0 xm.1jysgl.com.cn:

      用system身份登录fjyg擞据库:

      alter database rename global_name to fjyg.1jysgl.com.cn:

      ②用system身份登录xm数据库:

      create public database link fjyg.fjysgl.com.cn using fjyg’:

      测试数据库全局名称和公共的数据库连接:

      select。from global_name@t]yg.fjysgl.com.cn:

      返回结果应为fjYg.fjysgl.com.cn;

      用system身份登录fjyg数据库:

      create public database link xm.fjysgl.com.cn using‘xm’;

      测试数据库全局名称和公共的数据库链接。

      (3)建立管理数据库复制的用户repadmin,并赋权。

      ①用system身份登录xm数据库,分别运行如下命令:

      create user repadmin identified by repadmin default tablespace users temporary tablespace temp; execute dbms_defer_sys.register_propagator(‘repadmin’): grant execute any procedure to repadmin; execute dbms_repcat_admin.grant_admin_any_repgroup (‘repadmin’): grant comment any table t0 repadmin; grant lock any table tO repadmin;

      ②同样用system身份登录旬yg数据库,运行以上的命令,管理数据库复制的用户repadmin,并赋权。

      (4)在数据库复制的用户repadmin下创建私有的数据库链接。

      ①用repadmin身份登录xm数据库。

      create database link fjYg.fjysgl.com.cn connect Io repadmin identified by repadmin;

      ②用repadmin身份登录fjyg数据库。

      create database link xm.fjysgl.com.cn connect to repadmin identified by repadmin;

      在这里以ORACLE系统的例程用户的scott及dept表。

      (5)创建或选择实现数据库复制的用户和对象,给用户赋权,数据库对象必须有主关键字。

      (6)创建要复制的组scott_mg,加入数据库对象,产生对象的复制支持。

      ①用repadmin身份登录xm数据库,创建主复制组。

      scott_mg execute dbms_repcat.create_master_repgroup (‘scott_mg’):

      ②在复制组scott_mg里加入数据库对象。

      execute dbms_repcat.create_master_repobject(sname=>'scott', oname=>'dept',type=>'table',use_existing_object=>true. gname=>。scotLmg’):

      ③对数据库对象产生复制支持。

      execute dbms_repcat.generate_replication_support(‘scott','dept', ‘tabIe’):

      ④确认复制的组和对象已经加入数据库的数据字典。select gname.master。status from dba_repgroup;select from dba_repobject;

      (7)创建主复制节点。

      ①用repadmin身份登录xm数据库,创建主复制节点。execute dbms_repcat.add_master_database

      (gname=>'sco~_mg',master=>'rjyg.fjysgLcom.cn., use_existing_objects=>true.copy_rows=>false, propagation_mode=>。asynchronous');

      ②确认复制的任务队列已经加入数据库的数据字典。select’from useriobs;

      (8)使同步组的状态由停顿(quiesced)改为正常(normal)。

      ①用repadmin身份登录xm数据库,运行以下命令:execute dbms_repcat.resume_master_activity('scott_mg',false);

      ②确认同步组的状态为正常(normal)。select gname,master,status from dba_repgroup;

      ③如果这个①命令不能使同步组的状态为正常(normal),可能有一些停顿的复制,运行以下命令进行处理:execute dbms_repcat.resume_master_activity('scott,mg',true);

      (9)创建复制数据库的时间表,假设10分钟自动复制一次。

      ①用repadmin身份登录xm数据库,运行以下命令:

      SQL>begin dbms_defer_sys.schedule_push (destination=>'fjyg.fjysgl.com.cn.,interval=>’sysdate +10/1440',next_date=>sysdate);end;/ SQL>be_qin dbms_defer_sys.schedule_purge(next_date=>sysdate. interval=>’sysdate+10/1440',delay_seconds=>0. rollback_segment=>”): end; /

      ②用repadmin身份登录巧yg数据库,运行与①相似命令。

     

    登陆数据库

     

      通过以上的配置即可实现省局与厦门市处二个数据中心之间的数据同步复制,其他点省局与福州处、省局与泉州处等使用相同的方法进行处理。

      对于省局中心的内外网数据库服务器,因为正常工作时间,内外网均不能停顿,而内外网又不能物理连通,于是设定在每天晚上非工作时间(或其它时段)为维护时段,该时段内外网均停止作业,由系统管理员把与内外网DB相连的所有网线断开,用一根直连网线把两台DB连接,使用相同的方式实现内外网数据的同步。

      3 结束语

      Oracle的高级复制功能为分支机构多、地理范围广的大型企事业单位的分布式数据库系统提供了很好的各中心数据同步的实现方案。而随着网络技术的发展,这种应用也显得越来越重要,变得越来越复杂。为充分利用数据复制来提高数据的可用性和系统的性能,在进行复制之前应作出详细的需求分析才能取得更好的应用效果。

    展开全文
  • 参考解密:腾讯如何打造一款实时对战手游从《王者荣耀》来聊聊游戏同步《王者荣耀》技术总监复盘回炉历程:没跨过这三座大山,就是另一款MOBA霸占市场了 纵观AppStore畅销榜前十游戏,过半都支持玩家实时...

    转载自:https://www.jianshu.com/p/81050871cce7

    参考
    解密:腾讯如何打造一款实时对战手游
    从《王者荣耀》来聊聊游戏的帧同步
    《王者荣耀》技术总监复盘回炉历程:没跨过这三座大山,就是另一款MOBA霸占市场了

    纵观AppStore畅销榜前十的游戏,过半都支持玩家实时的PK或者合作攻关。由于实时对战有玩家之间自发进行强互动的特点,活跃度和社交强度都是比较高,为游戏的用户活跃和流水的提高奠定了坚实的基础。腾讯的游戏开发团队,很早就观察到实时对战这一核心玩法对游戏生命周期影响的重要性,因此在自研产品方面,加大力度开发围绕实时对战这一核心玩法的游戏,从而诞生了《王者荣耀》、《穿越火线·枪战王者》、《全民超神》、《全民突击》、《天天炫斗》等一大批优秀的作品,其中不乏日活跃过千万的大作。而早期的休闲类游戏如《全民飞机大战》等,也加入了实时双打等游戏特性,所以现在依然可以经常在AppStore畅销榜前十看到《全民飞机大战》这款游戏的身影。既然实时对战是一个非常重要的游戏玩法,为什么我们现在看到的许多游戏,都不具备这一的玩法,或者并不是游戏的主要玩法?其中一个重要的原因,就是开发实时对战的功能,在技术上需要有一定的门槛。本文希望能向大家分享腾讯是如何跨过这些门槛,解决实时对战游戏开发的一系列核心技术难题。

    首先我们介绍实时对战手游中最难解决的技术问题——弱网络下的同步问题。

    通过对玩家的游戏数据进行观察,发现玩家的游戏环境存在很大差异,不同玩家会使用不同的2G/3G/4G/Wifi网络,不同网络之间的延迟相差很大。另外移动网络质量不稳定,且都是按流量收费,这些都是需要考虑的问题。手机在网络间的切换,又会造成底层网络断线、地址变化等问题,都是常见的情况。这些问题的统一解决手段,最重要的是通盘考虑各种需求,选择一个合理的游戏状态同步模型。

     

    不同网络间的延时

     

    腾讯在大量游戏开发的实践中,总结出三种游戏的同步模型:

    一、MMOG模式

    这种同步模型,在端游时代就使用的非常广泛,特别是MMORPG里面。

    它的主要实现要点是:服务器负责计算全部的游戏逻辑,并且广播这些计算的结果,客户端仅仅负责发送玩家的操作,以及表现收到的游戏结果。一般来说,玩家发送一个操作到服务器上,服务器根据玩家操作去修改内存中的游戏世界模型,同时运算游戏世界对这个操作的反应,然后把这些反应都广播给相关的多个客户端,每个客户端负责把这些数据表现出来给玩家看。

    这种做法的优点是非常安全,由于整个游戏逻辑都在服务器上,服务器只接受合法的玩家操作,一切都经过既定逻辑的运算。另外一个优点是游戏的逻辑更新很方便,因为主要逻辑都在服务器端。一般的游戏玩法需要更新,游戏开发团队自己更新重启服务器就可以了,无需让千万个手机去下载更新包。

    但是这种做法的缺点也很明显,首先就是用户的体验非常依赖网络质量,如果一个用户的网速慢,其他玩家都会发现他在游戏中明显的变卡。

    另外一个缺点就是服务器负责了太多的游戏逻辑运算。在动作游戏里,服务器往往需要针对二维或者三维空间进行运算。

    最后,使用这种同步方案,由于每个游戏表现都要以数据包发往客户端,所以当一起玩的用户数量较多,这种广播的数据包量就会非常大。

    因此根据以上的特点,腾讯一般会在那些同局游戏人数不太多,但讲求玩法变化快和安全性高的游戏中采用这种同步方案。腾讯自研手游中比较著名的《穿越火线·枪战王者》、《全民超神》、《炫斗之王》都是使用这种方案。

     

    image.png

    二、主机模式

    这种同步方案的做法是:以参与对战的一个客户端为“主机”,其他的客户端为“副机”。

    游戏逻辑的主要运算由“主机”完成,所有的“副机”把操作指令,通过服务器中转,集中发送给“主机”;“主机”完成游戏运算后,把结果指令再通过服务器中转,广播给所有的“副机”。

    这个方案看起来有点奇怪,但是却有很明显的优点:首先是大量的实时动作游戏,其游戏过程的逻辑代码,都是在客户端上开发和运行的。客户端的游戏引擎对于二维、三维空间中的位置运算、碰撞检测等功能,都有很好的支持。

    因此把整个游戏逻辑由客户端负责,就能让服务器端无需再开发这部分功能。服务器只负责做转发、广播的操作,所以能承载的人数和第一种方案有数量级上的差别。由于“主机”客户端运行游戏逻辑,所以其体验是最好的,就算“副机”由于网络不佳造成体验下降,对于“主机”来说,只是发现“副机”动作有点迟缓而已。

    在以PVE玩法为主的游戏中,用户关注的是自己的体验,不会太在意同伴的准确动作,这种情况下,主机模式就是一种不错的同步方案。腾讯的《全民飞机大战》的双打模式就是采用这种方式,效果相当不错。

     

    image.png

    三、帧同步模式

    又叫“锁步模式”。这种模式用形象的比喻来说,就是把所有参与对战的客户端,看成是排成一列的囚犯。这些囚犯们的左脚都被链子所在一起,因此他们如果要往前走,就只能同时迈步,如果其中某个人走快了,或者走慢了,都会让整队人停下来。

    在实现上,一般是以服务器按固定的帧率,来搜集每个客户端的输入,然后把这些输入广播给所有的客户端;由于每个操作指令到达所有客户端的时间(帧)都是一样的,所以每个客户端运算的结果也是一样的,同样的输入就会得到同样的结果。

    这就好像:其他玩家通过网络,把操作手柄接到你的手机。这种同步方案,是传统单机-局域网游戏中最常用的。

    这种同步模型的最大优点是:强一致性。每个客户端的表现是完全一样的,非常适合高度要求操作技巧的游戏。由于广播的仅是玩家的操作,所以数据量很少。不管游戏中的角色数、状态量有多大、多复杂,都不会影响广播的数据量。

    但是这个方案也有缺点:对所有玩家的延迟都有要求,一般来说要求在50毫秒以内。如果有一个客户端网络卡了,所有的客户端都要停下来等,大家在玩《星际争霸》就见识过:一个玩家断线,全部玩家的游戏都暂停。腾讯游戏中的《王者荣耀》、《全民突击》由于竞技性非常强,所以采用了这种方案。

    另外在帧同步模式中,数据同步的频率较高,网络延迟越小越好。由于TCP的滑动窗口机制和重传机制,导致延时无法控制,因此帧同步一般采用udp进行网络传输,但udp又会衍生出可靠性问题,对于客户端,如果某些udp包没有收到,就会出现丢帧的情况,所以这里我们自己研发了一套《可靠UDP传输》的协议,应用在《王者荣耀》项目。关于《可靠UDP传输》的相关技术介绍,后续会作为专题继续分享给大家。大体上是如此来解决:

    1. 为每个数据包增加序列号,每发一次包,增加本地序号。

    2. 每个数据包增加一段位域,用来容纳多个确认符。确认字符多少个,跟进应用的发包速率来觉得,速率越高,确认字符的数量也相应越多。

    3. 每次收到包,把收到的包上序列号变为确认字符,发送包的时候带上这些确认字符。

    4. 如果从确认字符里面发现某个数据包有丢失,把它留给应用程序来编写一个包含丢失数据的新的数据包,必要的话,这个包还会用一个新的序列号发送。

    5. 针对多次收到同一包的时候可以放弃它

    image.png

    乐观锁&断线重连
    囚徒模式的帧同步,有一个致命的缺陷就是,若联网的玩家有一个网速慢了,势必会影响其他玩家的体验,因为服务器要等待所有输入达到之后再同步到所有的c端。

    另外如果中途有人掉线了,游戏就会无法继续或者掉线玩家无法重连,因为在严格的帧同步的情况下,中途加入游戏是从技术上来讲是非常困难的。因为你重新进来之后,你的初始状态和大家不一致,而且你的状态信息都是丢失状态的,比如,你的等级,随机种子,角色的属性信息等。

    比如玩过早期的冰封王座都知道,一旦掉线基本这局就废了,需要重开,至于为何没有卡顿的现象,因为那时都是解决方案都是采用局域网的方式,所以基本是没有延迟问题的。

    后期为了解决这个问题,如今包括王者荣耀,服务器会保存玩家当场游戏的游戏指令以及状态信息,在玩家断线重连的时候,能够恢复到断线前的状态。

    不过这个还是无法解决帧同步的问题,因为严格的帧同步,是要等到所有玩家都输入之后,再去通知广播client更新,如果A服务器一直没有输入同步过来,大家是要等着的,那么如何解决这个问题?

    采用“定时不等待”的乐观方式在每次Interval时钟发生时固定将操作广播给所有用户,不依赖具体每个玩家是否有操作更新。如此帧率的时钟在由服务器控制,当客户端有操作的时候及时的发送服务器,然后服务端每秒钟20-50次向所有客户端发送更新消息。如下图:

    image.png


    上图中,我们看到服务器不会再等到搜集完所有用户输入再进行下一帧,而是按照固定频率来同步玩家的输入信息到每一个c端,如果有玩家网络延迟,服务器的帧步进是不会等待的,比如上图中,在第二帧的时候,玩家A的网速慢,那么他这个时候,会被网速快的玩家给秒了(其他游戏也差不多)。但是网速慢的玩家不会卡到快的玩家,只会感觉自己操作延迟而已。

     

    四、帧同步的技术要点

    参考帧同步游戏开发基础指南

    在一般的帧同步系统中,会有一个Relay Server负责广播(转发)所有客户端的数据。为了让各个客户端能持续的运行,而不是卡住,所以需要定时的下发一个个“网络帧”数据来驱动各个客户端。因为客户端已经放弃了本地的时间,本地的循环驱动,所以这些“网络帧”就必不可少了。这些网络帧大部分实际上是“空”的,只有当玩家有输入的时候,才会把玩家的游戏操作的数据,填入到网络帧数据包中。对于客户端来说,就好像有很多键盘、鼠标、游戏手柄在通过网络操作自己一样。

    一般来说,大多数的游戏客户端引擎,都会定时调用一个接口函数,这个函数由用户填写内容,用来修改和控制游戏中各种需要显示的内容。比如在Flash里面叫OnEnterFrame(),在Unity里面叫Update()。这类函数通常会在每帧画面渲染前调用,当用户修改了游戏中的各个角色的位置、大小后,就在下一帧画面中显示出来。而在帧同步的游戏中,这个Update()函数依然是存在,只不过里面大部分的内容,需要挪到另外一个类似的函数中,我们可以称之为UpdateByNet()函数——由网络层不断的接收服务器发来的“网络帧”数据包,每收到一个这样的数据包,就调用一次这个UpdateByNet()函数,这样游戏就从通过本地CPU的Update()函数的驱动,改为根据网络来的UpdateByNet()函数驱动了。显然,网络发过来的同步帧速度会明显比本地CPU要慢的多,这里就对我们的游戏逻辑开发提出了更高的要求——如何同步的同时,还能保证流畅?

    1.帧数据要小
    帧同步游戏中,由于需要“每一帧”都要广播数据,所以广播的频率非常高,这就要求每次广播的数据要足够的小。最好每一个网络帧,能在一个MTU以下,这样才能有效降低底层网络的延迟。同样的理由,我们为了提高实时性,一般也倾向于使用UDP而不是TCP协议,这样底层的处理会更高效。但是,这样也会带来了丢包、乱序的可能性。因此我们常常会以冗余的方式——比如每个帧数据包,实际上是包含了过去2帧的数据,也就是每次发3帧的数据,来对抗丢包。也就是说三个包里面只要有一个包没丢,就不影响游戏。另外我们还会在RelayServer上保存大量的客户端上传的数据,如果客户端发现丢了包(如果乱序了也认为是丢包),那么就发起一次“下载”请求,从服务器上重新下载丢失了的帧数据包(这个可能会使用TCP)。这一切,都依赖于每个帧数据要足够的小。所以我们一般要求,每次客户端发送的数据,应该小于128字节。你可以大概计算一下,如果我们的游戏有4个玩家,我们的冗余是3帧,那么一个下行的网络帧数据包大小会到128x4x3=1536字节,而每秒我们发15个网络帧,那么占用的带宽会到1536x15=23,040字节/秒,加上一些底层协议包头也就是24kB/s,这个速度看起来已经要求手机是3G网络才能支持了(实测中GPRS一般很难稳定到这个速度)。
    我们使用的游戏引擎,特别是3D游戏引擎,里面使用的位置数据,大多数是浮点数,大家知道,一个浮点数需要占用8个字节,这可比简单的整数4个字节大了足足一倍。而我们需要广播的游戏操作,往往不需要那么高的精确度,所以我们应该把这些浮点数,想办法变成整数来广播。有时候我们甚至有可能只用1~2个字节(0-256-65535)来表达一个操作所需要的数字(比如按键值、鼠标坐标)。这样就能大大降低广播的数据长度。最简单的方法,就是把浮点数乘以1000或100然后取整。
    另外一个降低广播数据量的做法就是自己编写序列化函数:一般现代编程语言,特别是面向对象的语言,都带有把对象序列化和反序列化的功能。我们要广播游戏操作的时候,这些操作往往也是一个个的“对象”,因此最简单的方法就是使用编程语言自带的序列化库来把对象转换成字节数组去广播。但是这些编程语言的默认序列化功能,为了实现诸如反射等高级功能,会把很多游戏逻辑所“不必要”的数据也序列化了,比如对象的类名、属性名什么的。如果我们自己去针对特定的数据对象来编写序列化函数,就没有这个问题了,我们可以仅仅提取我们想要的数据,甚至能合并和裁剪一些数据项,达到最小化数据长度的目的。

    image.png

     

    2.加速播放
    在网络游戏中,各个客户端的运行条件和环境往往千差万别,有的硬件好一些,有的差一些,各方的网络情况也不一致;时不时玩家的网络还会在游戏过程中,发生临时的拥堵,我们称之为“网络抖动”。网络游戏有时候还会需要有中途加入游戏的需求(乱入),有游戏录像和观看、快进录像的功能。这些功能,都可能导致客户端收到“过去时间”里的一堆网络帧,因此,客户端必须要有处理这些堆积起来的网络数据的能力。最简单的做法就是加速播放(快进)——如果收到网络数据处理完游戏逻辑后,然后在同一个渲染帧(同一次Update()函数里)内,马上继续收下一个网络数据,然后又立刻处理。这样往往能在一个渲染帧的时间内,加速赶上服务器广播的最新游戏进度。但是这样做也会有副作用,如果客户端积累的包太多(比如游戏已经开始玩了10分钟,新的用户中途加入),会导致这个用户长时间卡住,因为程序正在疯狂的下载积累的帧同步包和运算快进。为了解决这个问题,有些程序员会限制每一个渲染帧中所快进的操作次数,这样用户还是能看到画面有活动。如果实在要快进的进度太多,就要采用“快照”技术,通过定时保存的游戏状态数据,来减少快进的进度了。这个快照功能这里就不展开了。

     

    image.png

     

    image.png

    3.发送玩家操作频率
    一般来说,我们的客户端的渲染帧率都会大大高于网络帧的接收频率。如果我们每个渲染帧都去发送一次玩家操作(比如触摸屏上的手指位置),那么可能会导致发送的游戏操作远远大于收到的操作,这样做要么会让游戏操作堆积在服务器上,导致操作的严重延迟,要么导致下行的网络包非常大(服务器每次都把收到的所有操作一次下发),这样会让网络带宽占满,同样是会感觉延迟。不管怎么处理,都是不太好的结果。正确的做法应该是控制发包频率,最好是至少收到一个网络下行帧,才发送一个上行的游戏操作,避免堆积。另外,刚刚讲到的“快进”,如果我们在快速播放游戏逻辑的时候,每次播放同时也采集玩家输入去发送,那么同样会导致短时间内发送一大堆上行数据给服务器,而这些数据很可能客户端接收时产生大量的延迟。所以最好是在快进的时候不采集玩家的输入,因为玩家在看到快进过程中,实际上也很难有效的做出合理的反应,一个常见的做法,就是快进的时候,给游戏覆盖一个“等待”或“Loading”的蒙皮层,让玩家不可以输入操作。

     

    image.png

     

    image.png

    4.容忍不一致
    我们做帧同步的目标是各个客户端都能看到一致的显示。但是游戏内容有很多,有一部分内容是可以容忍“不一致”的,比如我们做飞行射击弹幕游戏,满屏幕有很多子弹,而每一颗子弹本身的存在的时间很短,如果我们不是做对打的游戏(而是一起打电脑),那么这些子弹是可以不一致的。又比如我们做一个横版过关的配合游戏,几个玩家一起打电脑控制的怪物,大家关心的是怪物是怎么被打死的,而玩法本身又比较容忍不一致(横版动作游戏的攻击范围往往比较大),所以就算有些不一致问题也不大。在以上的条件下,我们就可以尝试,把更多的游戏逻辑,从网络帧的UpdateByNet()函数里面拿出去,放回到单机游戏中的Update()函数里去。这样就算网络有点卡,起码整个画面里还是有很多东西是不会被“卡住”的。但是必须注意的是,一般玩家控制的角色的动作,包括当前客户端控制的角色,还是应该从网络帧里面获得行为数据,因为如果玩家爱控制角色不一致的太多,整个游戏场面就会差更多。很多游戏中的怪物AI都是根据玩家角色来设定的,所以一旦玩家角色的行为是同步的,那么大多数的怪物的表现还是一致的。

     

    image.png

    5.非完全实时
    一般来说,我们都希望游戏中的角色控制是灵敏的,实时的。我们的游戏角色往往在会玩家输入操作后的几十分之一秒内,就开始显示变化。在帧同步游戏中,我们可以让玩家一输入完操作,就立刻发包,然后尽快在下一个收到的网络帧中收到这个操作,从而尽快的完成显示。然而,网络并不是那么稳定,我们常常会发现一会快一会慢,这样玩家的操作体验就非常奇怪,无法预测输入动作后,角色会在什么时候起反应。这对于一些讲求操作实时性的游戏是很麻烦的。比如球类游戏,控制的角色跑的一会儿快一会儿慢,很难玩好“微操”。要解决这个问题,我们一般可以学习传输语音业务的做法,就是接收网络数据时,不立刻处理,而是给所有的操作增加一个固定的延迟,后在延迟的时间内,搜集多几个网络包,然后按固定的时间去播放(运算)。这样相当于做了一个网络帧的缓冲区,用来平滑那些一会儿快一会儿慢的数据包,改成匀速的运算。这种做法会让玩家感觉到一个固定延迟:输入操作后,最少要隔一段时间,才会起反应。但是起码这个延迟是固定的,可预计的,这对于游戏操作就便捷很多了,只要掌握了提前量,这个操作的感觉就好像角色有一定的“惯性”一样:按下跑并不立刻跑,松开跑不会立刻停,但这个惯性的时间是固定的。

     

    image.png

    6.不锁步
    我们和其他玩家一起游戏的时候,有时候不希望对方因为电脑速度比较快,网络比较好,而能比我们更早的看到游戏的运行结果,从而提早作出操作。这一点在格斗对打游戏(如《街霸》)里面非常关键,在一些RTS(《星际争霸》)里面,提早看到游戏运行结果也是很有竞争优势的。因此我们为了让网络、硬件不一样的玩家能公平游戏,往往会使用一种叫“锁步”的策略:就好像一串绑着脚镣的囚犯,他们只能一起抬起左脚,然后再一起抬起右脚的走路,谁也不能走的更快。技术上的实现,就是每个客户端都定时(每N个渲染帧)发送一个网络帧到服务器上,就算玩家没操作,也类似心跳的这样发送空数据帧,所有客户端都要完整的收到所有的其他客户端的“心跳帧”才能开始运算一次游戏逻辑。这就是让所有的客户端,都互相等待,如果任何一个客户端卡了,其他的客户端都立刻就能知道,然后弹出界面让玩家停止输入来等待。因此在很多场合,帧同步的技术也被成为“锁步”技术,事实上,在没有统一的Relay Server服务器的时代(IPX局域网连机对战的时代),帧同步的网络帧其实就是上面所说的某个客户端的“心跳帧”,是由某个客户端产生并广播的(比如以前的局域网游戏,都会由一个客户端充当Host主机)。在《星际争霸》连机游戏中,如果有一个玩家掉线了,所有其他玩家就会发现有一个界面弹出来挡住画面,表示在等某某某。这种做法实际上是牺牲了流畅度的,因为你会发现一旦有网络、硬件卡的玩家加入游戏,所有其他玩家都受他的影响。为了减少这种对流畅度的影响,我们可以在需要“锁步”的时候,尽量少锁一点,比如不是发现缺了一帧就停下来,而是缺了若干帧,还是可以以“不公平”的方式继续玩一会儿(比如几秒),如果这段时间内还是没有补齐所缺的帧,才宣布锁住游戏等待。当然这个“容忍”的帧数我们可以调节到“最大”——就是没有。那么一个完全不锁步的游戏,肯定不是一个公平的游戏,但是也会在流畅性产生最大的好处,就是完全不受其他玩家影响。在那些不是PVP(玩家对战)的帧同步游戏中,不公平这个往往问题不大。我们完全可以在游戏的不同玩法里,打开、调整、甚至关闭这个“锁步”的机制,从而让游戏最大程度的平衡公平性和流畅性。

     

    image.png

    五、王者荣耀技术总监分享历程

    参考《王者荣耀》技术总监复盘回炉历程:没跨过这三座大山,就是另一款MOBA霸占市场了

    1.状态同步

    先看一下状态同步的优点。

    第一,它的安全性非常高,外挂基本上没有什么能力从中收益。

    第二,状态同步对于网络的带宽和抖动包有更强的适应能力,即便出现了200、300的输入延迟再恢复正常,玩家其实也感受不到不太舒服的地方。

    第三,在开发游戏过程中,它的断线重连比较快,如果我的游戏崩溃了,客户端重启之后只需要服务器把所有重要对象的状态再同步一次过来,重新再创建出来就可以了。

    第四,它的客户端性能优化优势也比较明显,比如优化时可以做裁剪,玩家看不到的角色可以不用创建,不用对它进行运算,节省消耗。

    再说一下我认为的缺点。

    第一,它的开发效率相对帧同步而言要差一些,很多时候你需要保证服务器与客户端的每一个角色对象的状态之间保持一致,但事实上你很难做到一致。

    比如客户端和服务器端更新的频率,对优化的一些裁剪,网络的抖动等等,你要让每一个状态在客户端同步是比较难的,而你要想调试这些东西,来优化它带来的漏洞、不一致的现象,花费的周期也会比较长,想要达到优化好的水平也比较难。

    第二,它比较难做出动作类游戏打击感和精确性。比如说你要做一个射击类角色,他的子弹每秒钟要产生几十颗,基于状态同步来做是比较难的,因为系统在很短时间内,会产生很多数据,要通过创建、销毁、位置运算来同步。

    第三,它的流量会随着游戏的复杂度,而逐渐增长,比如角色的多少。我们做《王者荣耀》时,希望在3G、4G的网络条件下也能够玩PvP,所以我们希望它对付费流量的消耗能控制在比较合理的水平,不希望打一局游戏就消耗几十兆的数据流量。

    2.帧同步

    另一种同步策略是帧同步。

    这种技术应用的很广泛,最早的《星际争霸》《魔兽争霸3》都采用了帧同步,他们都基于局域网运行,网络的条件非常好,也不需要服务器就能搞定。帧同步的优点有几个:

    第一,它的开发效率比较高。如果你开发思路的整体框架是验证可行的,如果你把它的缺点解决了,那么你的开发思路完全就跟写单机一样,你只需要遵从这样的思路,尽量保证性能,程序该怎么写就怎么写。

    比如我们以前要在状态同步下面做一个复杂的技能,有很多段位的技能,可能要开发好几天,才能有一个稍微过得去的结果,而在帧同步下面,英雄做多段位技能很可能半天就搞定了。

    第二,它能实现更强的打击感,打击感强除了我们说的各种反馈、特效、音效外,还有它的准确性。利用帧同步,游戏里面看到这些挥舞的动作,就能做到在比较准确的时刻产生反馈,以及动作本身的密度也可以做到很高的频率,这在状态同步下是比较难做的。

    第三,它的流量消耗是稳定的。大家应该看过《星级争霸》的录像,它只有几百K的大小,这里面只有驱动游戏的输入序列。帧同步只会随着玩家数量的增多,流量才会增长,如果玩家数量固定的话,不管你的游戏有多复杂,你的角色有多少,流量消耗基本上都是稳定的。这点延伸开来还有一个好处,就是可以更方便地实现观战,录像的存储、回放,以及基于录像文件的后续处理。

    帧同步也有它的缺点。

    第一,最致命的缺点是网络要求比较高,帧同步是锁帧的,如果有网络的抖动,一段时间调用次数不稳定,网络命令的延迟就会挤压,引起卡顿。

    第二,它的反外挂能力很弱,帧同步的逻辑都在客户端里面,你可以比较容易的修改它。但为什么《王者荣耀》敢用帧同步,一方面是因为当时立项的时候开发周期很短,半年时间要做上线,要有几十个英雄,存在时间的压力,另一方面,MOBA类游戏不像数值成长类的游戏,它的玩法是基于单局的,单局的作弊修改,顶多影响这一局的胜负,不会存档,不会出现刷多少钱刷多少好的装备的问题,而且作弊之后我们也很容易监测到,并给予应有的惩罚,所以我们认为这不是致命的缺点。

    第三,它的断线重回时间很长,相信台下也有很多王者玩家,也曾碰到过闪退以后重回加载非常长的情况,甚至加载完以后游戏也快结束了,这是帧同步比较致命的问题。

    第四,它的逻辑性能优化有很大的压力。大家应该没有见到哪一款大型游戏是用帧同步来做的,因为这些游戏的每一个逻辑对象都是需要在客户端进行运算的。如果你做一个主城,主城里面有上千人,上千人虽然玩家看不到它,但游戏仍然需要对他们进行有效的逻辑运算,所以帧同步无法做非常多的对象都需要更新的游戏场景。

    3.选择

    那么我们为什么选择了帧同步而放弃了状态同步呢?

    我们前面提到它两个优点缺点是相对的,这边的优点对于那边来说就是缺点。对于我们手游立项的时候,最重要就是时间。当时市面上正在开发的MOBA手游不止王者一款,大家都在争上线的时间,所以我们要选择一个开发周期最短的方案。

    然后我们做端游的时候也有一个深刻的体会,如果要做有趣的英雄,有趣的技能,它在状态同步上面很难调出一个比较满意的效果。所以最后我们依然选择帧同步的方案。

    现在来看,选择帧同步方案之后,我们再把它的缺点进行优化或是规避,之后它带来的好处是非常明显的。《王者荣耀》重除了英雄的设计以及技能的感觉,还有很重要的一点,就是它确实在做一些非常有特色的英雄,它的技能、反馈、体验上面都做得不错,这些都是基于帧同步技术方案带来的优势。
    我们选择了方案之后,当时觉得很high,觉得这样一个技术方案开发起来得心应手,效率如此之高,做出来的效果也很好。

    但事实上,它也有好的一面,也有坏的一面,技术测试版本上线后质量不好,其中技术层面遇到的问题就是下面这三座大山。

    第一是同步性,同步性这块容易解决,其实也解决了;

    第二也是最大一块网络问题,帧同步它的网络问题导致我们对它技术方案的原理没有吃透,碰到了一些问题,那时候游戏的延迟很重,画面卡顿,能明显感觉走路抖动的现象;

    第三是性能问题,这个问题始终存在,我们也一直在优化。

    4.第一座大山:同步

    第一座大山,最容易解决的同步问题。

    帧同步的技术原理相当简单,10、20年前在应用这种技术了,从一个相同初始的状态开始,获得一个相同的输入,往下一帧一帧执行,执行时所有代码的流程走得都是一样的,这个结果调用完了以后,又有一个新状态,完成循环。相同的状态,相同的流程,不停的这样循环下去。

    这个原理虽然简单,但是你要去实现它的时候,还是会有很多坑。
    首先,我们所有的运算都是基于整数,没有浮点数。浮点数是用分子分母表达的。

    其次,我们还会用到第三方的组件,帧组件也要需要进行一个比较严格的甄别。我们本身用的公司里面关于时间轴的编辑器里面,最初也是是浮点数,我们都是进行重写改造的。

    再次,很多人初次接触帧同步里面的问题,就是在写逻辑的时候和本地进行了关联、和“我”相关,这样就导致不同客户端走到了不同的分支。实际上,真正客户端跟逻辑的话,要跟我这样一个概念无关。

    接下来还有随机数,这个要严格一致。这是实现的要点,严格按照这上面的规则写代码还是有可能不同步,本身就很难杜绝这样的问题。

    最后,真正重要的是开发者要提升自己发现不同步问题的能力,什么时候不同步了,不同步你还要知道不同步在什么点,这是最关键的。你需要通过你的经验和总结提升这样的能力。这个能力还是通过输出来看不同客户端不同输出,找到发生在什么点。

    比如在《王者荣耀》里,我们看到不同步的现象应该是这样,有人对着墙跑,你看到的和别人玩的游戏是不一样的,就像进入平行世界。

    最开始测试《王者荣耀》的,我们希望不同步率达到1%,就是100局里面有1局出现不同步,我们就算游戏合格,但实际上对于这么大体量游戏来说,这个比率是有问题的,经过我们不停的努力,现在已经控制在万分之几,一万局游戏里面,可能有几局是不同步的。

    这个问题不一定是代码原因或者没有遵循这些要点才出现的,有可能是你去修改内存,你去加载资源的时候,本地资源有损害或者缺失,或者是异常。说白了,你没有办法往下执行,大家走了不同分支,这都可能引起最终是不同步的。

    如果你不同步概率比较低,到了这种万分之几概率的时候,很难通过测试来去还原,去找到这样不同步的点。

    最开始我们游戏出现不同步的时候,就是在周末玩家开黑多的时候,随着你的概率越来越低,基本上你就自己就还原不出这些问题了,只能依靠玩家帮你还原这样的场景,来分析这样的不同步问题。

    同步性遵循这样的要点,按照这样的思路来写,加上你不同步定位的能力,有了监控手段能够去发现,这个问题其实就解决了。解决之后,你就可以好好享受帧同步的开发优势。

    5.第二座大山:网络

    第二座大山就是网络,《王者荣耀》技术测试版本出台的时候,延迟非常大,而且还是卡顿,现在看一下帧同步里面比较特别的地方。帧同步有点像在看电影,它传统的帧同步需要有buffer,每个玩家输入会转发给所有客户端,互相会有编号,按顺序输入帧。

    比如我现在已经收到第N帧,只有当我收到第N+1帧的时候,第N这一帧我才可以执行。服务器会按照一定的频率,不同的给大家同步帧编号,包括这一帧的输入带给客户端,如果带一帧给你的数据你拿到之后就执行,下一帧数据没来就不能执行,它的结果就是卡顿。

    网络绝对理想的情况下还好,但现实的网络环境不是这样的。帧同步要解决问题就是调试buffer,以前有动态的buffer,它有1到n这样的缓冲区,根据网络抖动的情况,收入然后放到队列里面。

    这个buffer的大小,会影响到延迟和卡顿。如果你的buffer越小,你的延迟就越低,你拿到以后你不需要缓冲等待,马上就可以执行。但是如果下一帧没来,buffer很小,你就不能执行,最终导致的结果你的延迟还好,但是卡顿很明显。

    如果调到帧同步的buffer,假如我们认为网络延迟是1秒,你抖动调到1秒,那得到的结果虽然你画面不抖动了,但是你的延迟极其高。如果连最坏的网络情况都考虑进去,buffer足够大,那么记过就跟看视频是一样的,平行的东西,看你调大条小。一些局部的措施我们都做过,都是一样的问题。

    具体我们怎么优化卡顿的问题呢?

    刚才提到该帧同步与buffer,这个buffer可以是1也可以到n,我们要解决我们的延迟问题,我们就让buffer足够小。事实上《王者荣耀》最后做到的buffer是零,它不需要buffer,服务器给了我n,马上知道是n,我收到n,我知道下一次肯定是n+1,所以我收到n之后马上就把n这一帧的输入执行了。

    那么为什么不卡顿了,画面不抖动了?

    最后一个关键点,是本地插值平滑加逻辑与表现分离。客户端只负责一些模型、动画、它的位置,它会根据绑定的逻辑对象状态、速度、方向来进行一个插值,这样可以做到我们的逻辑帧率和渲染帧率不一样,但是做了插值平滑和逻辑表现分离,画面不抖了,延迟感也是很好的。

    做了这些后,我们还把TCP换成UDP,在手机环境下,弱网的情况下,TCP很难恢复重连,所以最后用了UDP来做。整体来说,在网络好的情况下,它延迟也是很好的,在网络比较差的情况下做插值,也是传统CS的表现。

    我们经常见到角色A和B,有些客户端A在左B在右,有些是A在右B在左,帧同步逻辑上面AB之间的距离和坐标都是完全一样,但是画面上看到他们可能会不重合,那就是你把它们分离之后的表现。网络极其好的情况下,它应该是重合的,但是在网络差的情况下,可能会有些偏差。这里面是最重要的一块优化。

    5.第三座大山:性能优化

    第三座大山,是我们对性能的优化。

    本身帧同步逻辑上面在优化上面存在一些缺点,所有的角色都需要进行运算。这方面我们也是借助Unity的特性,如果你想追求性能上的极致,有些东西你需要寻求好的方式。

    第一点是热点的处理。

    我们是不用反射的,它都有GC性能开销,我们的做法里面,会把对象的显示隐藏放在不同的渲染层里面,尽量让整个游戏帧率是平滑的过程。还有我们本身有自己的系统,比如AI,在《王者荣耀》这样的多角色游戏中,你如果想要做出比较好的体验,那么AI就要做得比较复杂。

    而要去优化热点,我觉得就只有这三个步骤可以走。

    首先,从程序的结构上面能找到更优的,它的优化效果就是最明显的;其次,如果你的结构都是用的最好,就去挖掘局部的算法,调整你代码的一些写法。最后,如果局部的算法都已经调到最优还是没有什么办法,那只有一条路,就是牺牲整个质量,就是分帧降频。

    第二点是GC,这块刚才说不用反射,还有装箱和拆箱的行为也是尽量少用。Unity指导过我们的优化,从GC上面的考虑,他们建议每一帧应该在200个字节以内是比较好的状态,其实很难做到,王者也是每一帧在1k左右,很难做到200。

    第三点是Drawcall,这些传统的优化手段大家都用的很熟了。

    第四点是裁剪,帧同步里面是不能裁剪的,表现里面我看不到的可以降低频率或者不更新它,这在表现里面可以做的。

    第五点是3DUI的优化,比如《王者荣耀》的血条、小地图上面叠的元素等等,这些UI都比较丰富,这块我们用了31UI的方式来优化,没有用UGUI里面进行血条方面的处理。

    我们也牺牲了一些东西,我们把所有东西都加载了,在游戏过程当中,我们希望不要有任何IO行为,包括输出我们都是要布局的。你处理的决策和复杂度,如果在一帧里面放出100颗子弹,在放100颗子弹的时候一定要掉帧的,一定要在力所能及的时候把这些东西做到极致。

    展开全文
  • 现场总线是20世纪80年代末、90年代初国际上发展形成的,用千过程自动化、制造自动化、楼宇自动化等领域的...1)现场总线的技术特点(1)系统的开放性。开放系统是指通信协议公开,各不同厂家的设备之间可进行互连并实...

    现场总线是20世纪80年代末、90年代初国际上发展形成的,用千过程自动化、制造自动化、楼宇自动化等领域的现场智能设备互连通信网络。它作为工厂数字通信网络的基础,沟通了生产过程现场及控制设备之间及其与更高控制管理层次之间的联系。它不仅是一个基层网络,而且还是一种开放式、新型全分布控制系统。

    1)现场总线的技术特点

    (1)系统的开放性。开放系统是指通信协议公开,各不同厂家的设备之间可进行互连并实现信息交换,现场总线开发者就是要致力于建立统一的工厂底层网络的开放系统。这里的开放是指对相关标准的一致、公开性,强调对标准的共识与遵从。

    (2)互可操作性与互用性,可实现互连设备间、系统间的信息传送与沟通,可实行点对点,一点对多点的数字通信;不同生产厂家的性能类似的设备可进行互换。

    e3dc772c58ccef282ffe02f6aea77584.png

    (3)现场设备的智能化与功能自治性。它将传感测量、补偿计算、工程量处理与控制等功能分散到现场设备中完成,仅靠现场设备即可完成自动控制的基本功能,并可随时诊断设备的运行状态。

    (4)系统结构的高度分散性。由于现场设备本身已可完成自动控制的基本功能,使得现场总线已构成一种新的全分布式控制系统的体系结构。从根本上改变了现有DCS集中与分散相结合的集散控制系统体系,简化了系统结构,提高了可靠性。

    (5)对现场环境的适应性。工作在现场设备前端,作为工厂网络底层的现场总线,是专为在现场环境工作而设计的,它可支持双绞线、同轴电缆、光缆、射频、红外线、电力线等,具有较强的抗干扰能力,能采用两线制实现送电与通信,并可满足本质安全防爆要求等。

    2)现场总线的优点

    由于现场总线的以上特点,特别是现场总线系统结构的简化,使控制系统的设计、安装、投运到正常生产运行及其检修维护,都体现出优越性。

    (1)节省硬件数量与投资。

    (2)节省安装费用。

    (3)节省维护费用。

    (4)用户具有高度的系统集成主动权。

    (5)提高了系统的准确性与可靠性。

    3)典型现场总线简介(

    1)基金会现场总线。基金会现场总线技术,是在过程自动化领域得到广泛支持和具有良好发展前景的技术。它以ISO/OSI开放系统互连模型为基础,取其物理层、数据链路层、应用层为基金会现场总线通信模型的相应层次,并在应用层上增加了用户层。

    基金会现场总线分低速H1和高速H2两种通信速率。H1的传输速率为3125kb/s通信距离达1900m(可加中继器延长)、可支持总线供电,支持本质安全防爆环境。H2的传输速率为1Mb/s2.5Mb/s两种,其通信距离为750m500m

    (2)LonWorks现场总线。

    LonWorks是又一具有强劲实力的现场总线技术,它采用了ISO/O SI模型的全部七层通信协议,采用了面向对象的设计方法,通过网络变量把网络通信设计简化为参数设置,其通信速率从300b/s15Mb/s不等,直接通信距离可达到2700m(78kb/s,双绞线),支持双绞线、同轴电缆、光纤、射频、红外线、电源线等多种通信介质,并开发相应的本安防爆产品,被誉为通用控制网络。

    (3)Profibus现场总线。

    Profibus是作为德国国家标准DIN 19245和欧洲标准prEN50170的现场总线。ISO/OSI模型也是它的参考模型。

    Porfibus支持主-从系统、纯主站系统、多主多从混合系统等几种传输方式。

    17e8490d32c05a864480cb0cc2cb7d28.png

    Profibus的传输速率为96~12kb/s。最大传输距离在12kb/s时为1000m,15Mb/s时为400m,可用中继器延长至10km。其传输介质可以是双绞线,也可以是光缆,最多可挂接127个站点。

    (4)CAN现场总线。

    CAN是控制网络control area network的简称,最早由德国BOSCH公司推出,用千汽车内部测量与执行部件之间的数据通信。其总线规范现已被ISO国际标准组织制定为国际标准,得到了MotorolaIntelPhilipsSiemensNEC等公司的支持,已广泛应用在离散控制领域。

    CAN协议也是建立在国际标准组织的开放系统互连模型基础上的。不过,其模型结构只有三层,只取OSI底层的物理层、数据链路层和顶上层的应用层。其信号传输介质为双绞线,通信速率最高可达1Mb/s/40m,直接传输距离最远可达lOkm/kb/s,可挂接设备最多可达110个。

    CAN支持多主方式工作,网络上任何节点均在任意时刻主动向其他节点发送信息,支持点对点、一点对多点和全局广播方式接收/发送数据。

    4)现场总线技术展望与发展趋势

    发展现场总线技术已成为工业自动化领域广为关注的焦点,国际上现场总线的研究、开发,使测控系统冲破了长期封闭系统的禁铜,走上开放发展的征程,这对我国现场总线控制系统的发展是个极好的机会,也是一次严峻的挑战。现场总线技术是控制、计算机、通信技术的交叉与集成,涉及的内容十分广泛,应不失时机地抓好我国现场总线技术与产品的研究与开发。自动化系统的网络化是发展的大趋势,现场总线技术受计算机网络技术的影响是十分深刻的。现在网络技术日新月异,发展十分迅猛,一些具有重大影响的网络新技术必将进一步融合到现场总线技术之中,这些具有发展前景的现场总线技术有智能仪表与网络设备开发的软硬件技术组态抗术,包括网络拓扑结构、网络设备、网段互连等;网络管 理技术,包括网络管 理软件、 网络数据操作与传输;人- 机接口 软件技术;现场总线系统集成技术。

    现场总线属于尚在发展之中的技术,我国在这一技术领域还刚刚起步,了解国际上该项技术的现状与发展动向,对我国相关行业的发展,对自动化技术、设备的更新,无疑具有重要的作用。总体来说,自动化系统与设备将朝着现场总线体系结构的方向前进,这一发展趋势是肯定的。既然是总线,就要向着趋于开放统一的方向发展,成为大家都遵守的标准规范,但由于这一技术所涉及的应用领域十分广泛,几乎覆盖了所有连续、离散工业领域,如过程自动化、制造加工自动化、楼宇自动化、家庭自动化等等。大千世界,众多领域,需求各异,一个现场总线体系下可能不止容纳单一的标准。

    另外,从以上介绍也可以看出,几大技术均具有自己的特点,已在不同应用领域形成了自己的优势。加上商业利益的驱使,它们都各自正在十分激烈的市场竞争中求得发展。有理由认为,在从现在起的未来10年内,可能出现几大总线标准共存,甚至在一个现场总线系统内,几种总线标准的设备通过路由网关互连实现信息共享的局面。现场总线技术的兴起,开辟了工厂底层网络的新天地。它将促进企业网络的快速发展,为企业带来新的效益,因而会得到广泛的应用,并推动自动化相关行业的发展。

    展开全文
  • 以太网作为一种成本低廉、吞吐能力强、适应性好、网络管理能力日益提高...基于LAN新型LXI(LAN eXtensions for Instrumentation)仪器总线正是利用了以太网这些特点,构成了一种适应自动测试系统仪器模块组建标准。
  • NTP 时间同步网络结构特点、安全隐患以及对安全措施迫切需求,对网络内弱电系统主机安全监测平台展开研究,重点论述安全监测平台功能目标、系统架构及工作原理,并结合其具体实现方法及技术特点提出工程实施...

    作者:郑燕燕( 上海轨道交通技术研究中心)

    摘 要: 本文结合轨道交通既有的 NTP 时间同步网络的结构特点、安全隐患以及对安全措施的迫切需求,对网络内弱电系统主机的安全监测平台展开研究,重点论述安全监测平台的功能目标、系统架构及工作原理,并结合其具体实现方法及技术特点提出工程实施方案及相关的应用条件。

    关键词: 轨道交通; NTP; 时间同步; 同步网络; 弱电系统; 安全监测; 基准分析

    1 概述

    在上海轨道交通建设初期,网络内各弱电系统之间的时间信息并不完全一致。当轨道交通由单线建设与运营的模式逐步向网络化发展,因各弱电系统的时间信息不同步而造成对系统设备的运行、维护及管理的不利影响逐渐显现。因此,建立了NTP( Network Time Protocol) 时间同步网络,由统一的时间源平台通过 IP 网络为轨道交通内的各弱电系统提供时间信息,以实现时间的同步和统一管理。但由于时间同步网络采用 IP 架构,也同时引出了网络安全问题。

    为保证网络安全,设计和建设阶段已提出了相关的要求,其中包括对弱电系统主机网卡的端口设置要求。本文论述的"NTP 时间同步网络的弱电系统安全监测平台"主要作用为定期检测上述端口的开放状态及端口流量,并对非正常状态及时报警,以确保网络的安全。

    2 系统组成及主要功能

    监测平台为专用于轨道交通 NTP 时间系统及各弱电系统安全防范的软件系统。它由主机端口检测、网络流量监测和平台管理 3 个系统组成。

    2. 1 主机端口检测系统

    本系统是对现有 NTP 同步网络的端口开放情况进行检测的工具,实现对轨道交通各弱电系统的系统主机是否关闭了除 Port 123 /UDP ( 受时端口)以外的其他端口进行测试的功能。系统功能由监测平台的端口分析模块实现,支持对 IP 或 IP 段内设备( 限 IPv4 地址) 的远程定期在线检测,可检测指定设备上 TCP /UDP 协议的 0 - 65535 端口开放情况,并对开放的非受时端口形成报警数据。

    2. 2 网络流量监测系统

    本系统是对 NTP 时间同步网络中各弱电系统主机的端口流量进行测试的工具。系统由流量收集模块和流量分析模块实现,通过配合交换机的 Sflow 流量采样功能,实现对局域网内除 Port 123 /UDP 外其他端口的异常数据包的发现,并对 Port 123 /UDP 上的非 NTP 协议的数据包进行报警的功能。

    2. 3 平台管理系统

    本系统专用于监测平台的系统管理,提供对主机端口检测系统和网络流量监测系统的参数配置,以及网络流量监测结果信息和主机端口检测结果信息的存储、统计、显示与查询,其功能由前台界面模块与业务分析逻辑实现。

    3 系统架构

    监测平台为专用软件系统( 见图 1) 。

    图 1 监测平台的软件架构

    3. 1 前台部分

    前台部分为使用 Java 语言设计开发的 Web 配置界面,根据其功能可划分成开始测试、基准管理、系统管理及测试报告 4 个模块,分别实现新建测试活动或模拟测试活动并显示测试的进度、报警信息和结果信息的功能; 端口扫描分析及端口流量分析的基准及基准参数配置、管理功能; 系统的配置管理及业务信息管理功能; 显示端口扫描分析及端口流量分析结果的功能。

    3. 2 后台部分

    后台部分是进行端口扫描分析及端口流量分析的具体功能实现部分,使用 C /C + + 语言设计开发,根据其功能可划分成扫描、流量收集及流量分析 3 个模块,分别实现对 TCP /UDP 端口进行扫描并分析扫描结果的功能( 基准分析可选) ; 收集、记录原始 SFlow 流量采样数据包,并识别伪造的 NTP 协议信息及记录报警日志的功能; 结合业务信息对所收集的流量结果进行分析的功能( 基准分析及补充基准分析可选) 。

    3. 3 业务分析逻辑部分

    业务分析逻辑实现前台与后台之间数据交换的中转,业务分析逻辑并不是实际的模块,但是又与实际模块有关联。

    4 工作原理

    4. 1 主机端口检测系统

    4. 1. 1 基本原理

    分析 TCP /IP 网络协议规定的通信建立后网络端口连接的状态,利用 socket 的编程连接方法对目标主机所有 TCP 端口建立连接,发现所有开放的网络通信端口,并将此基础数据记录至数据库中; 对目标主机所有 UDP 端口发送探测数据包,并判断是否返回 ICMP 端口不可达数据包。如果端口关闭,则给源端发送一个 ICMP 端口不可达数据包,如果端口开放,则可不发送该数据包,并将此基础数据记录至数据库中。通过对上述数据进行分析( 基准分析或未使用基准分析) ,以判断对主机端口的开放状态是否符合时间系统的设置要求,实现主机端口检测的目的。

    4. 1. 2 检测方法

    用户将弱电系统的主机信息导入数据库并进行注册,选择使用基准分析或未使用基准分析的验证方法来验证主机端口的开放状态。基准是根据已经完成的测试报告生成的一些参考数据,用户可利用这些数据辅助分析以后的测试结果,以更精确地定位主机异常情况。主机端口检测系统将弱电系统主机的工作情况分为正常、异常 ( 开放不允许开放的端口) 、故障( 主机不在线或未存活) 和未注册( 非法接入的主机) 4 类。

    1) 未使用基准分析。主机端口检测系统根据已注册主机的 IP 地址在数据库中逐一搜索该主机的开放端口,依此做出判断( 见表 1) 。

    表 1 未使用基准分析的验证方法

    2) 使用基准分析。主机端口检测系统根据已注册主机的 IP 地址在数据库中逐一搜索该主机的开放端口,同时检索基准中该主机允许开放的端口。通过对两者进行比对,依此对端口开放状态做出判断( 见表 2) 。

    表 2 使用基准分析的验证方法

    在上述过程中将注册主机的 IP 地址记录下来,再对数据库的主机注册信息进行搜索,以查找出所有非法接入的主机,并形成"未注册"的判断结果。

    4. 2 网络流量监测系统

    4. 2. 1 基本原理

    网络流量监测系统分为流量采集模块与流量分析模块两个部分,配合交换机( 由既有 NTP 时间同步网络配置) SFlow 流量采样功能,获得现有通信网络的流量状况。交换机定时将流量数据包传输给流量采集模块,由该模块根据流量数据包报文的格式和数据分别记录进数据库。流量分析模块将针对数据库内的报文数据进行分析处理。

    4. 2. 2 监测方法

    流量分析通常以五元组( 源地址、目的地址、协议号、源端口和目的端口) 对字节数和报文数进行统计,但对用户而言却不直观。因此,网络流量监测系统引入应用的概念( 如 TCP 协议与 80 端口可以联系到 HTTP 应用) ,在数据库中保存这些对应关系并且编排成号以供检索。流量采集模块将所采集数据的协议号、目的端口与应用进行匹配,识别出应用号作为流量信息的一部分保存在数据库中。当发现 NTP 应用时,则解析 sFlow 流量数据包中被采样到的 NTP 报文的长度及内容,判断 NTP 协议是否被伪造。若发现 NTP 被伪造,则将伪造发生的通信地址记录到数据库的报警信息表中,由网络管理平台实施实时报警。

    与主机端口发现系统类似,网络流量监测系统同样把主机的工作情况分为正常、异常、故障和未注册 4 类,同样支持基准分析方式来提高定位异常情况的能力。

    1) 未使用基准分析。网络流量监测系统根据已注册主机的 IP 地址在数据库中逐一搜索该主机使用的应用号,依此对端口流量做出判断( 见表 3) 。

    表 3 未使用基准分析的验证方法

    2) 使用基准分析。网络流量监测系统根据已注册主机的 IP 地址在数据库中搜索逐一该主机使用的应用号,同时检索基准中该主机允许使用的应用号,通过两者比对判断端口流量的状态( 见表 4)。

    表 4 使用基准分析的验证方法

    如果分析结果为"正常",还可以借助使用访问地址、下限流量、上限流量和单位时间发生次数的辅助流量基准进一步进行补充分析。

    在上述过程中将注册主机的 IP 地址记录下来,再对数据库的主机注册信息进行搜索,以此查找出所有未注册的主机流量信息,并形成"未注册"的判断结果。

    4. 3 管理平台系统

    管理平台的数据交换采用 MySQL 数据库进行,提供主机端口检测系统、网络流量监测系统的管理接口和界面,用于记录、存储弱电系统主机的注册信息、主机端口检测系统与网络流量监测系统的配置信息、扫描及流量采集的原始数据信息,并实现对分析结果的显示、存储、查询与统计。

    5 实施方案

    5. 1 部署方案

    为监测平台分配 IP 地址后接入待测网络,并确保弱电系统主机与交换机连接的物理端口全部纳入采样范围。根据监测平台提供的配置界面完成相应的配置,即可对弱电系统主机的端口进行扫描,并可同时进行流量监测( 见图 2) 。

    图 2 监测平台实施部署示意图(IP 地址为假设)

    5. 2 应用条件

    在监测平台投入测试前,应对其进行多方面的杀毒以确保其自身的安全。同时,其 IP 地址应与被测弱电系统主机所处的网段相同,并与未测试弱电系统主机处于隔离状态。

    6 结 语

    监测平台为轨道交通 NTP 时间同步网络中的各弱电系统提供了必要的安全防范措施,并具备紧密贴合弱电系统的业务逻辑、快速扫描主机端口及精确统计网络流量,以有效定位异常状况的技术特点。监测平台的研究成果已通过"公安部计算机信息系统安全产品质量监督检验中心"的第三方检测,并已申请了软件著作权。需要指出的是,监测平台设计为定期检测而非在线测试系统。因此,对于网络安全防范的实时性仍显不足,需要配合在线运行的专用硬件设备以实现实时解析 NTP 协议并拦截非 NTP 及伪造 NTP 协议的目的。

    参考文献:

    [1] 李兵,陈小鸿. 交通实时信息采集系统中时间同步问题研究[J]. 交通与计算机. 2008,26( 2) : 50 - 52.

    [2] 沈燕芬. 用于网络时间同步的 NTP 协议. 现代计算机[J]. 2004( 4) : 54 - 56.

    [3] 同济大学交通运输工程学院. 深圳市城市交通仿真项目系统检测报告[R]. 上海: 同济大学,2006.

    展开全文
  • 基于OTN同步检测机制实现,鲁传好,,研究了光传送(OTN:Optical Transport Network)主要功能特点,光传送是下一代光网络主流技术。帧同步光传送中数据恢复重要��
  • Microsoft Sync Framework(MSF)是一个全面的同步平台...MSF一个关键性技术特点是可以由开发人员自定义数据源提供器(Provider),可以让任意数据源之间进行点对点的同步。 虽然数据提供器是一种额外提供...
  • 北京恒颐针对勘探、测控等行业的特点,推出了基于ARM+FPGA低功耗、高速率、高精度、多通道同步数据采集方案,可以通过监测者要求完成多通道数据的同步采集并实现实时网络传输。  ◆应用场合  物探分析领域...
  • 任何用户上网过程中面临...为帮助用户获得对安全消息大致了解,下文将分析恶意软件***技术特点: 偷渡式下载: 是不是对这句话比较熟悉,“你要安装并运行XXX签名XXX吗,其发行者为XXX,发行商可靠性...
  • 针对复杂多变煤矿电力系统中供电质量存在问题,指明SVG静止同步无功补偿技术在煤矿供电网络中重要性,并对SVG静止同步无功补偿器工作原理、拓扑结构及技术特点进行分析,对现代化生产矿井安全可靠性供电具有...
  • NTP时间同步

    2019-06-04 15:41:42
    有多种时间同步技术,每一种技术都各有特点,不同技术的时间同步精度也存在较大差异 常用同步技术: 时间同步技术 准确度 覆盖范围 短波授时 1~10毫秒 全球 长波授时 1毫秒 区域 GPS 5~500纳秒 全球 电话拨号授...
  • 目前有多种时间同步技术,每一种技术都各有特点,不同技术的时间同步精度也存在较大差异.常用同步技术时间同步技术 准确度 覆盖范围短波授时 1~10毫秒 全球长波授时 1毫秒 区域GPS 5~500纳秒 全球电话拨号授时 ...
  • 知己知彼 用VLAN技术防御****** 为什么要用VLAN呢?VLAN实施是从逻辑上对用户进行了划分,使... VLAN技术的应用为网络安全防范提供了一种基于管理方式上策略方法,我们可以根据企业网络管理的特点有...
  • IEEE1588精密网络同步协议(PTP)

    千次阅读 2018-04-14 11:32:00
     以太网技术由于其开放性好、价格低廉和使用方便等特点,已经广泛应用于电信级别网络中,以太网数据传输速度也从早期10M提高到100M,GE,10GE。40GE,100GE正式产品也于2009年推出。  以太网技术是“即插即...
  •  TD-SCDMA与另外两种第三代移动通信标准相比有四大技术特点:双向智能天线技术、反向链路同步技术、反向联合检测技术、动态信道分配技术,其中双向智能天线技术得益于它收发同频。除四大技术特点外,TD-SCDMA还有...
  • 阐述了ASON控制平面与传统传送网的本质区别、管理平面智能化管理特点所带来的3种优点,以及传送平面中光交叉连接(OXC)的6种主要交换结构、发展方向和存在的主要问题;最后综述了新一代基于数字同步系列(SDH)提供多种...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 417
精华内容 166
关键字:

同步网的技术特点