版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/zay109327402/article/details/53147195
原来的KBE系列不更了，因为我放弃了KBE，所以。。。
关于一个游戏消息服务器的点点滴滴
以及关于程序员的“情怀”
我从Blued离职回重庆已经快一年了，我竟然在家“玩”了一年，期间有不少朋友问我你还好吧你没死吧？
我自己也惊讶，作为一名程序员，我竟然可以在家思考人生思考一年，不出去赚钱！
但是毋庸置疑经过我这么长时间的“领悟”，我终于知道，没钱真难啊~~
我思考什么是情怀，什么是现实
我思考什么是敏锐的洞察力，什么是强硬的执行力
我思考什么是天赋异禀，什么是神工鬼斧
我思考什么是程序员自己人生的控制反转，为什么程序员到了30岁就几乎要面临转行的尴尬境地，这是历史的必然性还是自我认知的不足？
我思考自己为什么对面子上东西这么不在乎而对技术上的瑕疵却锱铢必较，我朋友几次三番地叫我写简历我都草草地改改了事，用我自己的话说叫我懒得去弄那些有的没的，事实上这不就是情怀吗？
我们每个人何曾不期待自己未来的同事、伙伴、上级，认可的是自己这个人，而不是简历上面那些吹牛逼的，浮夸的修辞，也不是认可的那一纸简历，或者那些可有可无的经历？
可是情怀永远只能在梦里的，能为你的情怀买单的人估计自己也是个杯具的，能将情怀变现的，必须是循规蹈矩的踏实、安全和信任，这是我这几个月领悟出来的。
我给乔老板做了一个产品，自己一个人从前端到后台到消息服务器全在做，后来发现自己好累，于是叫石杰跟我一起做，可是我不图乔老板什么，甚至在答应乔老板的时候，我还怀揣着自己的情怀梦~就是因为我俩关系好，所以我帮你做了呗，不赚你钱
但是我发现我身边的所有每一个认识我的人都很现实地活着，或高贵或卑微地，然后我发现我是不是该醒醒了？该从我那个情怀梦里面走出来，进入到正常人的逻辑轨道了
我给乔老板做棋牌项目之前写过单机游戏，而我答应他之初也最担心的是，我不知道怎样处理服务器《-》客户端的双向通信问题，因为我以前所有的经验在两个逻辑之中：
1.如果是应用的功能模块，我们用HTTP和推送即可(APNS和安卓的那啥我不太清楚)，HTTP正常情况来说(严谨点我还是得打个括号你懂的)是单工的，用来客户端主动向后台拉数据，发数据
2.如果是聊天模块，我们一般用专门的IM方案，不管是XMPP也好，websocket也好，以及一大块的应用层协议架在socket之上。逼死了我的逻辑。
我们一般都是把即时通信和应用的界限划分的很清晰和明确，如果你的程序只是要获取数据，那就HTTP好了，你要即时通信？那好，加入IM模块吧。好像没有中间选项的。
但是当我真正开始分析如何做到在游戏里面服务器控制客户端行之有效的手段之后，我开始明白我需要把这之间的界限慢慢地模糊，我开始明白我需要把WEB的逻辑慢慢转移到我曾经划分的IM的那个领域去。至于Socket还是RPC都无所谓，重要的是这个界限在模糊，在我从一个应用开发者向游戏开发者的角色过渡的过程中，自然而然地发生，又是那么的必然。
更加让我费解的是，因为我曾经在Blued的经历告诉我，如果聊天只是游戏里面的附加模块，那么我们必须用少量的经历去处理他，因为他的体验给用户是附加的。否则会增加我特别多的开发量，让我陷入到里面去，毕竟以前在Blued，我们就是专门做聊天，而且只做聊天呀。
这里不得不提到我这几个月一直在玩的一个游戏，天天打波利，这个游戏就是奇葩到自称是自带小游戏的聊天软件！
你如果花时间去增加用户在聊天上的体验，那么在自己总共有限的精力上，你在用在游戏本身的精力就不够用了，我曾经这么想的。所以我打算直接用现成的IM产品集成进去
但是一切的一切好像都不是那么简单，游戏领域似乎对聊天和其他功能逻辑的划分是没有的！比如用户发送/接受文本消息和发送/接受游戏数据是可以在一个后台逻辑里面完成的~也可以理解说文本消息本来就是一种特殊的消息，而所有联网游戏基本上都有即时性的要求，因此基本上所有的游戏逻辑都在即时通信的大框架之中，因此以前在web那边的业务逻辑不得不跟着“搬”到即时通信这个大框架之下！
欧买膏的，原来网络游戏就是一个大型的社交软件啊，哈哈哈哈，难道不是吗？
我们以前总是想着刷新朋友圈/发朋友圈的逻辑和收发文本的消息是两个东西，没有交集的，可是呢？在联网的游戏中，你给一个用户发送文本消息包，然后将消息发送给目标用户，目标用户接收之后返回ack包给服务器，然后服务器 返回ack给你告 知你消息已送达； 和你发送一个朋友圈的包，服务器插入数据然后返回成功的ack，当你关注的朋友有新的朋友圈的时候服务器直接发送新朋友圈内容的包，你接收到之后返回一个ack，这两种逻辑不是就是可以同属于一个逻辑么？
当我尝试KBEinge，尝试Websocket，尝试PNS。。。 我跟乔老板说，我至少有20种办法做到服务器主动发送消息给客户端，而行之有效的方法，我计划中的快速完成的办法我没有找到，但是乔老板只关心结果呀，结果是他们都不行，不管是本身的不足，还是与UNITY的兼容性方面，都各有各的问题。
于是当我第一个星期每天都在写大量的逻辑，而第二个星期开始尝试解决这个服务器向客户端推消息的时候，我停滞不前，我的进度为0,，而这个阶段的进度就是这样啊，不是1，就是0 ，每一个方案都在尝试，成功了就是100%，失败了就是0%，因为我选错了路，因为我自己给自己设置了认知上的障碍。
就是那道我认为业务逻辑应该永远属于WEB服务器管控，不应该和IM混淆的界限，给我的心灵设置了认知上的障碍。我认为业务逻辑和IM的界限是神圣的，这道鸿沟是无法跨越的，于是我花费了一个星期，每天乔老板问我，我都说没进展。
这是多么简单呀，拆掉我自己给自己设置的路障，不就好了吗，业务逻辑在WEB层还是IM这边，无所谓的~所以我写了一个游戏消息服务器，它不光用来处理游戏指令，用户传统的操作逻辑，还处理聊天消息，不就是这样么？
于是我制定了自己的一个协议，并且打算从今天起开始维护这个协议，因为游戏端是UNITY 的c#脚本，所以服务端我选择了c#的wpf，这样我只需要把我协议里面规定的各种包在一个端写好，复制到另外一个端就行，两边都认识这个包了。于是有了连接包，认证包，注册包，PING包，PONG包，系统推送包，文本消息包，出牌包，摸牌包，结算包以及对应的ACK包…………
每个包的前面4个字节写一个int32表示这个包的类型，然后socket每次先读4个字节，判断出是什么包，然后用KVC类似的东西（http://msgpack.org/），把后面的1020个字节解析成对应的对象(我的buffer只设置了1024字节)
所有包都继承自一个基类，拆/解包的逻辑写在基类中然后新的包直接继承，完事啦~
接下来就是消息队列的逻辑了，消息的接受者要么是单一用户，要么是一组用户，分别是P2P模型和PubSub模型，单一用户的消息需要ACK，群组消息的ACK可有可无，且生成就发送，且永远不会进入消息队列。。。这样又把我以前的逻辑给串联了起来
总之这个消息服务器就是我上个星期的最后2天写出来的一个玩意。把我的以前的逻辑体系和新领悟到的，拆除了自我认知障碍的逻辑体系，串联了起来，运行一下.exe，点击一下开始，OK~游戏服务器启动啦~~
我打算开源，但是我还没有给他起名字。如果有人需要这个玩意，那就开源好了。
总之我的目的达到了，接下来的事情就是，好好维护好这个协议吧~
我自己也惊讶，作为一名程序员，我竟然可以在家思考人生思考一年，不出去赚钱！
但是毋庸置疑经过我这么长时间的“领悟”，我终于知道，没钱真难啊~~
我思考什么是情怀，什么是现实
我思考什么是敏锐的洞察力，什么是强硬的执行力
我思考什么是天赋异禀，什么是神工鬼斧
我思考什么是程序员自己人生的控制反转，为什么程序员到了30岁就几乎要面临转行的尴尬境地，这是历史的必然性还是自我认知的不足？
我思考自己为什么对面子上东西这么不在乎而对技术上的瑕疵却锱铢必较，我朋友几次三番地叫我写简历我都草草地改改了事，用我自己的话说叫我懒得去弄那些有的没的，事实上这不就是情怀吗？
我们每个人何曾不期待自己未来的同事、伙伴、上级，认可的是自己这个人，而不是简历上面那些吹牛逼的，浮夸的修辞，也不是认可的那一纸简历，或者那些可有可无的经历？
可是情怀永远只能在梦里的，能为你的情怀买单的人估计自己也是个杯具的，能将情怀变现的，必须是循规蹈矩的踏实、安全和信任，这是我这几个月领悟出来的。
我给乔老板做了一个产品，自己一个人从前端到后台到消息服务器全在做，后来发现自己好累，于是叫石杰跟我一起做，可是我不图乔老板什么，甚至在答应乔老板的时候，我还怀揣着自己的情怀梦~就是因为我俩关系好，所以我帮你做了呗，不赚你钱
但是我发现我身边的所有每一个认识我的人都很现实地活着，或高贵或卑微地，然后我发现我是不是该醒醒了？该从我那个情怀梦里面走出来，进入到正常人的逻辑轨道了
我给乔老板做棋牌项目之前写过单机游戏，而我答应他之初也最担心的是，我不知道怎样处理服务器《-》客户端的双向通信问题，因为我以前所有的经验在两个逻辑之中：
1.如果是应用的功能模块，我们用HTTP和推送即可(APNS和安卓的那啥我不太清楚)，HTTP正常情况来说(严谨点我还是得打个括号你懂的)是单工的，用来客户端主动向后台拉数据，发数据
2.如果是聊天模块，我们一般用专门的IM方案，不管是XMPP也好，websocket也好，以及一大块的应用层协议架在socket之上。逼死了我的逻辑。
我们一般都是把即时通信和应用的界限划分的很清晰和明确，如果你的程序只是要获取数据，那就HTTP好了，你要即时通信？那好，加入IM模块吧。好像没有中间选项的。
但是当我真正开始分析如何做到在游戏里面服务器控制客户端行之有效的手段之后，我开始明白我需要把这之间的界限慢慢地模糊，我开始明白我需要把WEB的逻辑慢慢转移到我曾经划分的IM的那个领域去。至于Socket还是RPC都无所谓，重要的是这个界限在模糊，在我从一个应用开发者向游戏开发者的角色过渡的过程中，自然而然地发生，又是那么的必然。
更加让我费解的是，因为我曾经在Blued的经历告诉我，如果聊天只是游戏里面的附加模块，那么我们必须用少量的经历去处理他，因为他的体验给用户是附加的。否则会增加我特别多的开发量，让我陷入到里面去，毕竟以前在Blued，我们就是专门做聊天，而且只做聊天呀。
这里不得不提到我这几个月一直在玩的一个游戏，天天打波利，这个游戏就是奇葩到自称是自带小游戏的聊天软件！
你如果花时间去增加用户在聊天上的体验，那么在自己总共有限的精力上，你在用在游戏本身的精力就不够用了，我曾经这么想的。所以我打算直接用现成的IM产品集成进去
但是一切的一切好像都不是那么简单，游戏领域似乎对聊天和其他功能逻辑的划分是没有的！比如用户发送/接受文本消息和发送/接受游戏数据是可以在一个后台逻辑里面完成的~也可以理解说文本消息本来就是一种特殊的消息，而所有联网游戏基本上都有即时性的要求，因此基本上所有的游戏逻辑都在即时通信的大框架之中，因此以前在web那边的业务逻辑不得不跟着“搬”到即时通信这个大框架之下！
欧买膏的，原来网络游戏就是一个大型的社交软件啊，哈哈哈哈，难道不是吗？
我们以前总是想着刷新朋友圈/发朋友圈的逻辑和收发文本的消息是两个东西，没有交集的，可是呢？在联网的游戏中，你给一个用户发送文本消息包，然后将消息发送给目标用户，目标用户接收之后返回ack包给服务器，然后服务器 返回ack给你告 知你消息已送达； 和你发送一个朋友圈的包，服务器插入数据然后返回成功的ack，当你关注的朋友有新的朋友圈的时候服务器直接发送新朋友圈内容的包，你接收到之后返回一个ack，这两种逻辑不是就是可以同属于一个逻辑么？
当我尝试KBEinge，尝试Websocket，尝试PNS。。。 我跟乔老板说，我至少有20种办法做到服务器主动发送消息给客户端，而行之有效的方法，我计划中的快速完成的办法我没有找到，但是乔老板只关心结果呀，结果是他们都不行，不管是本身的不足，还是与UNITY的兼容性方面，都各有各的问题。
于是当我第一个星期每天都在写大量的逻辑，而第二个星期开始尝试解决这个服务器向客户端推消息的时候，我停滞不前，我的进度为0,，而这个阶段的进度就是这样啊，不是1，就是0 ，每一个方案都在尝试，成功了就是100%，失败了就是0%，因为我选错了路，因为我自己给自己设置了认知上的障碍。
就是那道我认为业务逻辑应该永远属于WEB服务器管控，不应该和IM混淆的界限，给我的心灵设置了认知上的障碍。我认为业务逻辑和IM的界限是神圣的，这道鸿沟是无法跨越的，于是我花费了一个星期，每天乔老板问我，我都说没进展。
这是多么简单呀，拆掉我自己给自己设置的路障，不就好了吗，业务逻辑在WEB层还是IM这边，无所谓的~所以我写了一个游戏消息服务器，它不光用来处理游戏指令，用户传统的操作逻辑，还处理聊天消息，不就是这样么？
于是我制定了自己的一个协议，并且打算从今天起开始维护这个协议，因为游戏端是UNITY 的c#脚本，所以服务端我选择了c#的wpf，这样我只需要把我协议里面规定的各种包在一个端写好，复制到另外一个端就行，两边都认识这个包了。于是有了连接包，认证包，注册包，PING包，PONG包，系统推送包，文本消息包，出牌包，摸牌包，结算包以及对应的ACK包…………
每个包的前面4个字节写一个int32表示这个包的类型，然后socket每次先读4个字节，判断出是什么包，然后用KVC类似的东西（http://msgpack.org/），把后面的1020个字节解析成对应的对象(我的buffer只设置了1024字节)
所有包都继承自一个基类，拆/解包的逻辑写在基类中然后新的包直接继承，完事啦~
接下来就是消息队列的逻辑了，消息的接受者要么是单一用户，要么是一组用户，分别是P2P模型和PubSub模型，单一用户的消息需要ACK，群组消息的ACK可有可无，且生成就发送，且永远不会进入消息队列。。。这样又把我以前的逻辑给串联了起来
总之这个消息服务器就是我上个星期的最后2天写出来的一个玩意。把我的以前的逻辑体系和新领悟到的，拆除了自我认知障碍的逻辑体系，串联了起来，运行一下.exe，点击一下开始，OK~游戏服务器启动啦~~
我打算开源，但是我还没有给他起名字。如果有人需要这个玩意，那就开源好了。
总之我的目的达到了，接下来的事情就是，好好维护好这个协议吧~
发几个图片，有了这个协议之后自己跟自己打牌（目前只有摸牌，出牌/等待，结算的逻辑，至于你出的牌是否合法，石杰还没写好呢，这个掌握了全世界最先进的python热更新技术的小伙子竟然在跟我写牌型校验的逻辑~）
