《炉石传说》架构设计赏析(7):使用Google.ProtocolBuffers处理网络消息

这段时间琢磨了一下Unity3D网络游戏开发中的网络消息处理。网络游戏的服务端一般都是自主开发的,所以对应的网络消息处理也要自己开发。客户端/服务端之间的消息传到目前使用JSON和Google.ProtocolBuffers是两种常见的做法。打开炉石的代码看了看它的处理方式,感觉代码写的还是很好的,把它的思路分析一下,与大家分享。

整体机制描述

我们想要达到的目标大概是这样的:

  • 有N个网络消息,每个消息对应一个Proto中的message描述;
  • 每个消息对应一个数字ID;
  • 底层在收到消息是,将其解析成为Google.ProtocolBuffers.IMessage对象,这个对象的具体类型应该是前面那个message生成的代码;
  • 发送消息就简单了,因为知道其类型,可以直接执行序列化;

炉石使用Google.ProtocolBuffers类库,可以看这里:http://www.nuget.org/packages/Google.ProtocolBuffers/

消息发送

发送的机制很简单,首先使用ProtocolBuffer生成的message类构造一个消息对象,例如:ConnectAPI.SendPing()

public static void SendPing()
{
    Ping.Builder body = Ping.CreateBuilder();
    QueueGamePacket(0x73, body);
    s_lastGameServerPacketSentTime = DateTime.Now;
}

底层会构造一个“PegasusPacket”数据包对象,添加到发送队列之中,这个数据包对象主要包含3部分:消息ID,消息大小,具体消息数据。详见PegasusPacket.Encode()函数:

public override byte[] Encode()
{
    if (!(this.Body is IMessageLite))
    {
        return null;
    }
    IMessageLite body = (IMessageLite) this.Body;
    this.Size = body.SerializedSize;
    byte[] destinationArray = new byte[8 + this.Size];
    Array.Copy(BitConverter.GetBytes(this.Type), 0, destinationArray, 0, 4);
    Array.Copy(BitConverter.GetBytes(this.Size), 0, destinationArray, 4, 4);
    body.WriteTo(CodedOutputStream.CreateInstance(destinationArray, 8, this.Size));
    return destinationArray;
}

消息接收与解析

接下来我们重点看一下消息的接收与解析机制。首先因为TCP是流式的,所以底层应该检测数据包头,并收集到一个完整的数据包,然后再发送到上层解析,这部分逻辑是在”ClientConnection<PacketType>.BytesReceived()“中实现的。当收到完整数据包时,会在主线程中触发”OnPacketCompleted“事件,实际上会调用到”ConnectAPI.PacketReceived()“,其内部主要是调用了”ConnectAPI.QueuePacketReceived()“,这个函数负责将TCP层接收到的byte[]解析成对应的IMessage对象。

重点来了!由于网络层发过来的数据包,只包含一个消息ID,那么客户端就需要解决从ID找到相应的消息Type的问题。想象中无非有两种方式去做:1是手动记录每个ID对应的Type;2是搞一个中间的对应关系的类,附加上自定义的Attribute,然后在使用反射机制自动收集这些类,其实和前者也差不多。炉石采用了第一种方式。整体机制是这样的:

  • 客户端每个消息对应一个PacketDecoder的派生类对象;
  • ConnectAPI类使用一个字典,用来保存<消息ID,Decoder对象>之间的对应关系:ConnectAPI.s_packetDecoders:SortedDictionary<Int32,ConnectAPI.PacketDecoder>;
  • 如果每个消息都要写一个Decoder,而其内部代码由完全一致,岂不是很蛋疼?!好吧,我们用模板来实现,详见后续分析;
  • 在ConnectAPI.ConnectInit()初始化的时候,创建Decoder对象,并保存到上述dict之中,类似这样:

    s_packetDecoders.Add(0x74, new DefaultProtobufPacketDecoder<Pong, Pong.Builder>());

  • 最后在上述的收到完整数据包的函数中,根据数据包中记录的消息ID,去查找Decoder,然后调用其方法得到具体的消息对象,类似这样:
        if (s_packetDecoders.TryGetValue(packet.Type, out decoder))
        {
            PegasusPacket item = decoder.HandlePacket(packet);
            if (item != null)
            {
                queue.Enqueue(item);
            }
        }
        else
        {
            Debug.LogError("Could not find a packet decoder for a packet of type " + packet.Type);
        }

最后我们看一下,Decoder模板的实现技巧。首先消息解析的具体操作是有Google.ProtocolBuffers生成的代码去实现的,所以具体操作流程是完全一致的,这些写到基类的的静态模板函数中:

public abstract class PacketDecoder
{
    // Methods
    public abstract PegasusPacket HandlePacket(PegasusPacket p);
    public static PegasusPacket HandleProtoBuf<TMessage, TBuilder>(PegasusPacket p) where TMessage: IMessageLite<TMessage, TBuilder> where TBuilder: IBuilderLite<TMessage, TBuilder>, new()
    {
        byte[] body = (byte[]) p.Body;
        TBuilder local2 = default(TBuilder);
        TBuilder local = (local2 == null) ? Activator.CreateInstance<TBuilder>() : default(TBuilder);
        p.Body = local.MergeFrom(body).Build();
        return p;
    }
}

其次,使用一个模板派生类,实现HandlePacket()这个虚函数,主要的目的只是把TMessage和TBuilder这两个类型传给那个静态函数而已:

public class DefaultProtobufPacketDecoder<TMessage, TBuilder> : ConnectAPI.PacketDecoder where TMessage: IMessageLite<TMessage, TBuilder> where TBuilder: IBuilderLite<TMessage, TBuilder>, new()
{
    // Methods
    public override PegasusPacket HandlePacket(PegasusPacket p)
    {
        return ConnectAPI.PacketDecoder.HandleProtoBuf<TMessage, TBuilder>(p);
    }
}

OK,炉石是使用使用ProtocolBuffers来处理网络消息的机制就是这样,是不是已经很清晰啦!

时间: 2024-10-11 07:12:00

《炉石传说》架构设计赏析(7):使用Google.ProtocolBuffers处理网络消息的相关文章

炉石传说 C# 设计文档(序)

经过3个月的开发,有很多感触. 以前一直以为技术是开发成败的第一因素,现在发现,等到你代码写的时间够长,经验够丰富,什么功能都能随手完成,对于业务的分析能力变成了第一位. 炉石山寨版的BS版本用到的HTML5的SVG,我看了一个下午的教程,借鉴以前GUI+和HTML的经验,很快就能写点东西出来了. WebSocket,Github上找了一个开源的C#项目,通讯这块也是几个小时就搞定了.Javascript不是很熟悉,当时闭包这样的一些概念也算听说过,Js也是无障碍就写成了. 整个项目的技术壁垒其

《炉石传说》架构设计赏析(4):Asset管理

欢迎转载,请注明作者[燕良@游戏开发]及原文地址:http://blog.csdn.net/neil3d/article/details/39580197 另外,欢迎大家来我的QQ群交流各种游戏引擎相关的技术:游戏引擎能吃吗(264656505) 话说,经过这段时间的学习和摸索,对于Unity3D的开发思路已经基本清晰了.唯独还剩下一个AssetBundle机制还没有搞透,这个涉及到前期项目的资源规划.资源管理代码的写法,以及自动更新机制的实现. 所以,还是想先把游戏逻辑的进一步分析押后,先来看

《炉石传说》架构设计赏析(1):游戏启动流程

前些天看新闻,Unity Awards两项大奖颁给了暴雪的<炉石传说>,这真是对Unity一个再好不过的宣传了--你看,暴雪都开始用Unity了.大家都知道,目前Unity发布的游戏大多都没有对程序集进行混淆.加密,所以作为一个炉石的玩家&Unity的初学者,自然不能错过这个机会.让我们好好看一下暴雪的代码吧. 炉石传说的游戏内容的非常丰富多彩,所以我花了一些时间分析了其程序集,将一些设计思路记录下来,与大家分析.欢迎各路高手拍砖,欢迎转载,请注明出处:燕良@游戏开发,http://b

《炉石传说》架构设计赏析(6):卡牌&amp;技能数据的运行时组织

前一篇文章我们看到了<炉石传说>的核心卡牌数据的存储,今天我们继续探索卡牌&技能. 主要的类 通过之前的分析,卡牌&技能涉及到几个类体系:Entity,Actor,Card,Spell,令人十分困惑,特别是前两者.在这里先略带武断的说一下这几个类的基本定位: Entity主要用来做网络数据同步用的: Actor主要处理客户端的渲染对象的控制,作为Component挂载在资源对象上: Spell是技能Prefab挂载的脚本: Card是卡牌Prefab挂载的脚本,在运行时处于中心

《炉石传说》架构设计赏析(3):Gameplay初探

经过前面两篇文章的分析,我们对炉石的代码已经不陌生了,接下来我初步尝试分析其游戏逻辑代码. 欢迎转载,请注明作者[燕良@游戏开发]及原文地址:http://blog.csdn.net/neil3d/article/details/39453291 经过前面的分析,我们已经找到了两个关键的类Gameplay和GameState(当然还有我最感兴趣的Spell和SpellController,这两个还要在后面分析). 首先我们看一下Gameplay这个类的Awake方法,它完成的主要工作是: 调用"

《炉石传说》架构设计赏析(2):Scene管理

上篇文章我们分析到SceneMgr处理了Scene的加载工作,今天我们主要分析一下炉石这款游戏中一共有哪些Scene,他们各自负责什么,以及它内部的逻辑.UI的处理方式. 在正式开始之前,我来对前文中提到的Scene切换再做一些补充分析.前文中我们看到SceneMgr是调用了" Application.LoadLevelAdditiveAsync(this.sceneName);",那内存中的东西岂不是越搞越多吗?我们再仔细看一下SceneMgr:SwitchMode()函数,它是一个

《炉石传说》架构设计赏析(5):卡牌&amp;技能的静态数据组织

经过前面几次的尝试,我们对炉石的代码已经不陌生了.除了网络机制还没有了解以外,本机的逻辑已经比较熟悉了. 接下来继续向暴雪最NB的技能系统进发,我们的目标是: 分析技能的静态数据描述: 分析技能的运行时数据.逻辑组织: 这篇笔记主要记录对其分析静态数据. 静态数据组织 卡牌数据 卡牌的基本数据对于的AssetFamily为:AssetFamily.CardXML: 数据对于的资源包为"cardxml0.unity3d": 资源包中的资源类型为:TextAsset: 资源加载使用的接口为

架构设计:系统间通信(27)——其他消息中间件及场景应用(上)

1.概述 目前业界有很多消息中间件可供大家选择,主要分为两类:需要付费的商业软件和开源共享的非商业软件.对于商业软件您和您的团队可以选择IBM WebSphere集成的MQ功能,也可以选择Oracle WebLogic集成的MQ功能.本文首先介绍除Apache ActiveMQ以外的两款开源共享的消息中间件产品,然后列举三个实际的业务常见,为读者介绍如何在这些实际业务中使用消息中间件解决问题. 2.RabbitMQ及特性 RabbitMQ基于Erlang语言开发和运行.它与Apache Acti

炉石传说 C# 开发笔记(6月底小结)

炉石传说的开发,已经有30个工作日了. 关于法术的定义方法,有过一次重大的变更:法术效果是整个炉石的核心,正是因为丰富的法术效果,才造就了炉石的可玩性. 原来构思的时候,对于法术效果没有充分的理解,所以只将效果数据做成了常数,例如 造成5点伤害. 随着更加深入的解除,发现还有 毁掉你的武器,对所有随从造成武器攻击力的伤害,这样的话,效果是一个 表达式. 然后考虑到,有些追加效果,例如,对某个随从造成2点伤害,如果这个随从没有死,则抽一张牌, 这里就牵涉到了根据条件追加效果的处理. 同时,德鲁伊的