« 保重身体 | 返回首页 | Windows 下的进程间通讯及数据共享 »

针对网络游戏客户端更新的 P2P 网络

我最近在构思一个用 P2P 网络同步文件的计划。用于以后网络游戏的 client 同步更新。现有的 BT 之类的软件很成熟了，不过我考虑到网络游戏有其特殊性，说不定可以做的更好。

网络游戏可以说有一个天然的稳定的 p2p 网络的基础，好象我们的梦幻西游，最高已经超过八十万玩家同时在线了。而所有玩家所需求的是同一份 client。这跟 BT 网络上传输文件的需求和环境都不太相同。

游戏服务器将是一个天然的中心管理服务器，类似 BT 的种子发布服务器。BT 的下个版本据说要加入分布式的用户列表。也是，如果真有几十万玩家同时需要共享一份文件时，让每个玩家都知道他们的几十万同伙的位置是不现实的。这就需要分布式来做。而且，我们的游戏相关服务器是全职为玩家服务器的，无论从带宽还是性能上，都非常不错，这点应该加以利用。

关于分布式用户列表的问题暂时不讨论了，我最近想的比较多的是针对 LAN 的优化。

很明显，现在国内的网络玩家很多都是网吧用户。网吧更新是一个大问题，以前没有用 P2P 技术前，网吧老板大多采用自己同步 client 的作法。现在越来越多的游戏 client 采用 P2P 了，一般内嵌一个 BT 。但是当用户特别多时，BT 种子服务器都不堪重负（这个是存在于我们公司运营中的梦幻西游和大话西游的事实）。

如果能针对 LAN 做一些优化就好了。我能想到的是，如果一个玩家可以在自己的 LAN 上发现一份 copy ，就不再外连 BT 种子服务器，而是相互通讯，复制一份过来。整个 LAN 充当外部 P2P 网络的一个节点，如果有对外的连接任务，大家应该协商平摊，不应该做重复的事情。而且任务也尽量分散，不让某一台机器处理的任务过多，造成 CPU 和单机的网络负载太大。

在一个 LAN 上，各个玩家伙伴的身份是对等的，没有中央服务器，所以协调工作是很难展开的。我们务必先产生出一个领导者。因为领导者是临时产生的，我们无法确定它的机器性能如何，是否能长期稳定工作。所以，我们不能让领导者担负过强的工作，而且要有集体认可的候补人员。

能想到的最简单的集体推选方法是这样的：我们默认的标准是，IP 值最小的人是当然领导候选人。每个 client 进程启动后，都向 LAN 广播，准备参选领导职位。如果 LAN 上已经存在领导人，每个人都回复他现在的领导人是谁。如果他是更适合当领导的人，所有人回复他，承认他的地位。

当这个新人收到别人的通知，得知领导人以后，他却没有收到领导人的消息，认为现任领导人可能失踪。由这个人推举新领导。直到大家都确认领导人是谁。

所有点对点传输任务，必须得到领导的认可。新人只有找到领导后，向领导索取LAN上自己的结队对象，领导分配至少1个的结队对象给他。这个新人再主动去向这些对象索取需要同步的文件。注：这里，LAN 上任何一个人向自己索取文件，并不需要先得到领导的同意就可以满足其要求。

整个 LAN 对外的连接需要得到领导的同意，当整个 LAN 上文件都不全时，领导主要定期向外索取连接，但是这个连接任务应该分摊给大家，而不是全部由自己连接。当同伴完成任务后，应该主动讲获取部分传回领导。（然后领导通知其他人去索要）

当整个 LAN 文件收全后，为了保证外部 P2P 网络的健全，整个 LAN 作为一个节点，应该主动发起连接，这个发起者就是领导。领导定期分配任务给同伴，让每个人平均分配对外的连接。

所有人都应该定期保持对领导的联系，防止领导意外失踪。

云风 提交于 October 21, 2005 10:18 PM |

Comments

eMule的就做到了，使用的ed2k协议，而且可以很好的躲避版权方追查，去中心化的服务，优先选择用户连接的节点处所在网络搜索资源。

Posted by: keli | (8) January 25, 2022 10:47 AM

网络游戏P2P智能更新解决方案 业界内最成熟稳定的P2P内核，5年的P2P领域经验，打造了行业内最强大的网络游戏P2P智能更新解决方案，完美的解决了网络游戏因短时间内海量数据的集中更新所产生的带宽瓶颈p2plib.com

Posted by: asseab | (7) July 15, 2009 11:36 AM

好想法, 好创意. 可以作为项目的附加实现!

Posted by: yongzhi.wu | (6) September 20, 2007 02:36 PM

当整个 LAN 向外部索取新的补丁的时候，没有领导是很有问题的。 因为大家可能同时向外部要相同的文件，而且可能会因为每个 client 都企图向外部保持太多连接而被 LAN 的网关封掉。

Posted by: Cloud [TypeKey Profile Page] | (5) March 2, 2006 01:50 PM

如果是为了客户端更新的话，象你说的这种情况，我觉得不需要领导这个角色吧？ 无非是如果 LAN 内有需要的数据就尽量向 LAN 内索取，否则 LAN 内所有的点协商后分别向外部索取数据的一部分，也就是搞一个尽量少跟外界联系的文件同步算法，对 LAN 这种规模来说根本不需要领导这个东东

Posted by: 一无所知 | (4) March 2, 2006 11:21 AM

感觉我看过的一篇paper和你的想法有点类似~ 我把conclusion打一点出来，如果有兴趣的话可以网上查找或者我整篇发给你：） in this paper, we have proposed the zoned federation model, which adapts MOG(multi-player Online Game) to peer-to-peer networks, In this modelm the whole game world is divided into several zones, and each zone is maintianed by a federation of nodes: an owner and one or more members. Zone owner plays two critical roles. First, it provides zone-local serializability of state changes, by affregating modifications from all members, adn by sending state-change notifications to all members. Second, it ensures consistency of changes that are committed by other member nodes. DHT harnesses this zoning layer by probideing rendezvous capability and by working as a backup medium for zone data. 引自Takuji I., Hiroaki H. and Youki K.: Zoned Federation of Game Servers: a Peer-to-peer Approach to Scalable Multi-player Online Games. In SSIGCOMM'04 Workshops, Aug.30+Sept. 3, 2004

Posted by: festony | (3) November 1, 2005 07:19 AM

想法不错。实现、优化，我想这对你是小菜了。 ：） 我是你在工大的师弟。

Posted by: maverick | (2) October 24, 2005 07:33 PM

^_^ 我从6年前就开始看你的网站了。那个时候还是网易的乱七八糟的主页呢。想不到今天偶然逛回来，发现你的Blog了，可能这也是缘分吧。呵呵。 我一直都在做web programming和信息发现和管理方面的事情，已经很少关注底层的技术了，看到你一直都在做算法和底层引擎研究，真的很佩服和羡慕呢。 ^_^

Posted by: Felix Wong [TypeKey Profile Page] | (1) October 24, 2005 01:13 PM

Post a comment

非这个主题相关的留言请到：留言本