caffe 源码导读(一)了解protobuf

Protocol Buffers 是一种轻便高效的结构化数据存储格式,可以用于结构化数据串行化,或者说序列化。它很适合做数据存储或 RPC 数据交换格式。可用于通讯协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式。目前提供了 C++、Java、Python 三种语言的 API,具体介绍网上也有很多详解,下面直接记录一下自己的笔记,方便以后复习。

首先建立一个lm.helloworld.proto文件

package lm;   // 开始建一个proto文件文件名一般按照 packageName.MessageName.proto(标准命名方法)
message helloworld   // message是消息定义的关键字,等同于C++中的struct/class,或是Java中的class
{   
required int32     id = 1;  // ID   
required string    str = 2;  // str   
optional int32     opt = 3;  //optional field
}
// required前缀表示该字段为必要字段,既在序列化和反序列化之前该字段必须已经被赋值。
//与此同时,在Protocol Buffer中还存在另外两个类似的关键字
//optional repeated,带有这两种限定符的消息字段则没有required字段这样的限制。
//相比于optional,repeated主要用于表示数组字段在Protocol Buffer中还存在另外两个类似的关键字
//optional repeated,带有这两种限定符的消息字段则没有required字段这样的限制。相比于optional,repeated主要用于表示数组字段


建立好这个文件后,该生成相关的文件了,执行下面demo.sh文件

protoc -I=/home/hjxu/caffe_orc_study/protobuff_day1 --cpp_out=/home/hjxu/caffe_orc_study/protobuff_day1 /home/hjxu/caffe_orc_study/protobuff_day1/lm.helloworld.proto  

#第一个参数是指待编译的文件存放在-I=路径的子目录下,第二个参数--cpp_out生成的目标语言是c文件,并放到指定的路径中,第三个参数是proto原始文件
#下面这个例子选自https://www.cnblogs.com/stephen-liu74/archive/2013/01/06/2842972.html
# protoc -I=./message --java_out=./src ./MyMessage.proto
#      从上面的命令行参数中可以看出,待编译的文件为MyMessage.proto,他存放在当前目录的message子目录下。
# --java_out参数则指示编译工具我们需要生成目标语##言是java,输出目录是当前目录的src子目录。
# 这里需要补充说明的是,因为在MyMessage.proto文件中定义了option java_package = "com.lsk.lyphone"的文件级选##项,
# 所以输出的目前是src/com/lsk/# lyphone,生成的目标代码文件名是MyMessage.java。

这时候可以在--cpp_out下看到两个文件,分别是lm.helloworld.pb.cc和lm.helloworld.pb.h文件,接下来就是编写

接下来就是编写writer.cc和reader.cc

writer.cc:

  1. #include "lm.helloworld.pb.h"    
  2. #include <fstream>    
  3. #include <iostream>    
  4. using namespace std;    
  5.     
  6. int main(void)     
  7. {     
  8.     
  9.     lm::helloworld msg1;     
  10.     msg1.set_id(101);     
  11.     msg1.set_str("hello");     
  12.     fstream output("./write_log", ios::out | ios::trunc | ios::binary);     
  13.     
  14.     if (!msg1.SerializeToOstream(&output)) {     
  15.         cerr << "Failed to write msg." << endl;     
  16.         return -1;     
  17.     }            
  18.     return 0;     
  19. }    
reader.cc:
  1.     #include "lm.helloworld.pb.h"    
  2.     #include <fstream>    
  3.     #include <iostream>    
  4.     using namespace std;    
  5.         
  6.     void ListMsg(const lm::helloworld & msg) {      
  7.         cout << msg.id() << endl;     
  8.         cout << msg.str() << endl;     
  9.     }     
  10.         
  11.     int main(int argc, char* argv[]) {     
  12.         
  13.         lm::helloworld msg1;     
  14.         
  15.         {     
  16.             fstream input("./write_log", ios::in | ios::binary);     
  17.             if (!msg1.ParseFromIstream(&input)) {     
  18.                 cerr << "Failed to parse address book." << endl;     
  19.                 return -1;     
  20.             }           
  21.         }     
  22.         ListMsg(msg1);  
  23.         fstream out("./reader_log",ios::out);   
  24.         if(out.is_open())  
  25.         {  
  26.         out << msg1.id()<<endl;     
  27.         out << msg1.str()<<endl;  
  28.         out.close();  
  29.         }  
  30.  }   

这两个文件已经写好了。

运行以下命令:

  1. $ cd /home/lb/pratice/protobuf  
  2. $ g++  lm.helloworld.pb.cc writer.cc -o writer  `pkg-config --cflags --libs protobuf` -lpthread  
  3. $ ./writer  
  4. $ g++  lm.helloworld.pb.cc reader.cc -o reader  `pkg-config --cflags --libs protobuf` -lpthread  
  5. $ ./reader  
就会输出:
  1. 101  
  2. hello 

下面是百度文库里的介绍,写的非常详细,转自

https://wenku.baidu.com/view/a99d7005caaedd3383c4d386.html

一、使用protocol的好处

方 使用SOAP协议(WebService)作为消息报文的格式载体,

由该方式生成的报文是基于文本格式的,同时还存在大量的XML

描述信息,因此将会大大增加网络IO的负担。又由于XML解析的

复杂性,这也会大幅降低报文解析的性能。总之,使用该设式将会使系统的整体运行性能明显下降。

二、protocol的定义格式

1.每个方法的关键字为message 类似于Java中的class

eg:

message LogonReqMessage {

required int64 acctID = 1;

required string passwd = 2;

}

2. int64和string分别表示长整型和字符串型的消息字段,在Protocol Buffer中存在一张类型对照表,既Protocol Buffer

中的数据类型与其他编程语言(C++/Java)中所用类型的对照。该对照表中还将给出在不同的数据场景下,哪种类型更为高效。

该对照表将在后面给出。

3. acctID和passwd分别表示消息字段名,等同于Java中的域变量名,或是C++中的成员变量名。

4.标签数字1和2则表示不同的字段在序列化后的二进制数据中的布局位置。在该例中,passwd字段编码后的数据一定位于acctID之后。

需要注意的是该值在同一message中不能重复。另外,对于Protocol Buffer而言,标签值为1到15的字段在编码时可以得到优化,既标

签值和类型信息仅占有一个byte,标签范围是16到2047的将占有两个bytes,而Protocol Buffer可以支持的字段数量则为2的29次方减一。有鉴于此,我们在设计消息结构时,可以尽可能考虑让repeated类型的字段标签位于1到15之间,这样便可以有效的节省编码后的字节

数量。

5. required前缀表示该字段为必要字段,既在序列化和反序列化之前该字段必须已经被赋值。与此同时,在Protocol Buffer中还存在另外两个类似的关键字,optional和repeated,带有这两种限定符的消息字段则没有required字段这样的限制。相比于optional,repeated主要用于表示数组字段。具体的使用方式在后面的用例中均会一一列出。

三、定义第二个(含有枚举字段)Protocol Buffer消息。

//在定义Protocol Buffer的消息时,可以使用和C++/Java代码同样的方式添加注释。

enum UserStatus {

OFFLINE = 0; //表示处于离线状态的用户

ONLINE = 1; //表示处于在线状态的用户

}

message UserInfo {

required int64 acctID = 1;

required string name = 2;

required UserStatus status = 3;

}

这里将给出以上消息定义的关键性说明(仅包括上一小节中没有描述的)。

1. enum是枚举类型定义的关键字,等同于C++/Java中的enum。

2. UserStatus为枚举的名字。

3. 和C++/Java中

的枚举不同的是,枚举值之间的分隔符是分号,而不是逗号。

4. OFFLINE/ONLINE为枚举值。

5. 0和1表示枚举值所对应的实际整型值,和C/C++一样,可以为枚举值指定任意整型值,而无需总是从0开始定义。如:

enum OperationCode {

LOGON_REQ_CODE = 101;

LOGOUT_REQ_CODE = 102;

RETRIEVE_BUDDIES_REQ_CODE = 103;

LOGON_RESP_CODE = 1001;

LOGOUT_RESP_CODE = 1002;

RETRIEVE_BUDDIES_RESP_CODE = 1003;

}

eg:

enum OperationCode {

LOGON_REQ_CODE = 101;

LOGOUT_REQ_CODE = 102;

RETRIEVE_BUDDIES_REQ_CODE = 103;

LOGON_RESP_CODE = 1001;

LOGOUT_RESP_CODE = 1002;

RETRIEVE_BUDDIES_RESP_CODE = 1003;

}


  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值