共计 1527 个字符，预计需要花费 4 分钟才能阅读完成。
fooking 是一个分布式游戏网关，次要用于承载长连贯，将客户端的数据包残缺的转发给后端，后端服务解决完之后由 fooking 转发给客户端。
如同听起来有点像 nginx+fpm？嗯！没错，如果是单纯的 request/response，跟 nginx 相似;
但在游戏中经常出现要被动推数据给客户端，而没有 request，比方：A 发消息给 B，B 是没有 request 的，只有 response.
嗯哼？就这些性能？听上也没什么吸引力啊。。
当然不只如此，他包含：
1、分布式网关配置, 只须要简略配置就能动静增加网关, 以提供更多的连贯数量；
2、SESSION 维持，每个连贯会有惟一 sessionid, 后端只须要指定 sessionid 发送音讯即可，不必关怀这个连贯在哪台机器上；
3、组播，N 个用户退出到一组，只须要向组名发送音讯即可，不必关怀这个组有多少人(当然你非要本人去循环 session 发送我也阻止不了你)；
4、服务器状态监控，能够察看到以后有多少组服务器，总共有多少连贯，每台服务器上有多少连贯，哪些闲暇，哪些忙碌；
5、客户端连贯与断开事件告诉；
6、后端无语言限度，遵循 fastcgi 协定即可;
劣势
1、节约硬件，游戏通常刚开区压力比拟大，过段时间人少了就没多少压了，配置多台服务器齐全能够循环开服;
2、后端无痛热更，例如 php-fpm 重启或者是热更代码，客户端齐全没有觉察;
3、开发不便，跟开发 web 一样，只需将要发送的数据间接输入即可(须要增加 Content-Length 用于确定包大小，详见协定阐明)
4、PHP 谬误能在 log 文件里和盘托出, 并且谬误不会对 fooking 有任何影响
架构
fooking 由一个 router 与多个 gateway 组成，所有 gateway 都会去连贯 router, 后端被动推送的音讯由 router 派发给 gateway，而后由 gateway 转发客户端.
request/response 模式下不须要 router 干涉, 仅仅是 gateway 与 backend(php-fpm)通信.
协定
网关为什么会有协定？既然是音讯转发，就必须将一个包残缺的发到后端，而不是让后端来检测包是否残缺；
协定分为两种，一种是前端协定，一种是后端协定
前端协定是指游戏的客户端与 fooking 的交互协定，这个很简略，32 位 int + data(筹备下个版本反对 lua 进行自定义协定).
后端协定是应用 Fastcgi，这就意味着，后端无所谓什么语言，只须要遵循 fastcgi 协定即可，我是 phper, 当然举荐应用 fpm;
注：后端返回的数据必须有 Content-Lengthwww.cungun.com 标识返回数据长度，否则一律视为不返回数据到客户端，
另外数据是由后后向前切取，比方输入内容为 abcdef, 而 Content-Length: 3, 那么客户端会收到 def..
编译
在 fooking 目录下执行 make 即可, 启动须要 cd src
配置
具体的配置请详见 src/config.lua 与 src/router.lua
启动 router
./fooking router.lua
启动 gateway
./fooking config.lua
example
已做了个简略的聊天室，位于 example/chat
应用办法：
1、应用 nginx 或者 apache 将目录指向 example/chat 目录，并批改 index.html 的服务器 IP 与端口(须要拜访 index.html 和 chat.swf)
2、运行 python flash.py(flash 的平安沙箱，因为客户端是应用 flash socket)
3、配置 router.lua 和 config.lua，而后启动 router 和 gateway
4、拜访 localhost/index.html