在 muduo 中实现 protobuf 编解码器与消息分发器

陈硕 (giantchen_AT_gmail)

Blog.csdn.net/Solstice  t.sina.com.cn/giantchen

Muduo 全系列文章列表： http://blog.csdn.net/Solstice/category/779646.aspx

本文是《一种自动反射消息类型的 Google Protobuf 网络传输方案》的延续，介绍如何将前文介绍的打包方案与 muduo::net::Buffer 结合，实现了 protobuf codec 和 dispatcher。

Muduo 的下载地址： http://muduo.googlecode.com/files/muduo-0.1.9-alpha.tar.gz ，SHA1 dc0bb5f7becdfc0277fb35f6dfaafee8209213bc ，本文的完整代码可在线阅读 http://code.google.com/p/muduo/source/browse/trunk/examples/protobuf/codec/ 。

考虑到不是每个人都安装了 Google Protobuf，muduo 中的 protobuf 相关示例默认是不 build 的，如果你的机器上安装了 protobuf 2.3.0 或 2.4.0a，那么可以用 ./build.sh protobuf_all 来构建 protobuf 相关的 examples。

 

在介绍 codec 和 dispatcher 之前，先讲讲前文的一个未决问题。

为什么 Protobuf 的默认序列化格式没有包含消息的长度与类型？

Protobuf 是经过深思熟虑的消息打包方案，它的默认序列化格式没有包含消息的长度与类型，自然有其道理。哪些情况下不需要在 protobuf 序列化得到的字节流中包含消息的长度和（或）类型？我能想到的答案有：

• 如果把消息写入文件，一个文件存一个消息，那么序列化结果中不需要包含长度和类型，因为从文件名和文件长度中可以得知消息的类型与长度。
• 如果把消息写入文件，一个文件存多个消息，那么序列化结果中不需要包含类型，因为文件名就代表了消息的类型。
• 如果把消息存入数据库（或者 NoSQL），以 VARBINARY 字段保存，那么序列化结果中不需要包含长度和类型，因为从字段名和字段长度中可以得知消息的类型与长度。
• 如果把消息以 UDP 方式发生给对方，而且对方一个 UDP port 只接收一种消息类型，那么序列化结果中不需要包含长度和类型，因为从 port 和 UDP packet 长度中可以得知消息的类型与长度。
• 如果把消息以 TCP 短连接方式发给对方，而且对方一个 TCP port 只接收一种消息类型，那么序列化结果中不需要包含长度和类型，因为从 port 和 TCP 字节流长度中可以得知消息的类型与长度。
• 如果把消息以 TCP 长连接方式发给对方，但是对方一个 TCP port 只接收一种消息类型，那么序列化结果中不需要包含类型，因为 port 代表了消息的类型。
• 如果采用 RPC 方式通信，那么只需要告诉对方 method name，对方自然能推断出 Request 和 Response 的消息类型，这些可以由 protoc 生成的 RPC stubs 自动搞定。

对于最后一点，比方说 sudoku.proto 定义为：

service SudokuService {
  rpc Solve (SudokuRequest) returns (SudokuResponse);
}

那么 RPC method Sudoku.Solve 对应的请求和响应分别是 SudokuRequest 和 SudokuResponse。在发送 RPC 请求的时候，不需要包含 SudokuRequest 的类型，只需要发送 method name Sudoku.Solve，对方自知道应该按照 SudokuRequest 来解析(parse)请求。这个例子来自我的半成品项目 evproto，见 http://blog.csdn.net/Solstice/archive/2010/04/17/5497699.aspx 。

对于上述这些情况，如果 protobuf 无条件地把长度和类型放到序列化的字节串中，只会浪费网络带宽和存储。可见 protobuf 默认不发送长度和类型是正确的决定。Protobuf 为消息格式的设计树立了典范，哪些该自己搞定，哪些留给外部系统去解决，这些都考虑得很清楚。

只有在使用 TCP 长连接，且在一个连接上传递不止一种消息的情况下（比方同时发 Heartbeat 和 Request