我的Protobuf消息设计原则(续)--实践

1.首先为 聊天服务器(Chat)定义google protobuf的协议接口文件

接口主要遵循 Request、Response、Notification(Indication),Command(本文未出现)四大消息分类,并且使用Message顶层消息把Request、Response,Notification等包含起来;并定义一个MSG枚举值,用于表示具体的消息值(在google protobuf RPC过程中,其实 每个service方法就是一个Request和Response的应答对,只不过其消息值的编码是RPC自动分配的)

package chat; //定义protobuf的包名称空间,对应C++,C#的nanmespace,Java的package
enum MSG
{
 Login_Request  = 10001;
 Login_Response  = 10002;
 Logout_Request  = 10003;
 Logout_Response  = 10004;
 Keepalive_Request = 10005;
 Keepalive_Response = 10006;
 Get_Friends_Request = 10007;
 Get_Friends_Response = 10008;
 Send_Message_Request = 10009;
 Send_Message_Response = 10010;
 Friend_Notification = 20001;
 Message_Notification = 20002;
 Welcome_Notification = 20003;
}
/下面定义具体的消息内容,MSG枚举中的每个消息ID,如果有消息体,则会对应一个message 定义,如果无消息体则不必要/
/Login_Request 消息ID对应的消息名称为LoginRequest ; 规则为取掉下划线,有利于某些自动化编码工具编写自动化代码/
message LoginRequest
{
 required bytes username = 1;
 optional string password = 2;
}
message LoginResponse
{
 required fixed32 ttl = 1;
}
/没有对应的MSG id,则为其它 消息的字段,作为子消息,可以消息嵌套定义,也可以放在外面,个人习惯放在外部。/
message Friend
{
 required bytes name  = 1;
 optional bool  online = 2;
}
message GetFriendsResponse
{
 repeated Friend  friends  = 1;
}
message SendMessageRequest
{
 optional bytes receiver = 1;
 required bytes  text  = 2;
}
message FriendNotification
{
 required bytes name  = 1;
 optional bool online = 2;
}
message MessageNotification
{
 required bytes sender = 1;
 required bytes text = 2;
 required string timestamp = 3;
}
message WelcomeNotification
{
 required  bytes text = 1;
}
/请求消息集合,把所有的 XxxxxRequest消息全部集合在一起,使用起来类似于C语言的联合体,全部使用optional字段,任何时刻根据MSG 的id值,最多只有一个有效性, 从程序的逻辑上去保证,编译器(不管是protoc还是具体语言的编译器都无法保证)/
message Request
{
 optional LoginRequest login = 1;
 optional SendMessageRequest send_message = 2;
}
/与Request作用相同,把所有的XxxxResponse消息集合在一起,当作联合体使用,不过额外多了几个字段用于表示应答的结果/
message Response
{
 required bool result = 1;  //true表示应答成功,false表示应答失败
 required bool last_response = 2;// 一个请求可以包含多个应答,用于指示是否为最后一个应答
 optional bytes error_describe = 3;// result == false时,用于描述错误信息
 optional LoginResponse login = 4;
 optional GetFriendsResponse get_friends = 5;
}
/与Request相同,把所有的XxxxxNotification消息集合在一起当作联合体使用./
message Notification
{
 optional FriendNotification friend = 1;
 optional MessageNotification msg = 2;
 optional WelcomeNotification welcome = 3;
}
/顶层消息,包含所有的Request,Response,Notification,具体包含哪个消息又 MSG msg_type字段决定,程序逻辑去保证msg_type和具体的消息进行匹配/
message Message
{
 required MSG  msg_type = 1;
 required fixed32 sequence = 2;//消息系列号,主要用于Request和Response,Response的值必须和Request相同,使得发送端可以进行事务匹配处理
 optional fixed32 session_id = 3;
 optional Request request  = 4;
 optional Response response = 5;
 optional Notification notification = 6;
}

2.工程实例

服务器和客户端均使用C#语言开发,主要是考虑到Net集成的网络框架使用起来比较方面,做实例工程比较快;

google protobuf官方的第三方支持库下载protobuf的NET版本

具体工程文件可以从此下载: http://download.csdn.net/detail/chenxiaohong3905/7654087

通信模式采用TCP,在protobuf的二进制基础上追加了 4个字节的包头,用于表示protobuf 二进制数据的长度(不包含4字节自身)

  1. wireshard 抓包分析

普通的wireshark版本是不支持protobuf抓包解析的,可以下载http://download.csdn.net/detail/chenxiaohong3905/7244655 版本(需要10 CSDN积分,后面要取消,无法取消积分,上传新的文件也没资格了)

安装完下载的版本后需要对齐进行配置 在wireshark安装目录下有个protobuf的文件夹用于存放所有 要解析的protobuf文件和配置;

注意事项: 每一个端口只能对应一个顶层消息 ,至于为何每个端口只能有一个顶层消息可以去cnblog参考陈硕的文章,里面关于protobuf的描述已经解释了这个问题; protobuf 文件可以包含其它protobuf接口文件,会自动加载,配置的时候只需要指定顶层消息所在的proto文件即可;

里面vcs.conf是一个配置实例

对于 聊天服务器的配置可以如下:

把 protocol.proto文件复制为 wireshark/protobuf文件夹下面,并穿件一个 文件 protocol.conf 输入一下内容即可

# same config file for parsing Message messages

name                  = Message

proto_file            = protocol.proto

port                  = 39999

name 为顶层消息的名称, port为源或目标的端口之一,不管是TCP,UDP都会尝试解析;如果port端口有其它协议优先注册了,则无法解析为protobuf,需要手动解析;

3.1 连接建立 , 服务器推送 Welcome_Notification消息到客户端

此流程非必须,只不过为抓包而演示

GoogleProtocolBuffer , Length 59 描述了 Message 消息二进制的总长度

3.2 登录聊天服务器

3.3. 获取朋友列表

简单的推送服务器的所有已经登录的用户,包含当前用户

3.4 用户通知

当用户登录或者注销时通过其它用户

3.5 发送消息与消息推送

只演示发送广播消息,所有用户都会接收到包含自己

3.6 注销

时间: 2024-11-03 15:16:10

我的Protobuf消息设计原则(续)--实践的相关文章

如何实践设计原则

大家都知道遵循设计原则是开发高质量软件的重要基础,但实际运用时并不容易.Booch在<<面向对象分析与设计>>中提出了四个基础原则: 抽象   核心思想是不变性的概念.去除不关心的属性,而强化重要的属性,帮助人们思考要做什么. 封装  核心是分离关注和信息隐藏,让程序借助最少的工作进行可靠的修改. 模块化  核心思想是分而治之,各个模块应当高内聚.低耦合. 层次结构  核心是对抽象的分级和排序,可以简化对系统的理解. 这些概念看起都比较容易理解,但实际运用并不简单.所以<&l

连载:面向对象葵花宝典:思想、技巧与实践(39) - 设计原则 vs 设计模式

又是设计原则,又是设计模式,到底该用哪个呢? ============================================================================= 在"设计模型"一章中,我们提到设计原则和设计模式是互补的,设计原则和设计模式互补体现在:设计原则主要用于指导"类的定义"的设计,而设计模式主要用于指导"类的行为"的设计.   举一个很简单的例子:假设我们要设计一个图形类Shape,这个类既支持三角

交互设计原则&#8211;待续

我们认为目标导向设计方法由4个P组成,即process.pattern.principles.practices(过程.模式.原则.实践),下面我将和大家一起讨论前3个P.交互设计总的来说是一件困难杂乱的工作,交互设计师常常被要求在紧迫的工期中想象和定义一个可能要运用最新科技,并且是谁都没见过的东西,我们必须深刻地了解产品所属的复杂的领域,必须平衡好竞争的优先次序,必须理解所用科技的约束和机会,还要对整个项目的商业环境有清楚的认识.这些让人眩晕的困难和挑战迫使我们必须要采用非常系统的方法,通过需

Android界面与交互设计原则:以用户为中心

译者按: 在iOS HIG已经强大经典了N年之后,Android终于推出了一套比较系统的HIG(大概是为了配合Android 4.0 Ice Cream Sandwich).仔细比较两套HIG的"设计原则"部分,发现完全是截然不同的两种风格.iOS HIG走的是更专业型的路线,描述严谨且有不少的专业词汇(比如Metaphors.Consistency之类的).而Android则显得亲民许多,不仅描述方式简要易懂,配图鲜明直观,甚至还用了"me"作为了一系列要点的标题

微服务的4大设计原则和19个解决方案

作者|郝炎峰 编辑|小智 本文将介绍微服务架构的演进.优缺点和微服务应用的设计原则,然后着重介绍作为一个"微服务应用平台"需要提供哪些能力.解决哪些问题才能更好的支撑企业应用架构. 注:本文转载自公众号 EAWorld,已获授权. 写在前面 微服务架构现在是谈到企业应用架构时必聊的话题,微服务之所以火热也是因为相对之前的应用开发方式有很多优点,如更灵活.更能适应现在需求快速变更的大环境. 微服务平台也是我目前正在参与的,还在研发过程中的平台产品,平台是以 SpringCloud 为基础

微服务的4个设计原则和19个解决方案

微服务架构现在是谈到企业应用架构时必聊的话题,微服务之所以火热也是因为相对之前的应用开发方式有很多优点,如更灵活.更能适应现在需求快速变更的大环境. 本文将介绍微服务架构的演进.优缺点和微服务应用的设计原则,然后着重介绍作为一个"微服务应用平台"需要提供哪些能力.解决哪些问题才能更好的支撑企业应用架构. 微服务平台也是我目前正在参与的,还在研发过程中的平台产品,平台是以SpringCloud为基础,结合了普元多年来对企业应用的理解和产品的设计经验,逐步孵化的一个微服务应用平台. 一.微

交互设计经验谈:移动应用交互设计原则

文章描述:设计在很多时候都是靠灵感的闪现,移动应用的设计则更加的灵活多变,如何能更好地设计出一个应用,没有具体的方法和成规.但是,为了能更好地避免设计师们走弯路,设计原则的学习是有必要的,它给了设计师们一定的参考和指导. 摘要:交互设计专业也有了蓬勃发展,Ben Shneiderman 提出的交互设计"黄金八法"和Nielsen 的"启发式评估10条原则"为交互设计的评估提供了标准.我们在考虑其他原则的基础上,整理了八条移动应用设计的针对性原则. 本文节选自<

用户体验设计原则:安卓用户体验团队制定的设计原则

文章描述:Android界面与交互设计原则. 译者按: 在iOS HIG已经强大经典了N年之后,Android终于推出了一套比较系统的HIG(大概是为了配合Android 4.0 Ice Cream Sandwich).仔细比较两套HIG的"设计原则"部分,发现完全是截然不同的两种风格.iOS HIG走的是更专业型的路线,描述严谨且有不少的专业词汇(比如Metaphors.Consistency之类的).而Android则显得亲民许多,不仅描述方式简要易懂,配图鲜明直观,甚至还用了&q

GOOGLE用户体验设计师谈Google的十大设计原则

在一次讲座上,Jon Wiley--Google的"用户体验设计师"(User Experience Designer)--提到了Google的十大设计原则. 1. 有用(Useful):以用户为焦点,关注他们的生活.工作和梦想. 2. 快速(Fast):争取节省每一个毫秒. 3. 简单(Simple):简洁就是力量. 4. 魅力(Engaging):能够唤起新手的好奇心,能够吸引资深用户. 5. 革新(Innovative):勇于创新. 6. 通用(Universal):全世界适用的