赞 | 400 |
VIP | 0 |
好人卡 | 24 |
积分 | 250 |
经验 | 45372 |
最后登录 | 2024-7-2 |
在线时间 | 3339 小时 |
Lv5.捕梦者 (版主)
- 梦石
- 1
- 星屑
- 23994
- 在线时间
- 3339 小时
- 注册时间
- 2011-7-8
- 帖子
- 3926
|
加入我们,或者,欢迎回来。
您需要 登录 才可以下载或查看,没有帐号?注册会员
x
本帖最后由 guoxiaomi 于 2017-5-29 16:52 编辑
最近为了实现VX的聊天功能,在SAE上搭建了HTTP服务器。大致说一下自己的构思吧:
1. 服务端部署用标准环境,租金 10 云豆 / 天,GIT 方式管理代码。但是SAE支持代码直接上传和在线编辑,所以就算不会用 GIT 也没有关系。
2. 客户端用了 6R 上不死鸟之翼的HTTP并发和英顺的马甲的免DLL输入法,细心的人应该能发现我在这两个帖子下面都留了言。
3. 客户端有 2 个操作: update 和 upload ,前者的参数是 $chat_index ,服务端收到后会返回最新的聊天记录。后者的参数是聊天信息,服务端收到后会提取参数里的内容,生成聊天记录保存下来,返回一个 done。
4. 服务端要用到 SAE 自带的这些功能:Memcached,KVDB,Storage。因为要用到 Memcached,所以每天有 3云豆的租金。从而每月纯挂机有 400 云豆的开销,也就是 4 块钱。
这些功能的介绍还是看看文档吧。简单的说,Memcached的数据是以 key-value 对的形式存储在内存里,而且有销毁时间;KVDB的数据是以 key-value 对的形式存在硬盘里;Storage的数据是以文件形式存在硬盘里,相比与KVDB,读取速度更慢,但是可以通过 FTP 直接管理。
服务端逻辑:
1. 首先在 KVDB 里保存一个变量 $chat_index,标记着当前聊天总数。这个也缓存在 Memcached 里方便读取。然后保存一个数组 $chat_ary,用来储存聊天信息。
2. 客户端上传聊天信息 $data 的时候,读取 $chat_index 并加一, 然后把聊天信息更新到 KVDB 里。 $chat_ary[$chat_index] = $data。
3. 客户端上传 update 信息的时候,比较数据里的 $chat_index 和 KVDB 里的 $chat_index,如果前者比较小比如是 9,而后者是 12,则从服务端返回 10,11,12 的聊天信息,以及新的 $chat_index = 12。
4. 当服务端的 $chat_index = 1000 的时候,将 KVDB 里的数组 $chat_ary 存储到 Storage 里,并且使 $chat_index = 0。
5. 对 3 的补充,如果比较数据里的 $chat_index 和 KVDB 里的 $chat_index,发现前者比后者还要大,比如前者是 120,后者是 12。说明客户端的 $chat_index 已经过期了,从服务端返回 0-12 的聊天记录。
简单的说就是这样,但是更多的问题比如,缓存优化、数据加密、身份验证、保存用户信息,这些暂时就不提了。
上面说的我已经做好了,暂时不把服务端代码、工程发上来,原因是我不太想直接就发布了,想听听各位的看法,比如要不要设置权限,或者开收费主题。还有一个原因是我不愿意把全部的代码拱手相让,毕竟研究这些花了不少时间。简单的聊天功能不仅仅是聊天,比如交易系统,本质上也是聊天。不过6月份一定会给出工程+服务端代码的~
关于网络,懂的人不细说,不懂的人喜欢瞎想,我发布这些东西出来,也是为了寻找有兴趣的人一同优化基于HTTP的适合RMXP/VX/VA的网络脚本。其实也没啥好优化的,主要是想找个程序员把免DLL输入法的bug解决了,以及把加密解密的函数写进 DLL 以提升速度。
选择用HTTP而不是 socket IP直连也是有原因的,论坛上网络化的帖子我全看过一遍,有一篇提过,RM系统做不了实时对战,因为不光网络有延迟,本地受到 Graphics.update 的影响,也有一个不小的延迟,所以数据是不可能“实时”处理的。所以索性不做实时的处理,如果只是做聊天、交易功能,或者是卡牌游戏等这些对延迟要求不高的应用,选择 HTTP 是合适的,而且成本比起租一个 VPS 要便宜得多。当然这只是我一个人的想法,因为我也没有租过 VPS,也不知道一个月多少钱。 |
|