小谈Online-game服务器端设计(1、2)

谈这个话题之前,首先要让大家知道,什么是服务器。在网络游戏中,服务器所扮演的角色是同步,广播和服务器主动的一些行为,比如说天气,NPC AI之类的,之所以现在的很多网络游戏服务器都需要负担一些游戏逻辑上的运算是因为为了防止客户端的作弊行为。了解到这一点,那么本系列的文章将分为两部分来谈谈网络游戏服务器的设计,一部分是讲如何做好服务器的网络连接,同步,广播以及NPC的设置,另一部分则将着重谈谈哪些逻辑放在服务器比较合适,并且用什么样的结构来安排这些逻辑。
服务器的网络连接
  大多数的网络游戏的服务器都会选择非阻塞select这种结构,为什么呢?因为网络游戏的服务器需要处理的连接非常之多,并且大部分会选择在Linux/Unix下运行,那么为每个用户开一个线程实际上是很不划算的,一方面因为在Linux/Unix下的线程是用进程这么一个概念模拟出来的,比较消耗系统资源,另外除了I/O之外,每个线程基本上没有什么多余的需要并行的任务,而且网络游戏是互交性非常强的,所以线程间的同步会成为很麻烦的问题。由此一来,对于这种含有大量网络连接的单线程服务器,用阻塞显然是不现实的。对于网络连接,需要用一个结构来储存,其中需要包含一个向客户端写消息的缓冲,还需要一个从客户端读消息的缓冲,具体的大小根据具体的消息结构来定了。另外对于同步,需要一些时间校对的值,还需要一些各种不同的值来记录当前状态,下面给出一个初步的连接的结构:
typedef connection_s {
    user_t *ob; /* 指向处理服务器端逻辑的结构 */
    int fd; /* socket连接 */
    struct sockaddr_in addr; /* 连接的地址信息 */
    char text[MAX_TEXT]; /* 接收的消息缓冲 */
    int text_end; /* 接收消息缓冲的尾指针 */
    int text_start; /* 接收消息缓冲的头指针 */
    int last_time; /* 上一条消息是什么时候接收到的 */
    struct timeval latency; /* 客户端本地时间和服务器本地时间的差值 */
    struct timeval last_confirm_time; /* 上一次验证的时间 */
    short is_confirmed; /* 该连接是否通过验证过 */
    int ping_num; /* 该客户端到服务器端的ping值 */
    int ping_ticker; /* 多少个IO周期处理更新一次ping值 */
    int message_length; /* 发送缓冲消息长度 */
    char message_buf[MAX_TEXT]; /* 发送缓冲区 */
    int iflags; /* 该连接的状态 */
} connection_t;
  服务器循环的处理所有连接,是一个死循环过程,每次循环都用select检查是否有新连接到达,然后循环所有连接,看哪个连接可以写或者可以读,就处理该连接的读写。由于所有的处理都是非阻塞的,所以所有的Socket IO都可以用一个线程来完成。
  由于网络传输的关系,每次recv()到的数据可能不止包含一条消息,或者不到一条消息,那么怎么处理呢?所以对于接收消息缓冲用了两个指针,每次接收都从text_start开始读起,因为里面残留的可能是上次接收到的多余的半条消息,然后text_end指向消息缓冲的结尾。这样用两个指针就可以很方便的处理这种情况,另外有一点值得注意的是:解析消息的过程是一个循环的过程,可能一次接收到两条以上的消息在消息缓冲里面,这个时候就应该执行到消息缓冲里面只有一条都不到的消息为止,大体流程如下:
while ( text_end – text_start > 一条完整的消息长度 )
{
    从text_start处开始处理;
    text_start += 该消息长度;
}
memcpy ( text, text + text_start, text_end – text_start );
  对于消息的处理,这里首先就需要知道你的游戏总共有哪些消息,所有的消息都有哪些,才能设计出比较合理的消息头。一般来说,消息大概可分为主角消息,场景消息,同步消息和界面消息四个部分。其中主角消息包括客户端所控制的角色的所有动作,包括走路,跑步,战斗之类的。场景消息包括天气变化,一定的时间在场景里出现一些东西等等之类的,这类消息的特点是所有消息的发起者都是服务器,广播对象则是场景里的所有玩家。而同步消息则是针对发起对象是某个玩家,经过服务器广播给所有看得见他的玩家,该消息也是包括所有的动作,和主角消息不同的是该种消息是服务器广播给客户端的,而主角消息一般是客户端主动发给服务器的。最后是界面消息,界面消息包括是服务器发给客户端的聊天消息和各种属性及状态信息。
  下面来谈谈消息的组成。一般来说,一个消息由消息头和消息体两部分组成,其中消息头的长度是不变的,而消息体的长度是可变的,在消息体中需要保存消息体的长度。由于要给每条消息一个很明显的区分,所以需要定义一个消息头特有的标志,然后需要消息的类型以及消息ID。消息头大体结构如下:
type struct message_s {
    unsigned short message_sign;
    unsigned char message_type;
    unsigned short message_id
    unsigned char message_len
}message_t;
服务器的广播
  服务器的广播的重点就在于如何计算出广播的对象。很显然,在一张很大的地图里面,某个玩家在最东边的一个动作,一个在最西边的玩家是应该看不到的,那么怎么来计算广播的对象呢?最简单的办法,就是把地图分块,分成大小合适的小块,然后每次只象周围几个小块的玩家进行广播。那么究竟切到多大比较合适呢?一般来说,切得块大了,内存的消耗会增大,切得块小了,CPU的消耗会增大(原因会在后面提到)。个人觉得切成一屏左右的小块比较合适,每次广播广播周围九个小块的玩家,由于广播的操作非常频繁,那么遍利周围九块的操作就会变得相当的频繁,所以如果块分得小了,那么遍利的范围就会扩大,CPU的资源会很快的被吃完。
  切好块以后,怎么让玩家在各个块之间走来走去呢?让我们来想想在切换一次块的时候要做哪些工作。首先,要算出下个块的周围九块的玩家有哪些是现在当前块没有的,把自己的信息广播给那些玩家,同时也要算出下个块周围九块里面有哪些物件是现在没有的,把那些物件的信息广播给自己,然后把下个块的周围九快里没有的,而现在的块周围九块里面有的物件的消失信息广播给自己,同时也把自己消失的消息广播给那些物件。这个操作不仅烦琐而且会吃掉不少CPU资源,那么有什么办法可以很快的算出这些物件呢?一个个做比较?显然看起来就不是个好办法,这里可以参照二维矩阵碰撞检测的一些思路,以自己周围九块为一个矩阵,目标块周围九块为另一个矩阵,检测这两个矩阵是否碰撞,如果两个矩阵相交,那么没相交的那些块怎么算。这里可以把相交的块的坐标转换成内部坐标,然后再进行运算。
  对于广播还有另外一种解决方法,实施起来不如切块来的简单,这种方法需要客户端来协助进行运算。首先在服务器端的连接结构里面需要增加一个广播对象的队列,该队列在客户端登陆服务器的时候由服务器传给客户端,然后客户端自己来维护这个队列,当有人走出客户端视野的时候,由客户端主动要求服务器给那个物件发送消失的消息。而对于有人总进视野的情况,则比较麻烦了。
  首先需要客户端在每次给服务器发送update position的消息的时候,服务器都给该连接算出一个视野范围,然后在需要广播的时候,循环整张地图上的玩家,找到坐标在其视野范围内的玩家。使用这种方法的好处在于不存在转换块的时候需要一次性广播大量的消息,缺点就是在计算广播对象的时候需要遍历整个地图上的玩家,如果当一个地图上的玩家多得比较离谱的时候,该操作就会比较的慢。
服务器的同步
  同步在网络游戏中是非常重要的,它保证了每个玩家在屏幕上看到的东西大体是一样的。其实呢,解决同步问题的最简单的方法就是把每个玩家的动作都向其他玩家广播一遍,这里其实就存在两个问题:1,向哪些玩家广播,广播哪些消息。2,如果网络延迟怎么办。事实上呢,第一个问题是个非常简单的问题,不过之所以我提出这个问题来,是提醒大家在设计自己的消息结构的时候,需要把这个因素考虑进去。而对于第二个问题,则是一个挺麻烦的问题,大家可以来看这么个例子:
  比如有一个玩家A向服务器发了条指令,说我现在在P1点,要去P2点。指令发出的时间是T0,服务器收到指令的时间是T1,然后向周围的玩家广播这条消息,消息的内容是“玩家A从P1到P2”有一个在A附近的玩家B,收到服务器的这则广播的消息的时间是T2,然后开始在客户端上画图,A从P1到P2点。这个时候就存在一个不同步的问题,玩家A和玩家B的屏幕上显示的画面相差了T2-T1的时间。这个时候怎么办呢?
  有个解决方案,我给它取名叫 预测拉扯,虽然有些怪异了点,不过基本上大家也能从字面上来理解它的意思。要解决这个问题,首先要定义一个值叫:预测误差。然后需要在服务器端每个玩家连接的类里面加一项属性,叫latency,然后在玩家登陆的时候,对客户端的时间和服务器的时间进行比较,得出来的差值保存在latency里面。还是上面的那个例子,服务器广播消息的时候,就根据要广播对象的latency,计算出一个客户端的CurrentTime,然后在消息头里面包含这个CurrentTime,然后再进行广播。并且同时在玩家A的客户端本地建立一个队列,保存该条消息,只到获得服务器验证就从未被验证的消息队列里面将该消息删除,如果验证失败,则会被拉扯回P1点。然后当玩家B收到了服务器发过来的消息“玩家A从P1到P2”这个时候就检查消息里面服务器发出的时间和本地时间做比较,如果大于定义的预测误差,就算出在T2这个时间,玩家A的屏幕上走到的地点P3,然后把玩家B屏幕上的玩家A直接拉扯到P3,再继续走下去,这样就能保证同步。更进一步,为了保证客户端运行起来更加smooth,我并不推荐直接把玩家拉扯过去,而是算出P3偏后的一点P4,然后用(P4-P1)/T(P4-P3)来算出一个很快的速度S,然后让玩家A用速度S快速移动到P4,这样的处理方法是比较合理的,这种解决方案的原形在国际上被称为(Full plesiochronous),当然,该原形被我篡改了很多来适应网络游戏的同步,所以而变成所谓的:预测拉扯。
  另外一个解决方案,我给它取名叫 验证同步,听名字也知道,大体的意思就是每条指令在经过服务器验证通过了以后再执行动作。具体的思路如下:首先也需要在每个玩家连接类型里面定义一个latency,然后在客户端响应玩家鼠标行走的同时,客户端并不会先行走动,而是发一条走路的指令给服务器,然后等待服务器的验证。服务器接受到这条消息以后,进行逻辑层的验证,然后计算出需要广播的范围,包括玩家A在内,根据各个客户端不同的latency生成不同的消息头,开始广播,这个时候这个玩家的走路信息就是完全同步的了。这个方法的优点是能保证各个客户端之间绝对的同步,缺点是当网络延迟比较大的时候,玩家的客户端的行为会变得比较不流畅,给玩家带来很不爽的感觉。该种解决方案的原形在国际上被称为(Hierarchical master-slave synchronization),80年代以后被广泛应用于网络的各个领域。
  最后一种解决方案是一种理想化的解决方案,在国际上被称为Mutual synchronization,是一种对未来网络的前景的良好预测出来的解决方案。这里之所以要提这个方案,并不是说我们已经完全的实现了这种方案,而只是在网络游戏领域的某些方面应用到这种方案的某些思想。我对该种方案取名为:半服务器同步。大体的设计思路如下:
  首先客户端需要在登陆世界的时候建立很多张广播列表,这些列表在客户端后台和服务器要进行不及时同步,之所以要建立多张列表,是因为要广播的类型是不止一种的,比如说有local message,有remote message,还有global message 等等,这些列表都需要在客户端登陆的时候根据服务器发过来的消息建立好。在建立列表的同时,还需要获得每个列表中广播对象的latency,并且要维护一张完整的用户状态列表在后台,也是不及时的和服务器进行同步,根据本地的用户状态表,可以做到一部分决策由客户端自己来决定,当客户端发送这部分决策的时候,则直接将最终决策发送到各个广播列表里面的客户端,并对其时间进行校对,保证每个客户端在收到的消息的时间是和根据本地时间进行校对过的。那么再采用预测拉扯中提到过的计算提前量,提高速度行走过去的方法,将会使同步变得非常的smooth。该方案的优点是不通过服务器,客户端自己之间进行同步,大大的降低了由于网络延迟而带来的误差,并且由于大部分决策都可以由客户端来做,也大大的降低了服务器的资源。由此带来的弊端就是由于消息和决策权都放在客户端本地,所以给外挂提供了很大的可乘之机。

 

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/444975.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

Linux(8)-Linux下的编程开发-C/C++、PHP、JAVA概述

Linux下的编程开发1.C/C语言开发环境的搭建2.PHP开发环境搭建3.JAVA开发环境搭建1.C/C语言开发环境的搭建 方式1:文本编辑器编译器(gcc/g) Ubuntu 下常用的文本编辑器: Gedit–语法高亮Vim–vi(无比强大无比难用)的改进。字符界面/图形界面…

leetcode55 跳跃游戏 秒杀所有答案

给定一个非负整数数组,你最初位于数组的第一个位置。 数组中的每个元素代表你在该位置可以跳跃的最大长度。 判断你是否能够到达最后一个位置。 示例 1: 输入: [2,3,1,1,4] 输出: true 解释: 我们可以先跳 1 步,从位置 0 到达 位置 1, 然后再从位置 …

小谈Online-game服务器端设计(3)

下面我想来谈谈关于服务器上NPC的设计以及NPC智能等一些方面涉及到的问题。首先,我们需要知道什么是NPC,NPC需要做什么。NPC的全称是(Non-Player Character),很显然,他是一个character,但不是玩…

小谈Online-game服务器端设计(4)

在这一章节,我想谈谈关于服务器端的脚本的相关设计。因为在上一章节里面,谈NPC智能相关的时候已经接触到一些脚本相关的东东了。还是先来谈谈脚本的作用吧。   在基于编译的服务器端程序中,是无法在程序的运行过程中构建一些东西的&#xf…

leetcode45 跳跃游戏II 秒杀所有答案

给定一个非负整数数组,你最初位于数组的第一个位置。 数组中的每个元素代表你在该位置可以跳跃的最大长度。 你的目标是使用最少的跳跃次数到达数组的最后一个位置。 示例: 输入: [2,3,1,1,4] 输出: 2 解释: 跳到最后一个位置的最小跳跃数是 2。 从下标为 …

MachineLearning(7)-决策树基础+sklearn.DecisionTreeClassifier简单实践

sklearn.DecisionTreeClassifier决策树简单使用1.决策树算法基础2.sklearn.DecisionTreeClassifier简单实践2.1 决策树类2.3 决策树构建2.3.1全数据集拟合,决策树可视化2.3.2交叉验证实验2.3.3超参数搜索2.3.4模型保存与导入2.3.5固定随机数种子参考资料1.决策树算法…

游戏服务器体系结构

本文描述了一个我所设计的游戏服务器体系结构,其目的是实现游戏服务器的动态负载平衡,将对象从繁忙的服务器转移到相对空闲的服务器中.设计并没有经过具体的测试与验证,仅仅是将自己目前的一些想法记录下来.随着新构思的出现,可能会有所变化. 以下是服务器的逻辑视图,其中忽略…

游戏服务器架构探讨

要描述一项技术或是一个行业,一般都会从其最古老的历史开始说起,我本也想按着这个套路走,无奈本人乃一八零后小辈,没有经历过那些苦涩的却令人羡慕的单机游戏开发,也没有响当当的拿的出手的优秀作品,所以也…

leetcode72 编辑距离

给定两个单词 word1 和 word2,计算出将 word1 转换成 word2 所使用的最少操作数 。 你可以对一个单词进行如下三种操作: 插入一个字符 删除一个字符 替换一个字符 示例 1: 输入: word1 "horse", word2 "ros" 输出: 3 解释: ho…

即时通讯系统架构

有过几款IM系统开发经历,目前有一款还在线上跑着。准备简单地介绍一下大型商业应用的IM系统的架构。设计这种架构比较重要的一点是低耦合,把整个系统设计成多个相互分离的子系统。我把整个系统分成下面几个部分:(1)状态…

leetcode303 区域和检索

给定一个整数数组 nums,求出数组从索引 i 到 j (i ≤ j) 范围内元素的总和,包含 i, j 两点。 示例: 给定 nums [-2, 0, 3, -5, 2, -1],求和函数为 sumRange() sumRange(0, 2) -> 1 sumRange(2, 5) -> -1 sumRange(0,…

算法(24)-股票买卖

股票买卖1.动态规划框架LeetCode-121 一次买卖LeetCode-122 不限次数LeetCode-309 不限次数冷冻期LeetCode-714 不限次数手续费LeetCode-123 两次买卖LeetCode-188 k次买卖2.贪心特解LeetCode-121 一次买卖LeetCode-122 不限次数解题思路参考buladong解题,详细信息可…

网络游戏的客户端同步问题 .

有关位置同步的方案实际上已经比较成熟,网上也有比较多的资料可供参考。在《带宽限制下的视觉实体属性传播》一文中,作者也简单提到了位置同步方案的构造过程,但涉及到细节的地方没有深入,这里专门针对这一主题做些回顾。 最直接的…

leetcode319 灯泡的开关

初始时有 n 个灯泡关闭。 第 1 轮,你打开所有的灯泡。 第 2 轮,每两个灯泡你关闭一次。 第 3 轮,每三个灯泡切换一次开关(如果关闭则开启,如果开启则关闭)。第 i 轮,每 i 个灯泡切换一次开关。 …

网游服务器端设计思考:心跳设计

网络游戏服务器的主要作用是模拟整个游戏世界,客户端用过网络连接把一些信息数据发给服务器,在操作合法的情况下,更新服务器上该客户端对应的player实体、所在场景等,并把这些操作及其影响广播出去。让别的客户端能显示这些操作。…

算法(25)-括号

各种括号1.LeetCode-22 括号生成--各种括号排列组合2.LeetCode-20 有效括号(是否)--堆栈3.LeetCode-32 最长有效括号(长度)--dp4.LeetCode-301删除无效括号 --多种删除方式1.LeetCode-22 括号生成–各种括号排列组合 数字 n 代表生成括号的对数,请你设计一个函数&a…

(二十)深入浅出TCPIP之epoll的一些思考

Epoll基本介绍 在linux的网络编程中,很长的时间都在使用select来做事件触发。在linux新的内核中,有了一种替换它的机制,就是epoll。相比于 select,epoll最大的好处在于它不会随着监听fd数目的增长而降低效率。因为在内核中的select实现中,它是采用轮询来处理的,轮询的fd…

leetcode542 01矩阵

给定一个由 0 和 1 组成的矩阵,找出每个元素到最近的 0 的距离。 两个相邻元素间的距离为 1 。 示例 1: 输入: 0 0 0 0 1 0 0 0 0 输出: 0 0 0 0 1 0 0 0 0 示例 2: 输入: 0 0 0 0 1 0 1 1 1 输出: 0 0 0 0 1 0 1 2 1 注意: 给定矩阵的元素个数不超过 10000。…

RPC、RMI与MOM与组播 通信原理 .

远程过程调用(RPC): 即对远程站点机上的过程进行调用。当站点机A上的一个进程调用另一个站点机上的过程时,A上的调用进程挂起,B上的被调用过程执行,并将结果返回给调用进程,使调用进程继续执行【…

网关服务器 .

之前想着要把什么什么给写一下,每次都太懒了,都是想起了才来写一下。今天只讨论游戏服务器的网关服务器。 1.转发 转发客户端和服务器间的消息,网关将场景、会话、数据、名字、平台等服务器的数据转发给客户端,接收客户端的数据&a…