KBEngine 学习笔记 不定时跟新
http://kbengine.org/docs/configuration/entities.html
http://kbengine.org/docs/programming/entitydef.html
疑问:定义Entity的时候
客户端调了loginGateway以后base服务器就会创建account实体,创建完以后生成一个mailbox,然后调用客户端的onCreatedProxies方法,通知客户端创建account的客户端部分
同时服务器上account.py的onEntitiesEnabled函数也会被调用,表示account的客户端部分也创建好了,服务器逻辑层可以撸起来了
cellapp与cell关系:
cell是space(一个空间/场景)的一部分或者全部(由动态分割算法决定)。
cellapp是一个进程,所有的space-cell都创建在cellapp进程中
玩家的cell部分指的就是玩家在space-cell中对应的实体。
实体在不同cell中迁移, 有2个原因
第一个,由引擎动态负载均衡导致的迁移。
第二, 玩家移动导致跨越到另一个cell中
http://bbs.chinaunix.net/thread-2030722-1-1.html
服务端:考虑到服务端重启或多宿,为socket设置SO_REUSEADDR基本成为一个定律 客户端:客户端很少有必要bind端口,不bind时内核自动为你分配可用的端口 每个客户端都对应服务端的一个proxy, 这个proxy在进游戏后由于demo逻辑的做法他是一个account实体, 能让玩家在客户端选角色。 当玩家选完角色之后在服务端demo逻辑中会切换与客户端绑定的proxy,所以在玩家进入场景中时他是avatar。 有一些游戏也不需要按照这个逻辑写, 例如:登入游戏之后的这个account实体本身就是一个avatar, 不需要选择角色。 这些概念你需要理解基本之后才能灵活运用。 看看文档以及demo中的proxy是什么,如何切换控制权给另一个proxy。
self.client这个属性是一个maibox, 只能通过这个mailbox调用在def中定义的clientMethods方法。
mailbox在底层包含了ip地址与实体的id, 当你调用某个正确的方法后, 底层会将方法参数等信息打包并带上实体的id,在客户端根据实体的id调用到某个方法。
Volatile
账号登录的时候创建了一个proxy,然后选择角色进入游戏的时候又创建了一个proxy,不是说一个客户端就对应一个proxy?
avatar是proxy,服务器跟任何一个客户端之间同时只能存在一个proxy
当分布式的avatar需要存储时, baseapp先请求从cellapp获得数据放入base.cellData, 然后将所有持久化类型属性数据打包到dbmgr执行写入
引擎架构设计上baseApp, cellApp的区别 http://bbs.kbengine.org/forum.php?mod=viewthread&tid=69&highlight=baseApp
0基础学KBEngine基础学习笔记之一
做了一段时间U3D客户端,总想着接触一些服务器知识。于是搜了一下开源服务器框架,准备折腾一下KBEngine。
本人习惯接触一样新技术的时候就做一些笔记,很多时候做完就留着当备份,有空拿出来看看。因为写的烂,再说这些东西你影撸几遍代码也肯定搞的定了。
但是这次我决定分享出来贡献自己的一份力量。因为我发现KBEngine这个服务器引擎一个很纠结的问题。
不同于很多开源项目,KBEngine(以下简称KB)并没有那些 quick start 之类的东西,官网上的很多文档更类似与参考手册,这也许让很多慕名而来的人学个一两天就望而却步了。
当然或许从某种程度上说也算是一种考验,毕竟开源的东西你还要求这要求那也过分了。
废话不扯。开始正题,本人水平有限,发现问题欢迎各位喷我。
本篇只是开头,说句实话我目前了解的也不多,顶多能挤多少算多少。不定时更新。
在读这篇文章之前,请各位自定搭建运行好u3d demo。
了解服务器运行的一些抽象概念
首先了解一个概念,entity(实体),什么是实体,实体就是服务器所有东西的基类。
举个例子,你玩家登陆后,如果是个RPG游戏,你的新手村是个实体,你周围的NPC也是一个个实体,然后你自己当然也是个实体等等。
既然是实体,我们就需要交互,在交互之前,我们要了解一下谁负责我们实体数据的生命周期。
我目前浅薄的了解了一下,参考了下面这张图:
在这上面有很多app进程,loginapp 负责登录请求的转发,bassapp 负责实体的 base 部分,cellapp 负责实体的 cell 部分(一般来说就是空间部分的数据)
很明显我们实体的数据被不同的进程拆分了,举个例子说,玩家的背包数据是baseapp的 base 部分,在baseapp这个进程上被维护。同理,玩家的空间坐标是cellapp的 cell部分,在cellapp上被维护。
很好, 目前我们大略的讲了一下实体的生命维护,那么我们的交互呢?
首先,我们可以看到,一个实体上的数据虽然被拆分了,但是这些数据依旧是一个实体的,只是由不同进程维护(好像是废话)。
KB给这些被拆分的实体每一个都配了 mailbox 用于和自己实体的其他部分 或者其他实体,或者周围实体等等进行交互。(也就是所谓数据的作用域)
从某种程度上说隐藏了那些消息拆包,事件分发的机制。但实际上底层还是一样的。
目前就这些,接下类就是枯燥的通信流程了。