广播和监督服务器
前几天写到我们把服务器组分成连接服务器和逻辑服务器的想法,这代码部分已经完成,并且比最初的构想增加了不少东西。比如允许逻辑服务器广播数据包,由连接服务器分发等。
随着工作的深入,这两天想了更多东西。
我们的目的是尽量把每个部分做的简洁清晰,功能单一。游戏逻辑服务器可能是有最复杂的处理流程,所以我们务必减少它处理的事务。比如 聊天等。
那么还有什么可以剥离的事务呢?其实对于作弊检测,监视数据交互等都属于这一类。比如,如果我需要得到所有 player 所在的坐标的地图,直接向逻辑服务器索取,对这台服务器的负担就比较大。
现在想到的方案是,由连接服务器把需要传递给逻辑服务器的数据 clone 一份,发到另一台广播服务器上(暂定名)。这台广播服务器只负责接收数据,而不会有任何数据反馈。这样,不会给连接服务器带来过大的负担。
广播服务器可以选择把数据筛选再广播到更多的服务器上,让每个服务器处理更细致的任务。例如 player 的坐标,可以通过筛选出所有移动相关的数据包得到。并且可以根据这个有限的检测出速度作弊。GM 也可以连接到这里,获取整个游戏世界中 player 的位置分布图而不需要担心这个操作增加逻辑服务器的负担。
广播服务器应该是可以随时连入随时断开的。如果支持这个特性,那么它还是需要跟逻辑服务器通讯。我们的逻辑服务器跟连接服务器是用脉冲(或者心跳)保持通讯的节奏的。所以,广播服务器在接入连接服务器时,连接服务器只用通知它脉冲号是多少。然后广播服务器再向逻辑服务器索取初始状态,就可以随时和逻辑服务器同步了。
例如,广播服务器在第 100 个脉冲接入连接服务器,那么它就具有了第100个脉冲之后的所有 client 发过来的数据包。之后它跟逻辑服务器建立联系,假设逻辑服务器在 110 个脉冲的时候通知广播服务器所有状态数据(逻辑服务器可以 fork 一个子进程慢慢发这些数据)。下面的工作,广播服务器可能在 120 个脉冲接收完所有这些状态数据。它可以丢弃掉 100~110 之间的数据包,并把 110~120 之间的数据包作用于 110 那个时候的状态数据上,得以跟逻辑服务器同步。
有了这台广播服务器后,我们可以多出很多运用,这里就不一一展开讨论了。
Comments
您好,我想问一下网络游戏中由于网络延迟造成的瞬移和所用的同步算法有关系吗?如果用DR算法还会产生瞬移吗?
Posted by: 崔娜 | (4) June 3, 2012 10:26 AM
向一个软件实体请求服务有两种思路,一是每一个请求找一个专用的通道,只要从这个通道上来的,不用多说,就是来享受某个特定服务的。二是所有的请求都走一个通道,在拜贴上填写自己申请的具体内容。从技术发展的实践来看,第二种思路不断地替换第一种思路。但我觉得两种思路恰当配合可能是最合理的。云风的这个实践我认为就是这样的一种恰当配合的尝试。具体怎么样,还要看看。
Posted by: myan | (3) May 9, 2006 11:55 AM
不好意思,能否请问一下写《水滴石穿C语言》系列的那个楚云风是不是你?
Posted by: sPhinX | (2) April 27, 2006 10:55 AM
这些东西,对于Java来说就是一个一个EJB
Posted by: Atry | (1) April 26, 2006 09:05 PM