CN111669444B - 基于边缘计算的云游戏服务质量增强方法及*** - Google Patents
基于边缘计算的云游戏服务质量增强方法及*** Download PDFInfo
- Publication number
- CN111669444B CN111669444B CN202010511256.4A CN202010511256A CN111669444B CN 111669444 B CN111669444 B CN 111669444B CN 202010511256 A CN202010511256 A CN 202010511256A CN 111669444 B CN111669444 B CN 111669444B
- Authority
- CN
- China
- Prior art keywords
- cluster
- game
- server
- edge
- player
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 32
- 238000004364 calculation method Methods 0.000 title claims description 6
- 238000004422 calculation algorithm Methods 0.000 claims abstract description 76
- 230000004044 response Effects 0.000 claims abstract description 41
- 238000012360 testing method Methods 0.000 claims description 16
- 238000012545 processing Methods 0.000 claims description 10
- 230000008569 process Effects 0.000 claims description 7
- 230000000694 effects Effects 0.000 claims description 6
- 238000000638 solvent extraction Methods 0.000 claims description 6
- 238000009826 distribution Methods 0.000 claims description 4
- 238000005304 joining Methods 0.000 claims description 4
- YHXISWVBGDMDLQ-UHFFFAOYSA-N moclobemide Chemical compound C1=CC(Cl)=CC=C1C(=O)NCCN1CCOCC1 YHXISWVBGDMDLQ-UHFFFAOYSA-N 0.000 claims description 4
- 230000001932 seasonal effect Effects 0.000 claims description 4
- 230000001174 ascending effect Effects 0.000 claims description 3
- 238000005192 partition Methods 0.000 claims 1
- 230000003993 interaction Effects 0.000 abstract description 18
- 238000009877 rendering Methods 0.000 abstract description 13
- 230000008859 change Effects 0.000 abstract description 6
- 230000000737 periodic effect Effects 0.000 abstract description 3
- 238000004891 communication Methods 0.000 description 9
- 238000010586 diagram Methods 0.000 description 8
- 230000001934 delay Effects 0.000 description 7
- 230000001965 increasing effect Effects 0.000 description 7
- 239000011159 matrix material Substances 0.000 description 7
- 230000007246 mechanism Effects 0.000 description 7
- 230000005540 biological transmission Effects 0.000 description 6
- 238000011160 research Methods 0.000 description 6
- 238000004458 analytical method Methods 0.000 description 4
- 238000013459 approach Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 238000004088 simulation Methods 0.000 description 4
- 238000002474 experimental method Methods 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 238000003860 storage Methods 0.000 description 2
- 239000002699 waste material Substances 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000006837 decompression Effects 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000011835 investigation Methods 0.000 description 1
- 230000000116 mitigating effect Effects 0.000 description 1
- 238000011056 performance test Methods 0.000 description 1
- 230000035755 proliferation Effects 0.000 description 1
- 230000010076 replication Effects 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 238000011144 upstream manufacturing Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
- 238000012800 visualization Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1029—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers using data related to the state of servers by a load balancer
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
- A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
- A63F13/35—Details of game servers
- A63F13/352—Details of game servers involving special game server arrangements, e.g. regional servers connected to a national server or a plurality of servers managing partitions of the game world
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/101—Server selection for load balancing based on network conditions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1023—Server selection for load balancing based on a hash applied to IP addresses or costs
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1031—Controlling of the operation of servers by a load balancer, e.g. adding or removing servers that serve requests
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/131—Protocols for games, networked simulations or virtual reality
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Information Transfer Between Computers (AREA)
Abstract
一种基于边缘计算的云游戏服务质量增强方法及***,使用边缘服务器为玩家渲染游戏,云端只需负责计算游戏状态和发送更新信息给边缘服务器。考虑到各区域游戏的负载不同,提出区域划分算法来确定集群的部署位置,使负载均衡。考虑到各游戏自身要求不同,提出集群选择算法为玩家选择集群,使所选的集群即满足游戏要求且不浪费资源。考虑到玩家之间大量的交互,提出服务器分配算法把好友关系的玩家分配到同一台服务器上,进一步减少由于交互所产生的延迟。考虑到游戏动态的周期性变化,提出服务器动态部署策略来动态开启服务器,进一步提高服务器的可靠性并节约成本。本技术方案能够减少响应延迟、节约带宽消耗和提高用户覆盖率。
Description
技术领域
本技术方案属于计算机技术领域,具体是一种基于边缘计算的云游戏服务质量增强方法及***。
背景技术
云游戏是一种蓬勃发展的游戏模式,改变了传统游戏的集中式客户机和服务器的基础设施;它将玩家从高端的硬件配置和繁琐的游戏安装的中解放出来,玩家只需一台可以上网的电脑即可,而无需3D游戏所需的高端显卡、大存储内存、高配置CPU以获得好的游戏体验。在云游戏中,游戏存储和运行在远程服务器上,并实时将渲染好的游戏画面通过网络传输给玩家,因此玩家的客户端只需要基本的视频解压能力[1]。游戏运营商可以根据***需求购买服务(云资源)从而节省成本;此外,游戏运营商不必开发同一游戏的多个版本,以满足不同的操作***,也不必在防软件盗版上花钱。
云游戏在快速发展的同时也面临严峻的挑战。第一,玩家能够接受的响应延迟是100毫秒(其中客户端播放延迟和云端处理延迟共20毫秒,网络传输延迟80毫秒)。若将渲染模块卸载到远程主机上运行,由于增加了在云端与终端之间距离,较长的传输延迟会产生。第二,相比较而言,云游戏要求高速网络带宽(OnLive达到5Mbit/s)。第三,依赖单一服务中心限制了服务范围的扩展。传统基于云计算的集中式游戏服务提供模式无法解决低延迟、高带宽和广服务范围等这些问题。
对云游戏玩家来说,游戏服务质量的关键指标之一是响应延迟。现有技术的研究结果表明玩家对上行的响应实时性要求较低,但对下行的实时性要求较高,且下行速率受游戏视频流速率的影响;所以可以通过减少从云端传输的流量来减少下行延迟。边缘计算的出现为我们解决传统云游戏模式所面临的问题提供了思路。直觉上,边缘计算技术拉近了服务器与终端之间的距离,有助于减少网络传输延迟。然而,在云游戏中使用边缘计算技术又面临很多新的问题,例如,边缘服务器集群安置在边缘何处,一处安置多少台边缘服务器,安置太多浪费资源,安置太少既缓解不了计算压力,又会影响游戏渲染性能;玩家由哪个集群来服务需要做出选择,若选择不当,有可能导致集群负载不均衡,不能满足游戏的响应延迟等问题;在同一集群中如何合理地分配服务器,既能减少交互延迟,又能最大化利用资源。
传统云游戏***的发展分为三类:(一)3D图形流,(二)视频流和(三)渲染流。这三种方法在如何划分云服务器和客户机之间的工作负载方面各不相同。
使用3D图形流方法,云服务器截取图形命令,压缩命令,并将它们发送到客户机上,然后客户机渲染游戏场景,利用其基于图形指令集的图形显卡,如OpenGL和Direct3D。客户端的图形显卡不仅要与服务器发送过来的图形命令相兼容,而且要足够强大,能够实时、高质量地渲染游戏场景。3D图形流方法不使用云服务器上的图形显卡,所以每个云服务器可以同时支持多个客户端。然而,由于这种方法在客户机上渲染游戏画面,强加了客户机更多的工作负载,所以它不太适合资源受限的客户端设备,比如移动设备和机顶盒。
与此相反,随着视频流方法的发展,云服务器将3D图形渲染为2D视频,然后压缩视频,并将它们发送给客户机,客户机解码并播放显示视频流。解码可以使用低成本的视频解码器。这种方法可以减轻客户机密集计算3D图形的渲染绘制。渲染流方法介于3D图形流和视频流之间。而渲染后的视频流方法的渲染工作在云服务器上执行,后续的解码、纹理和照明等操作在瘦客户机上运动。这些渲染后的操作具有较低的计算复杂度且可以实时运行,不需要GPU。
现有技术中,通用瘦客户机***的性能探讨,对不同瘦客户机的性能进行了研究,包括VNC(虚拟网络计算)。研究者量化VNC服务器上运行多个应用程序时的性能,通过网络连接到一个具有不同往返时间(RTT)的VNC客户端。这些应用程序的响应延迟高度取决于应用程序的交互量和网络RTT的程度。然而都是为通用瘦客户机设计的,不适用于有严格时间限制的云游戏***。
如何提高瘦客户机游戏的性能一直是研究的热点。一些研究者在通用瘦客户机的游戏性能方面的研究,已成为评估多种流行瘦客户机的标准;还提出了玩家的体验质量(QoE)取决于视频质量和帧速率。据调查,通用瘦客户机不能支持云游戏,因为所获得的帧速率低于9.7fps。另一些研究者提出了另一种量化响应延迟的方法,这对云游戏更为关键。另外,还有研究者评估了传统网络游戏是否同样适用于云游戏环境,并发现一些游戏更适合云游戏。同时,一些研究者评估当前互联网上的大规模云游戏基础设施是否可行,并提出一种智能边缘解决方案来缓解在云上游戏时用户感知的延迟。
上述方案都没有有效解决云游戏的响应延迟问题。这驱使本方案提出一种基于边缘计算技术的云游戏服务质量增强机制。
发明内容
针对上述问题,本发明提出:
一种基于边缘计算的服务质量增强的云游戏***,包括云端服务中心和终端,还包括边缘服务器集群;
在部署边缘服务器之前,云端服务中心需要执行集群区域划分算法来确定边缘服务器集群的位置和服务器范围,该算法根据每个区域的负载进行划分(云游戏集群区域);
在集群区域划分好之后,当一个新玩家请求加入游戏时,云端服务中心执行集群选择算法根据玩家游戏的延迟要求和资源要求来为该玩家选择最适当的边缘服务器集群,让玩家加入;
在集群选好之后,再执行服务器选择算法根据该集群中玩家的社交网络关系来进行选择服务器加入;
若边缘服务器集群中的服务器数量不够或者过剩时候,执行服务器动态部署策略来动态的调节服务器的开启数量;服务器动态部署策略为:
本***中,所述云端服务中心分发玩家在游戏过程中的操作、控制信息;所述集群负责更新游戏状态和渲染游戏视频,然后发送给对应的玩家;终端接收边缘服务器发送过来的视频数据,然后解码播放。
一种基于边缘计算的云游戏服务质量增强方法,本方法为:将服务器安置在边缘,靠近终端,构成边缘服务器集群(拉近了与终端的距离,从而可以减小响应延迟);使用边缘服务器来负责渲染游戏视频并传输给这些边缘服务器附近的终端(即玩家)(从而可以减少传输量,节约网络带宽;并且由于服务器安置在边缘,所以在云端没有覆盖到的用户可以获得附近的边缘服务器的支持,从而扩大云游戏的服务器范围;因此,云游戏传统部署方法所面临的问题将迎刃而解。)步骤包括:
1)在部署边缘服务器之前,云端服务中心需要执行集群区域划分算法来确定边缘服务器集群的位置和服务器范围,该算法根据每个区域的负载进行划分(云游戏集群区域);
2)在集群区域划分好之后,当一个新玩家请求加入游戏时,云端服务中心执行集群选择算法根据玩家游戏的延迟要求和资源要求来为该玩家选择最适当的边缘服务器集群,让玩家加入;
3)在集群选好之后,再执行服务器选择算法根据该集群中玩家的社交网络关系来进行选择服务器加入;
步骤4)若边缘服务器集群中的服务器数量不够或者过剩时候,执行服务器动态部署策略来动态的调节服务器的开启数量。
本方法中,所述云端服务中心负责分发玩家在游戏过程中的操作、控制信息;集群负责更新游戏状态和渲染游戏视频,然后发送给对应的玩家;终端负责接收边缘服务器发送过来的视频数据,然后解码播放即可。
本发明在设计云游戏增强方案时,考虑了采用边缘计算技术所面临的新问题,考虑到各区域游戏的负载不同,提出区域划分算法来确定集群的部署位置,目的是达到负载均衡。考虑到各游戏自身要求不同,提出集群选择算法为玩家选择集群,目的是达到所选的集群即满足游戏要求且不浪费资源。考虑到玩家之间大量的交互,提出服务器分配算法把好友关系的玩家分配到同一台服务器上,目的是进一步减少由于交互所产生的延迟。考虑到游戏动态的周期性变化,提出服务器动态部署策略来动态开启服务器,目的是进一步提高服务器的可靠性并节约成本。
通过PeerSim模拟器模拟边缘计算环境,实验结果表明总延迟可减少18~20毫秒,提高了游戏的总体性能。
附图说明
图1为基于边缘计算的云游戏基本框架图;
图2为架构模块及交互流程示意图;
图3为基于无向图的算法过程可视化示意图;
图4为基于社交网络的服务器分配图;
图5为集群社区划分示意图;
图6为周期划分关系示意图;
图7为网络带宽比较示意图;
图8为响应延迟比较示意图;
图9为服务器部署策略分析示意图;
图10为游戏需求对集群数量的影响示意图;
图11为覆盖率与集群数、延迟的关系图;
图12为服务器分配算法分析示意图。
具体实施方式
下面结合具体实施方式以及附图对本发明创造进一步说明:
本发明的基于边缘计算的云游戏服务质量增强方法及***,使用边缘服务器为玩家渲染游戏,云端只需负责计算游戏状态和发送更新信息给边缘服务器。考虑到各区域游戏的负载不同,提出区域划分算法来确定集群的部署位置,使负载均衡。考虑到各游戏自身要求不同,提出集群选择算法为玩家选择集群,使所选的集群即满足游戏要求且不浪费资源。考虑到玩家之间大量的交互,提出服务器分配算法把好友关系的玩家分配到同一台服务器上,进一步减少由于交互所产生的延迟。考虑到游戏动态的周期性变化,提出服务器动态部署策略来动态开启服务器,进一步提高服务器的可靠性并节约成本。本技术方案能够减少响应延迟、节约带宽消耗和提高用户覆盖率。
具体来说:
1体系结构
1.1总体框架
图1给出了基本框架,包括云端服务中心、边缘服务器集群和终端。在部署边缘服务器之前,云端服务中心需要执行集群区域划分算法(见2.1节)来确定集群的位置和服务器范围,该算法根据每个区域的负载进行划分,图1中被划分成了三个云游戏集群区域;在集群区域划分好之后,当一个新玩家请求加入游戏时,云端服务中心执行集群选择算法(见2.2节)根据玩家游戏的延迟要求和资源要求来为该玩家选择最适当的集群,让玩家加入;在集群选好之后,再执行服务器选择算法(见2.3节)根据该集群中玩家的社交网络关系来进行选择服务器加入;若集群中的服务器数量不够,或者过剩,即当游戏高峰期时,需要更多的服务器,在低谷期时,需要的服务器比较少,针对这些情况,我们设计了服务器动态部署策略(见2.4节)来动态的调节服务器的开启数量。云端服务中心还负责分发玩家在游戏过程中的操作、控制信息等。集群主要负责更新游戏状态和渲染游戏视频,然后发送给对应的玩家;终端负责接收边缘服务器发送过来的视频数据,然后解码播放即可。
1.2***模型
如图2所示,用pi表示序号为i的玩家,用meci表示序号为i的服务器集群。当玩家发送请求游戏信息时,该机制先通过集群选择算法来给玩家选择一个距离最近、有足够资源且满足游戏延迟要求的集群,确保能够提供满意的游戏视频服务;当为玩家pi选出最佳的集群meci之后,为了最小化集群中服务器之间的交互,集群执行基于社交的服务器选择算法把pi与他的好友分配到同一台服务器上,因为游戏好友总是一起游戏[7],所以他们在游戏中进行密集地互动时就不会触发不同服务器之间的通信,从而减少由于服务器之间的通信而导致的延迟。玩家在游戏过程中的操作、控制信息都先交由云端控制中心处理,然后再发送给相应的边缘服务器集群。最后,为了适应大型多人在线游戏的高峰期和低谷期的人数变化,通过服务器动态部署策略来动态的、周期性的调节服务器的数量,在高峰期时,开启更多的服务器来支持在线玩家,在低谷期时,关闭空闲的服务器,这样便于集中管理,且节约资源,最小化成本。
每一个边缘服务器最初部署时,需要预先安装配置好游戏。在游戏中,当玩家pi发出动作或操作,如:发起游戏战役或移动到一个新的地方,这些信息被发送到云端控制中心。云端收集***中所有参与该游戏的玩家的动作信息,并对游戏状态进行计算,包括对象的新形状和位置;然后云端发送更新信息给边缘服务器meci,更新其相应的游戏画面;然后meci根据玩家pi的观看位置和角度为其渲染游戏视频,对游戏视频进行编码并发送给玩家pi。因为一个玩家在网络距离上更接近边缘服务器,并且来自云端的流量明显减少,所以,游戏的视频传输延迟比直接从云端传输要短得多。
2***实现
2.1集群区域的划分
(集群区域划分算法)
目前有很多区域划分算法被提出。现有技术在复杂网络中的社区发现算法,提出一种能够探测到层次化社团结构的凝聚算法BGLL,但是该算法不能选出最具有合并倾向的节点。另一些算法没有考虑游戏本身的特点,有些区域游戏比较密集,不能简单的根据网络拓扑结构划分,因此不能直接应用于游戏玩家区域划分。
考虑到集群资源的有限性与游戏本身的特点,划分的目标是为了达到负载均衡。
针对上述问题,本发明在设计集群区域划分策略时,基于如下准则:首先,在区域合并时,参考集群负载,合并之后的集群负载必须低于集群自身的处理能力,且只能合并相邻的区域;其次,每次迭代只合并两个节点;最后,不能无限制地合并区域,因为要考虑到集群自身的处理能力。
这里通过图3来说明划分细节。把一个区域随机分成9个子区域,每个子区域代表一个集群,该区域的范围就是该集群的服务范围;然后用边ei,j的权重wi,j∈R表示节点i和节点j之间的负载。自环的边ei,i表示集群内部自身的负载。算法迭代执行两个阶段。
第一阶段:首先遍历边集E中的所有边,选出权重最大的边ei,j,且满足节点i和节点j在地理位置上是相邻的,如:区域1与区域2、4是相邻的,与其他区域就不是相邻的。还要满足集群i和集群j中的负载量小于等于集群的处理能力最大值C,即:wi,i+wi,j+wj,i+wj,j≤C。
第二阶段:对节点i和节点j进行合并,合并后用一个新节点k来表示。节点k的邻居是节点i和节点j之前的邻居,节点k与其邻居之间的权重等于节点i与其邻居之间的权重加上节点j与其邻居之间的权重。
最后,新的自环的权重等于前两个自环的权重加上节点i和j之间的权重。一旦第二阶段完成,就把新生成的图作为输入重新执行算法的第一阶段;这样一直迭代下去,直到图中的节点无法满足要求为止。
通过不断地构造图,每一步节点数都在减少,直到无法合并为止,这也意味着达到了集群相互交互量的局部极小值。算法的最终结果给出了该区域划分的集群数量和每个集群的服务范围,即集群应该部署的位置。算法的第一阶段是从图3的所有边中找出最大权重的非自环边。第二阶段包括在图中添加和移除节点;当没有一对节点可以合并时,算法结束。因此算法的时间复杂度是O(|E|·|N|),其中|E|是边数,|N|是顶点数。
2.2服务器集群选择
(集群选择算法)
在集群区域划分好之后,便在各区域里部署相应的服务器,形成服务器集群。当玩家请求游戏时,为了给玩家选择最优的集群,即所选的集群即满足游戏要求且不浪费资源,本节提出集群选择算法。
玩家服务质量易受两个因素影响:其一是集群自身有限的能力不能满足游戏服务质量的要求,所以要为玩家选择有足够剩余能力的集群来服务;其二是由于不同的边缘服务器集群到同一个玩家有不同的物理距离和传输延迟,所以要选择满足游戏要求且延迟较小的集群来服务该玩家。
根据这两个因素,定义某一个集群中服务器剩余的最大GPU容量为Gmax,最大CPU容量为Cmax;然后在云端服务中心存储一个集群列表group_list,记录这些信息及其集群序号ID和IP地址。最后还需维护一张游戏列表game_list,用于描述game_list[i]这款游戏运行时所需要的GPU资源GPUneed、CPU资源CPUneed和其最大响应延迟容忍度Lmax等信息。
当玩家pi登录云游戏官网,在首页展示所有的游戏列表;当玩家点击喜欢的游戏之后,将向云端服务中心请求该游戏并提交游戏所需的资源GPUneed、GPUneed和Ltest;Ltest是响应延迟容忍度的测试值,然后云端首先根据玩家所请求的资源在group_list中查找能够满足条件的集群,即满足如公式1所示的最优化条件,使所有游戏列表中的GPU资源和CPU资源最小,并且要满足这些游戏的需求。
云端返回一定数量的、有足够能力的边缘服务器集群列表;再使用集群的IP地址和玩家的IP地址来计算每个集群到玩家的物理距离,然后根据物理距离选出较小的Num个待选服务器集群;物理上靠近玩家的集群也可能无法保证短的响应延迟,并且现阶段游戏的种类繁多,并不是所有游戏的响应延迟要求都类似,因此,新加入的玩家pi从云端接收到其集群候选列表后,对他们进行测试,然后对比测试所得的延迟与游戏本身的延迟要求;移除响应时延大于游戏本身延迟要求的候选服务器集群;这是用来确保服务器能够提供快速的数据流服务。
为了选择高质量的边缘服务器,将候选集群按照他们的响应延迟升序排序。在玩家pi选择服务器集群的过程中,同时该集群可能接入了其他玩家而导致不再有足够的剩余容量;为了再次确保所选集群有可用容量,玩家按照排序列表依次询问待选集群是否有可用容量,一旦有集群满足要求,玩家就选择该集群连接加入,然后调用服务器选择算法在该集群中选择恰当的服务器;如果没有满足要求的集群,云端就向响应延迟最小的集群请求执行服务器动态部署策略,开启一个新服务器进行分配。
通常情况下,商业GPU都基于驱动程序或硬件计数器来提供运行时的性能信息。例如,使用英伟达提供的PerfKit性能测试工具,可以实时地收集GPU资源消耗的信息,包括GPU空闲或忙碌时的百分比、GPU的内存消耗等。同样对于商用CPU,英特尔处理器已经提供监控性能事件的能力,可以获得CPU的利用率、周期等信息。因此,可以实时的获取更新每个集群中服务器的Gmax和Cmax的值。下面给出集群选择算法的核心部分:
2.3集群服务器分配
(服务器选择算法)
在为玩家选好集群之后,那么接下来便是在该集群中选择某台服务器。
边缘服务器集群由多台服务器组成,协同完成计算和存储功能。在线网络游戏涉及到玩家的密集互动,对服务器分配。提出了较高的要求。即:当多个玩家分配到不同的服务器时,如果在游戏中交互,他们的服务器之间就需要互相通信,就会产生延迟,容易导致总延迟增加且服务器资源浪费。如图4所示,当玩家pi和玩家pj一起游戏时,会导致服务器A和B之间的交互,这样服务器之间的通信将增加响应延迟并降低服务质量;如果pi与pk一起游戏,它们之间的交互不会导致服务器之间的交互。
针对上述问题,本节提出基于社交的服务器分配算法,通过把一起游戏的玩家分配到同一服务器上来减少服务器之间的交互,并且当好友一起游戏时,他们的游戏时长基本上都是一样的,这样把他们分配在同一台服务器上,当游戏结束时,可以直接关闭这台服务器,节约资源,便于管理。当新玩家进入边缘服务器集群时,如果他与其他玩家是好友关系,就把这个新玩家分配给其大部分好友所在的服务器,否则将随机分配一个服务器。为了提高好友聚类的准确性和减少服务器之间的交互,将周期性地执行该算法来调整玩家的服务器。
在集群中的玩家用一个无向图G=(V,E)来表示;V是玩家的点集,E是玩家之间关系的边集。eij=1表示玩家pi和玩家pj是好友关系。使用一个集合F(i)存储pi的所有好友。文献[7]的研究表明,在网络游戏中,玩家更喜欢相互添加好友,更倾向于和他们的好友一起玩游戏,这里所指的好友都是玩家在游戏中建立的好友。因此,假设某个边缘服务器集群中有n个服务器,我们要做的工作就是把这个集群中的所有玩家分成n个网络社区,然后分配在不同的服务器上。如图5所示,每个节点代表一个玩家,节点之间有边就说明这两个玩家是好友关系,最优化的目的是尽可能使社区之间的边数最少,也就达到了使服务器之间的通信最少。
为了衡量社区划分的好坏,本节使用模块化参数H来评估合成的网络社区的质量[14]。首先定义一个n×n的对称矩阵Q,其元素qij的值是连接社区i和j的边数与总边数的比例,然后计算H为:
把公式4带入公式3可得:
H=tre(Q)-||Q2|| (5)
其中||Q||是矩阵Q中所有元素之和,即矩阵的范数。H的值越高说明这个社区分的越好,也就是游戏好友分配到了相同的服务器。现有的研究通常使用复制的方法将用户及其好友划分到同一服务器[15],也就是说,用户的数据被复制到多个服务器上。这些方法不适用于每个玩家数据只有一个副本的游戏服务器,并且每个玩家的数据被保存在多个服务器上,那么玩家数据的同步将会带来很大的开销。本节提出的基于社交的服务器分配算法避免了这些问题,该算法采用贪心的思想首先将一个玩家及其好友分配到同一个社区,然后为了优化社区的结构,即增加H的值,不断地选择一些玩家并交换他们的社区。通过设置不同的交换次数,可以控制社区集群的计算开销;下面给出详细的算法步骤:
2.4服务器动态部署
(服务器动态部署策略)
在大型网络游戏中,在线玩家的数量通常按照每日模式周期性变化。当大量玩家在高峰期短时间内加入游戏时,玩家数量的激增会给云端服务器带来沉重的负担;使用边缘服务器可以在高峰期最小化云端服务器的开销,但是同样边缘服务器也会面临高峰期时沉重的处理压力,甚至会出现超载宕机的情况。针对这些问题,本节提出的服务器动态部署策略在考虑到玩家数量的动态变化时,部署相应数量的边缘服务器来帮助云端处理数据和传输游戏视频流,从而减轻云端服务器的负担,并且也能保证边缘服务器不会超载。实验证明这是一种处理玩家动态变化问题的行之有效的方法。
该策略在高峰期之前预先部署了足够多的边缘服务器来支持玩家,在高峰期之后再关闭空闲的服务器。这些新部署的服务器服务刚刚到达的玩家,从而减轻了对云端的峰值带宽需求。该策略面临的一个挑战是如何确定预先部署边缘服务器的数量。如果部署过多的服务器,其中一些可能是一直闲置的;如果部署的数量不足,那么边缘服务器就会出现超载的情况,这会严重影响云游戏的服务质量。
需要部署多少台服务器跟玩家的数量有关,在线玩家的数量越多,则就需要更多的服务器;我们先预测玩家的数量,然后基于玩家的数量来确定预先部署边缘服务器的数量。现有技术中,大型多人在线游戏的负载每周都有固定的模式,周与周之间的负载变化不到10%;例如,这周五的在线玩家的趋势可以反映出下周五的玩家数量;因此,根据前几周的数据来预测当前周的在线玩家的数量,然后提前部署足够的边缘服务器。这种预测过程以一种m小时的时间周期进行,把每个星期都划分为7*24/m=T个时间窗口。用Gi表示在时间窗口i内的玩家的预测数量,Gi根据上周同一时间的在线玩家数量预测到,其中i∈T。本方案使用季节性的ARIMA模型来预测玩家的数量。
如图6所示,比如说要预测本周的i时间窗口的玩家人数Gi,需要基于本周的i-1时间窗口的玩家数据Gi-1(也称为当前时间窗口)、上周的同一时间窗口的数据Gt-T和前一个时间窗口的在线人数Gt-T-1,即:
Gi=Gi-1+Gi-T-Gi-T-1-θωi-1-θωi-T-θλωi-T-1 (6)
其中θ是移动平均系数,λ是季度移动平均线的系数。ωi~N(0,σ2)为服从均值为0、方差为σ2分布的白噪声序列。为了能够支持Gi数量的玩家,所需的边缘服务器的数量Gsi为:
Gsi=(1+δ)*Gi/Cavg (7)
其中Cavg为服务器的平均服务能力,δ为服务器数量的比例因子。
有些时间序列数据会表现出一定的周期性。在本文中,一个周期代表一天的游戏活动;每个周期又分为24个子周期。
为了服务更多的玩家和最大化利用服务器的能力,选择当前区域内,那些服务大量玩家的服务器开启;因为每个区域玩家的密度都是稳定的,一个支持大量玩家的服务器在未来服务更多玩家的可能性更大。使用Gi′记录服务器在前一个时间段中所服务的玩家数量,根据Gi′降序排列所有的候选服务器,选择前Gsi个即可。最后,预先部署的边缘服务器有足够的能力来处理其所在区域的请求激增。
3性能分析与评价
使用PeerSim模拟器来搭建仿真实验环境,方案A表示使用边缘服务器集群的布局方式和集群选择算法,方案B表示采用所提出的布局方式和所有算法。在测试布局方式和集群选择算法时,与GamingAnywhere[1]进行对比,GamingAnywhere是基于一个数据中心的布局方式。在测试服务器分配算法和服务器动态部署策略时,主要通过与不运行该算法或策略时对比,然后分析他们的平均响应延迟。
实验分为28个周期,一个周期代表一天的游戏活动;每个周期又分为24个子周期。假设8pm-12am(即子周期20到24)为高峰期,即大量玩家都在线。现有技术的研究中,随机选择50%的节点在子周期(0,2]中随机游戏一段时间,30%的节点在子周期(2,5]中随机游戏一段时间,剩下的20%的节点在子周期(5,24]中。在一个周期中,每个玩家的游戏开始时间以30%的概率从子周期[1,19]中随机选取,以70%的概率从子周期[20,24]中随机抽取。记录每个子周期段的在线玩家数量和使用这些数据来预测在线玩家数量。
仿真实验默认有1个云端服务中心、5个边缘服务器集群,每个集群中有5个服务器,每个服务器设置为八线程,主频3.6GHz,16GB RAM;显卡设置核心频率为800MHz,显存1024M。由统计数据来设置仿真中下载带宽的分布,为了模拟真实的网络连接,节点的上行带宽容量被设置为其下行带宽的1/3[23,24]。设置在线和离线玩家共10000名,每名玩家的朋友数服从倾斜系数为0.5的幂律分布。为了模拟玩家的动态的增长,玩家加入***服从期望为5的泊松分布,即平均每秒5名玩家加入。每名玩家在游戏结束后离开***,并加入到下一个实验周期的***中。游戏的延迟要求如表1所示。游戏视频的帧速率设置为30fps,因为30fps的帧速率是满足游戏服务质量的最低标准。玩家与服务器之间的通信延迟是从ping英雄联盟服务器的延迟中根据频率随机选择的。
表1用于测试的游戏需求
3.1玩家人数的变化对机制性能的影响
实验主要从响应延迟、带宽消耗和用户覆盖率三个方面进行分析。一般游戏的响应时间要求是100毫秒,如果响应延迟不超过用户游戏的延迟要求,就说明用户可以被覆盖,定义用户覆盖率为覆盖到的玩家数量与***中所有玩家数量的比值。
为了比较带宽消耗,我们从云端测量不同游戏的带宽消耗。图7对比了玩家数量与带宽消耗的关系,从中可以看出,GamingAnywhere的带宽消耗大于方案A;这是因为方案A的服务器更靠近玩家,所以传输游戏视频给玩家带宽消耗更少,可以节省大量的带宽资源。云端只需要发送更新信息给集群,而不是整个游戏视频。
图8展示每个玩家的平均响应时间。从中可以看出,方案A的响应时间比GamingAnywhere略有减少,这表明边缘集群的布局方案有助于减少响应延迟。在方案A中,用户链接到位置上接近他们的边缘服务器,然后游戏的视频流是从边缘服务器传输到用户,而不是从远处的数据中心服务器;因此,方案A能够减少用户的响应延迟。
经过分析可知,使用边缘计算的集群部署方案能够有效提高用户覆盖范围,且满足游戏响应延迟要求;节约带宽消耗,减轻网络负载;减少响应延迟,提高服务质量。
为了测试服务器动态部署策略的性能,我们为高峰期和非高峰期手动设置了不同的玩家到达率,主要测试用户在申请加入游戏的等待时间。在仿真实验中,设置移动平均系数θ=0.5,m=4,设置非高峰期(子周期1-19)的玩家平均到达率为每分钟5人,在高峰期时(子周期20-24)从初始值每分钟10名玩家开始,以每一个子周期增加10名玩家的速率递增,直到每分钟60名玩家。测试时使用一个集群,设置该集群中有400台服务器,然后对比在使用该策略和不使用该策略情况下的性能,如图9所示,不使用该策略时,等待时间平均增加了135秒;这是因为在高峰期短时间内,有大量玩家加入时,由于集群中已开启的服务器资源不够用,新加入的玩家向服务中心申请开启新的服务器;因为没有使用动态部署策略,所以没有提前开启部署好足够的服务器,因此新到达的玩家就需要等待服务器部署好之后才能加入游戏。在用户到达率为40时,等待时间出现突然增加现象,这是因为此时集群中虽然有空闲资源,但是不能满足该游戏,只能申请开启一台新服务器,所有需要额外的等待时间。
实验结果表明,该策略能有效地应付高峰期时用户激增情况,并且减轻集群的负载,防止出现服务器宕机等。
3.2玩家需求的变化对机制性能的影响
本小节我们将从游戏本身的需求进行分析,首先分析在玩家数量固定的情况下,游戏自身的响应延迟对集群数量的影响,测试多组数据,然后绘制图10。分析图10中所采集的实验数据,可知针对不同的游戏,有不同的响应延迟要求,响应延迟越大,说明可以连接到的更远处的集群,因此所需的集群数量就越少。从图10中可以看出在游戏延迟为50毫秒时,集群数量的范围波动比较大,这是因为这一批的玩家测试数据中的好友关系比较少,所以大部分都分配在了不同的服务器上,没有对好友关系的玩家进行整合;因此导致集群数量波动不稳定。
3.3集群资源的变化对机制性能的影响
图11显示玩家覆盖率与集群数量、网络延迟之间的关系,从中可以看出,集群数量越多,用户覆盖率就越高,这是因为用户更倾向于连接到近的集群,使原本无法连接的边缘用户,现在可以连接了,从而提高了覆盖率。在一定集群数量时,延迟要求越严格导致用户覆盖率越低,这是因为原本可以玩高延迟游戏的玩家,现在玩低延迟要求的游戏可能不能满足服务质量要求,所以该用户没有被覆盖,导致覆盖率变低。当网络延迟的要求是90毫秒时,部署10个集群的覆盖率比部署5个集群的覆盖率增加约10%,再继续增加集群数量,可以看出覆盖率的增加是非常小的,观察其他延迟要求的情况,发现具有类似的情况;可以得出当集群的数量达到某个阈值时,通过部署更多的集群来提高用户覆盖率的效果变得很差。
如图12所示,对比了在使用该算法和不使用该算法情况下的平均总延时,可以看出在不使用服务器分配算法时,玩家被随机分配到集群中的服务器,由于服务器之间需要通信,所以通信延迟远远大于运行该算法时的延迟。总延时包括服务器之间的通信延迟和其他延迟。还可以发现,使用该算法可以使服务器延迟减少大约20毫秒,从而降低了整体的响应延迟;这是因为使用该算法可以使游戏中频繁交互的用户被分配到集群中同一服务器上,因此他们之间的交互不太可能涉及到服务器之间的通信,从而减少了延迟。从图8中得出运行该算法的方案B比方案A的响应延迟短,可以看出该算法在整体框架中的有效性。
4结束语
本发明提出的一种使用边缘计算来提高云游戏服务质量的机制,其主要目的是减少响应延迟,提高云游戏的服务范围和质量,并针对边缘化之后面临的新问题,给出有效的解决方法。使边缘区域的玩家可接入附近的服务器,减少网络带宽消耗。并在此基础上提出集群区域划分算法、服务器集群选择算法、服务器分配算法和服务器动态部署策略。实验结果表明,该机制能够减少响应延迟,提高用户覆盖率和云游戏的服务质量。
Claims (3)
1.一种基于边缘计算的云游戏服务质量增强方法,其特征是将服务器安置在边缘,靠近终端,构成边缘服务器集群;使用边缘服务器来负责渲染游戏视频并传输给这些边缘服务器附近的终端;本方法的步骤包括:
1)在部署边缘服务器之前,云端服务中心需要执行集群区域划分算法来确定边缘服务器集群的位置和服务器范围,该算法根据每个云游戏集群区域的负载划分云游戏集群区域;
2)在集群区域划分好之后,当一个新玩家请求加入游戏时,云端服务中心执行集群选择算法根据玩家游戏的延迟要求和资源要求来为该玩家选择最适当的边缘服务器集群,让玩家加入;
3)在集群选好之后,再根据该集群中玩家的社交网络关系来进行选择边缘服务器加入;
4)若边缘服务器集群中的服务器数量不够或者过剩时候,执行服务器动态部署策略来动态的调节服务器的开启数量,服务器动态部署策略为:预先准备足够多的边缘服务器,在高峰期之前部署足够多的边缘服务器,在高峰期过后再关闭其中空闲的服务器;
所述步骤1)中,集群区域划分算法为:
把一个云游戏集群区域随机分成多个子区域,每个子区域代表一个集群,该子区域的范围就是该集群的服务范围;然后用边ei,j的权重wi,j∈R表示节点i和节点j之间的负载;自环的边ei,i表示集群内部自身的负载;
集群区域划分算法迭代执行两个阶段:
第一阶段:首先遍历边集E中的所有边,选出权重最大的边ei,j,且满足节点i和节点j在地理位置上是相邻的,还要满足集群i和集群j中的负载量小于等于集群的处理能力最大值C,即:wi,i+wi,j+wj,iwj,j≤C;
第二阶段:对节点i和节点j进行合并,合并后用一个新节点k来表示;节点k的邻居是节点i和节点j之前的邻居,节点k与其邻居之间的权重等于节点i与其邻居之间的权重加上节点j与其邻居之间的权重;
最后,新的自环的权重等于前两个自环的权重加上节点i和j之间的权重;一旦第二阶段完成,就把新生成的无向图作为输入重新执行集群区域划分算法的第一阶段;这样一直迭代下去,直到表示算法的无向图中的节点无法满足要求为止;
所述步骤2)中,集群选择算法为:
定义某一个边缘服务器集群中服务器剩余的最大GPU容量为Gmax,最大CPU容量为Gmax;在云端服务中心存储一个集群列表group_list,用来记录Gmax和Gmax及其集群序号ID和IP地址;维护一张游戏列表game_list,用于描述game_list[i]这款游戏运行时所需要的GPU资源GPUneed、CPU资源CPUneed和其最大响应延迟容忍度Lmax;这里game_list[i]表示游戏列表中第i款游戏;
首先,第i个终端玩家pi选择某游戏之后,向云端服务中心请求该游戏并提交该游戏所需的资源GPUneed、CPUneed和Ltest;Ltest是响应延迟容忍度的测试值;
然后,云端服务中心根据玩家pi所请求的资源,在group_list中查找能够满足式1所示条件的集群,使所有游戏列表game_list中的GPU资源和CPU资源最小,并且要满足这些游戏的需求;
接着,云端服务中心返回一定数量的、有足够能力的边缘服务器集群列表;并使用集群的IP地址和玩家的IP地址来计算每个集群到终端玩家的物理距离;根据物理距离选出多个候选边缘服务器集群生成集群候选列表;
终端玩家pi从云端服务中心接收到集群候选列表后,对表中集群进行响应时延测试,对比测试所得的延迟与游戏本身的延迟要求;移除响应时延大于游戏本身延迟要求的候选服务器集群;将候选集群按照响应时延升序排序得到排序列表;
在终端玩家pi选择边缘服务器集群的过程中,如果该集群接入了其他终端玩家导致不再有足够的剩余容量,则终端玩家pi按照排序列表依次询问候选集群是否有可用容量;
如果有集群满足要求,终端玩家pi就连接加入该集群,然后调用服务器选择算法在该集群中选择恰当的服务器;
如果没有集群满足要求的,云端服务中心就向响应延迟最小的集群请求执行边缘服务器动态部署策略,开启一个新服务器进行分配;
所述步骤3)中,执行服务器选择算法选择边缘服务器加入;
所述服务器选择算法为:
通过把共同游戏的玩家分配到同一服务器上,并且当好友一起游戏时,他们的游戏时长基本上都是一样的,这样把他们分配在同一台服务器上,当游戏结束时,直接关闭这台服务器;
当新玩家进入边缘服务器集群时,如果该新玩家与其他玩家是好友关系,就把这个新玩家分配给其大部分好友所在的服务器,如果该新玩家与其他玩家不是好友关系,则将随机分配一个服务器;
将周期性地执行服务器选择算法来调整玩家的服务器;
所述步骤4)中,部署边缘服务器的数量的方法为:先预测玩家的数量;然后基于玩家的数量来确定预先部署边缘服务器的数量;
预测玩家数量的过程是,以m小时的时间周期进行,先把每个星期都划分为7×24/m=T个时间窗口;一个周期代表一天的游戏活动;每个周期又分为24个子周期;
用Gi表示在第i个时间窗口内的玩家的预测数量;Gi根据上周同一时间的在线玩家数量预测到,其中i∈T;
使用季节性的ARIMA模型来预测玩家的数量:
预测本周的第i个时间窗口的玩家人数Gi,是基于本周的第i-1个时间窗口的玩家数据Gi-1即为当前时间窗口、上周的同一时间窗口的数据Gt-T、上周的同一时间窗口的前一个时间窗口的在线人数Gt-T-1,i表示本周的某个时间窗口;t表示上周的某个时间窗口;即:
Gi=Gi-1+Gi-T-Gi-T-1-θωi-1-θωi-T-θλωi-T-1 (6)
其中,θ是季节性的ARIMA模型中的移动平均系数,λ是季节性的ARIMA模型中的季度移动平均线的系数;ωi~N(0,σ2)为服从均值为0、方差为σ2分布的白噪声序列;
为了能够支持Gi数量的玩家,所需的边缘服务器的数量Gsi为:
Gsi=(1+δ)×Gi/Cavg (7)
其中,Cavg为服务器的平均服务能力即为能够支持的玩家数量;δ为服务器数量的比例因子,δ∈[0.1],用于调节服务器数量;
选择当前区域内,那些服务大量玩家的服务器开启;
使用G′i记录边缘服务器在前一个时间段中所服务的玩家数量,根据G′i降序排列所有的候选边缘服务器,选择前Gsi个边缘服务器。
2.一种使用权利要求1所述方法的云游戏***,包括云端服务中心和终端,其特征是还包括边缘服务器集群;
在部署边缘服务器之前,云端服务中心需要执行集群区域划分算法来确定边缘服务器集群的位置和边缘服务器范围,该算法根据每个云游戏集群区域的负载划分云游戏集群区域;
在集群区域划分好之后,当一个新玩家请求加入游戏时,云端服务中心执行集群选择算法,根据终端玩家游戏的延迟要求和资源要求来为该玩家选择最适当的边缘服务器集群,让玩家加入;
在集群选好之后,再根据该集群中终端玩家的社交网络关系来进行选边缘择服务器加入。
3.根据权利要求2所述的云游戏***,其特征是若边缘服务器集群中的服务器数量不够或者过剩时候,使用权利要求1所述方法,执行服务器动态部署策略来动态的调节服务器的开启数量。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010511256.4A CN111669444B (zh) | 2020-06-08 | 2020-06-08 | 基于边缘计算的云游戏服务质量增强方法及*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010511256.4A CN111669444B (zh) | 2020-06-08 | 2020-06-08 | 基于边缘计算的云游戏服务质量增强方法及*** |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111669444A CN111669444A (zh) | 2020-09-15 |
CN111669444B true CN111669444B (zh) | 2021-12-10 |
Family
ID=72385687
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010511256.4A Active CN111669444B (zh) | 2020-06-08 | 2020-06-08 | 基于边缘计算的云游戏服务质量增强方法及*** |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111669444B (zh) |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112491978B (zh) * | 2020-11-12 | 2022-02-18 | 中国联合网络通信集团有限公司 | 一种调度方法和设备 |
CN112565884B (zh) * | 2020-11-27 | 2024-03-05 | 北京达佳互联信息技术有限公司 | 图像处理方法、装置、终端、服务器及存储介质 |
CN112463386B (zh) * | 2020-12-08 | 2022-08-02 | 内蒙古大学 | 用于异构云环境下在线游戏应用的虚拟机管理方法及*** |
CN112685187B (zh) * | 2021-03-17 | 2021-06-25 | 北京海誉动想科技股份有限公司 | 云游戏资源调度方法与装置 |
CN113141511A (zh) * | 2021-04-20 | 2021-07-20 | 上海卓易科技股份有限公司 | 一种图形渲染方法及设备 |
CN115277802B (zh) * | 2021-04-29 | 2023-08-08 | 中国联合网络通信集团有限公司 | 一种数据传输方法及网关 |
WO2022096946A1 (en) * | 2021-06-16 | 2022-05-12 | Sensetime International Pte. Ltd. | Game state detection and configuration updating method and apparatus, device and storage medium |
CN113422822B (zh) * | 2021-06-21 | 2022-04-26 | 广东电网有限责任公司 | 一种边缘计算自适应网络方法、***、终端和存储介质 |
CN113467958B (zh) * | 2021-09-02 | 2021-12-14 | 腾讯科技(深圳)有限公司 | 一种数据处理方法、装置、设备以及可读存储介质 |
CN116074323B (zh) * | 2023-03-10 | 2023-06-09 | 腾讯科技(深圳)有限公司 | 边缘计算节点的选择方法、装置、计算机设备及介质 |
CN116049019B (zh) * | 2023-03-29 | 2023-06-09 | 中诚华隆计算机技术有限公司 | 一种基于测试芯片对软件进行测试的方法及*** |
CN116983617B (zh) * | 2023-09-25 | 2024-01-05 | 深圳云天畅想信息科技有限公司 | 跨集群资源调度方法、计算机装置及存储介质 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106390449A (zh) * | 2016-09-19 | 2017-02-15 | 南京工业大学 | 一种基于图形虚拟化技术的云游戏框架 |
CN109460297A (zh) * | 2018-11-01 | 2019-03-12 | 中山大学 | 一种边缘云游戏缓存和资源调度方法 |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108499100B (zh) * | 2018-03-30 | 2021-02-19 | 南京工业大学 | 一种基于边缘计算的云游戏错误恢复方法及*** |
CN108815842A (zh) * | 2018-06-01 | 2018-11-16 | 网宿科技股份有限公司 | 一种运行云游戏的方法、设备和*** |
US10874941B2 (en) * | 2018-06-01 | 2020-12-29 | At&T Intellectual Property I, L.P. | Virtualized gaming emulation as a network service |
CN109889576B (zh) * | 2019-01-18 | 2021-11-02 | 天津大学 | 一种基于博弈论的移动云游戏资源优化方法 |
CN110022377B (zh) * | 2019-04-19 | 2021-11-09 | 中国联合网络通信集团有限公司 | 云游戏服务器的调整方法及*** |
CN110933036B (zh) * | 2019-10-29 | 2022-03-22 | 咪咕互动娱乐有限公司 | 一种云游戏服务***和服务器 |
-
2020
- 2020-06-08 CN CN202010511256.4A patent/CN111669444B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106390449A (zh) * | 2016-09-19 | 2017-02-15 | 南京工业大学 | 一种基于图形虚拟化技术的云游戏框架 |
CN109460297A (zh) * | 2018-11-01 | 2019-03-12 | 中山大学 | 一种边缘云游戏缓存和资源调度方法 |
Non-Patent Citations (1)
Title |
---|
An Evaluation of QoE in Cloud Gaming Based on Subjective Tests;Michael Jarschel等;《2011 Fifth International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing》;20110804;全文 * |
Also Published As
Publication number | Publication date |
---|---|
CN111669444A (zh) | 2020-09-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN111669444B (zh) | 基于边缘计算的云游戏服务质量增强方法及*** | |
Lin et al. | CloudFog: Leveraging fog to extend cloud gaming for thin-client MMOG with high quality of service | |
CN110971706B (zh) | Mec中近似最优化与基于强化学习的任务卸载方法 | |
Ranadheera et al. | Mobile edge computation offloading using game theory and reinforcement learning | |
Prodan et al. | Prediction-based real-time resource provisioning for massively multiplayer online games | |
JP2021525402A (ja) | モバイルエッジコンピューティングのシナリオでシングルタスクオフロード戦略を策定する方法 | |
CN113434212A (zh) | 基于元强化学习的缓存辅助任务协作卸载与资源分配方法 | |
Lin et al. | A two-stage framework for the multi-user multi-data center job scheduling and resource allocation | |
CN111866601A (zh) | 一种基于合作博弈的移动边缘场景中的视频码率决策方法 | |
Deng et al. | Deep-reinforcement-learning-based resource allocation for cloud gaming via edge computing | |
US20230093368A1 (en) | Game data processing method, apparatus, and system, electronic device, and storage medium | |
CN112799823A (zh) | 边缘计算任务的在线分派调度方法和*** | |
WO2023116460A1 (zh) | 移动边缘计算环境下多用户多任务计算卸载方法及*** | |
Aboutorabi et al. | An Optimized Meta-heuristic Bees Algorithm for Players' Frame Rate Allocation Problem in Cloud Gaming Environments. | |
CN116669111A (zh) | 一种基于区块链的移动边缘计算任务卸载方法 | |
Barri et al. | Distributing game instances in a hybrid client-server/P2P system to support MMORPG playability | |
CN113486042B (zh) | 数据处理方法、装置、计算机可读介质及电子设备 | |
Cao et al. | Service placement and bandwidth allocation for MEC-enabled mobile cloud gaming | |
Cao et al. | Adaptive provisioning for mobile cloud gaming at edges | |
CN113778675A (zh) | 一种基于面向区块链网络的计算任务分配***及方法 | |
Nguyen et al. | EdgePV: collaborative edge computing framework for task offloading | |
Hu et al. | Maximum profit of real-time IoT content retrieval by joint content placement and storage allocation in C-RANs | |
CN110743164B (zh) | 一种用于降低云游戏中响应延迟的动态资源划分方法 | |
Huang et al. | Joint optimization of task scheduling and computing resource allocation for VR video services in 5G‐advanced networks | |
CN115022332A (zh) | 一种边缘计算中基于深度强化学习的动态服务放置方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |