KBEngine loginapp-登录（转）
在前文《KBEngine 客户端-loginapp-协议加载》的最后，我们看到在 kbengine.js / onImportClientMessageCompleted 中，会以参数为 false 调用 login_loginapp(false) 函数。
kbengine.js / login 
因为参数 noconnect 为 false，所以这里逻辑会走到 3101~3107 行；
由前面的两篇协议构建文章，我们知道，这里就是往服务器 logapp 发送用户名、密码等信息，loginapp 的响应函数是 Loginapp::login 。
KBEngine.message.Loginapp_login 是如何对应到这个函数的，请看 《KBEngine 客户端-loginapp-协议加载》中的 loginapp.cpp / importClientMessages 章节。
loginapp.cpp / login 服务器端 login 响应客户端请求，先通过 python 脚本验证，然后数据库验证，然后返回负载较低的baseapp 地址。
上面的代码，精简了各种验证逻辑，可以看到行号是不连续的。这里面有几个逻辑：
- 773 行，表示要加载的 python 脚本文件在 assets/scripts/login 下面？(这个逻辑没有跟到）
- 895~903 行，调用 assets/login/kbengine.py 脚本里的 onRequestLogin 函数。
- 978~984 行，在 pendingLoginMgr_ 中缓存登录信息及客户端地址，因为此次登录尚未处理完，后续需要跳转到 Dbmgr 这个组件去进行处理，在 Dbmgr 处理完成之后，还会跳转回来继续处理。
- 995~999 行，调用 Dbmgr 中的 onAccountLogin 函数验证用户信息。
login / kbengine.py / onRequestLogin 
onRequestLogin 函数就只是简单的检查一下用户名、密码的长度就返回了。当然这里只是留了一个接口，可以自行修改逻辑。
dgmgr.cpp / onAccountLogin 
这个函数调用了 interface 的 loginAccount 函数来实现。
interface_handler.cpp / loginAccount 
可以看到，真正的数据库查询操作，是通过 DBTaskAcountLogin 来实现的。
dbtask.cpp / DBTaskAccountLogin::presentMainThread 
数据库的具体查询逻辑我们先不管；1603~1617行，数据查到之后，会反过来调用 Loginapp::onLoginAccountQueryResultFromDbMgr 函数。
Loginapp.cpp / onLoginAccountQueryResultFromDbmgr 通过 Dbmgr 从数据库查询到数据之后，通过这个回调函数，在 Loginapp 里继续处理登录流程。
这里有几个主要逻辑：
- 1110~1117 行，先调用 assets/login/kbengine.py 脚本里的 onLoginCallbackFromDB 函数，给脚本一个嵌入处理流程的机会 ^^
- 1152~1176 行，在 baseapp 上注册；为了叙述流程简单明了，我们只考虑 1165~1176 行的逻辑，也就是用户第一次登录；后面我们会看 Baseappmgr::registerPendingAccountToBaseapp 函数。
login / kbengine.py / onLoginCallbackFromDB 
可以看到，现在脚本的实现，就只是简单进行 log 输出。
由上图可可以看到 log 输出结果，在 logger_loginapp.2016-02-13.log 文件中，最前面的 S_INFO 的 S 表示是 Script 的输出。
baseappmgr.cpp / registerPendingAccountToBaseapp 这个函数，就是查找一个负载较低的 baseapp，然后在调用此 baseapp 的 registerPendingLogin 来进行注册。。
上图主要有几块逻辑：
- 367 行，找到最合适的 baseapp，其实就是通过 bestBaseappID_ 来查找的，这个是 Baseappmgr::updateBestBaseapp() 时就设置好了，使用时直接用就好。
至于各个 baseapp 之间的负载均衡，应该是在 Baseappmgr::findFreeBaseapp 函数里，基本逻辑是找到包含 entity 数最少的 baseapp，这个不在这里展开分析。 - 369~383 行，找不到 baseapp，应该是系统负载满了，那么就缓存信息，这里也不展开。
- 389~398 行，在具体的 baseapp 中注册用户信息，实际调用函数为Baseapp::registerPendingLogin。
baseapp.cpp / registerPendingLogin 
上图代码有几个主要逻辑：
- 2510~2526 行，调用 BaseappMgr::onPendingAccountGetBaseappAddr，这里最主要的作用是带回 baseapp 的地址和端口。这里绕来绕去应该是因为 baseapp 不能直接和 loginapp 通信，需要通过 baseappMgr？
- 2528~2536 行，在 PendingLoingMgr 中缓存当前登录用户信息，即在 baseapp 上注册一下，后续客户端直接连 baseapp 时需要靠这个注册信息来进一步验证。
baseappmgr.cpp / onPendingAccountGetBaseappAddr 
onPendingAccountGetBaseappAddr 调用 Baseappmgr::sendAllocatedBaseappAddr
来实现；最终通过调用
Loginapp::onLoginAccountQueryBaseappAddrFromBaseappmgr，把用户名，账户名，baseapp 端口、地址返回 loginapp。
loginapp.cpp / onLoginAccountQueryBaseappAddrFromBaseappmgr 
绕了一大圈，终于回到 Loginapp 了。 在 1207 行取到 客户端 的 channel，然后返回 baseapp 的 ip、port 等信息，1216 行指定这个消息由客户端的 onLoginSuccessfully 来响应，客户端的 Client_onLoginSuccessfully 函数将被调用（协议相关请看前面的两篇文章）。
kbengine.js / Client_onLoginSuccessfully 
终于回到客户端了 ^^
- 3238~3239 行，缓存 baseapp 地址
- 3246 行，开始 baseapp 登录
小结
- 在理清楚协议之后，再看这个登录 loginapp 的过程就比较清楚了
- 主要逻辑：loginapp 在验证用户名、密码之后，通过 baseappmgr 获取可用的 baseapp，在此 baseapp 上注册一下，然后向客户端返回 baseapp 的地址，客户端再直接连接 baseapp（需要通过前面在 baseapp 上的注册信息来验证）
- python 脚本：可以看到，在这个登录过程中，主要是通过 python 脚本暴露了几个接口，以便用户可以介入这个登录流程
- python 脚本的作用当然不限于此，后面会基于 python 脚本构造 Entity，然后基于 Mailbox 和 客户端直接通信，这个在后面会进一步讲解。
