12.3 gRPC消息协议

Fabric中大量采用了gRPC消息在不同组件之间进行通信交互，主要包括如下几种情况：客户端访问Peer节点，客户端和Peer访问Orderer节点，链码容器跟Peer节点之间，以及多个Peer节点之间的通信。

12.3.1　Envelope消息结构

这些通信消息大多采用了Envelope结构来进行封装。

Envelope消息结构定义在protos/common/common.proto文件中，结构如图12-14所示。

Envelope消息结构并不复杂，包括一个Payload域存放数据，以及Payload域中内容进行签名的Signature域。

图12-14　Envelope消息结构

Payload域中又包括Header域（记录类型、版本、签名者信息等元数据）和Data域（记录消息内容）。

Header域是一个通用的结构。包括两种头部：ChannelHeader和SignatureHeader（主要记录签名者的身份信息）。

ChannelHeader中记录了跟通道和交易相关的很多信息，包括：

·Type：int32类型，代表了结构体（如Envelope）的类型。结构体消息根据类型不同，其Payload 可以解码为不同的结构。类型可以为MESSAGE、CONFIG、CONFIG_UPDATE、ENDORSER_TRANSACTION、 ORDERER_TRANSACTION、DELIVER_SEEK_INFO、CHAINCODE_PACKAGE等；

·Version：int32类型，版本号记录了消息协议的版本，一般为0；

·Timestamp：*google_protobuf.Timestamp类型，消息创建时候的时间；

·ChannelID：string类型，消息所关联的通道ID；

·TxID：string类型，交易的ID，由交易发起者创建；

·Epoch：uint64类型，所属的世代，目前指定为所属区块的高度值；

·Extension：[]byte类型，扩展域。

12.3.2　客户端访问Peer节点

客户端通过SDK和Endorser Peer进行交互，执行包括链码相关操作（安装、实例化、升级链码以及调用），加入、列出应用通道和监听事件操作。

大部分消息都采用了SignedProposal结构（定义在protos/peer/proposal.pb.go文 件），消息中ChannelHeader.Type为ENDORSER_TRANSACTION，并且发往的gRPC服务地址为 /protos.Endorser/ProcessProposal。这些操作消息总结如表12-1所示。

表12-1　操作消息总结

其中，SignedProposal消息结构如图12-15所示。

图12-15　SignedProposal消息结构

SignedProposal消息结构结构中包括Proposal和对其的签名。

Proposal消息结构中同样包括Header域、Payload域，以及扩展域。其中，Payload域和扩展域如何解码都取决于ChainHeader中的Type指定的类型。

以背书过程为例，Endorser Peer返回的消息则为ProposalResponse结构（定义在protos/peer/proposal.pb.go文件），如图12-16所示。

图12-16　ProposalResponse消息结构

ProposalResponse消息结构包括如下数据：

·Version：int32类型，记录消息协议的版本号信息；

·Timestamp*google_protobuf.Timestamp类型，记录消息创建的时间；

·Response：*Response类型，记录背书操作是否成功；

·Payload：[]byte类型，记录背书提案的Hash值等；

·Endorsement：*Endorsement类型，记录背书信息，主要是各背书者对提案的签名信息。

12.3.3　客户端、Peer节点访问Orderer

客户端通过SDK与Orderer进行交互，执行操作如链码实例化、调用和升级，应用通道创建和更新，以及区块结构获取等。

Peer节点可以直接向Orderer请求获取区块结构，两者采用了同样的方法获取接口。请求消息都采用了 Envelope结构，并且都发往/orderer.AtomicBroadcast/BroadcastgRPC服务地址。从Orderer获取信息 时，则发往/orderer.AtomicBroadcast/DelivergRPC服务地址。gRPC消息总结如表12-2所示。

表12-2　客户端访问Orderer的gRPC消息

12.3.4　链码容器和Peer节点之间的操作

链码容器启动后，会向Peer节点进行注册，gRPC地址为/protos.ChaincodeSupport/Register。

消息为ChaincodeMessage结构（定义在protos/peer /chaincode_shim.proto文件），如图12-17所示。其中，Payload域中可以包括各种Chaincode操作消息，如 GetHistoryForKey、GetQuery-Result、PutStateInfo、GetStateByRange等。

图12-17　ChaincodeMessage消息结构

注册完成后，双方建立起双工通道，通过更多消息类型实现多种交互，这将在12.5节予以介绍。

12.3.5　多个节点之间的操作

Peer节点之间可以通过Gossip协议来完成区块分发、状态同步等过程，主要过程为通过GossipClient客 户端的GossipStream双向流进行通信，发送SignedGossipMessage消息结构。相关定义在protos/gossip /message.proto文件中，gRPC服务地址主要为/gossip.Gossip/GossipStream。

此外，通过单独的Ping服务（gRPC服务地址为/gossip.Gossip/Ping）来实现对远端Peer在线状态进行探测。

SignedGossipMessage消息结构如图12-18所示。

图12-18　SignedGossipMessage消息结构

其中，消息Tag可以为EMPTY、ORG_ONLY、CHAN_ONLY、CHAN_AND_ORG、CHAN_OR_ORG等5种。

消息Content可以为如下17种类型，分别适用于不同的场景：

·成员消息：AliveMsg、MemReq、MemRes；

·区块消息：DataMsg；

·推拉消息：Hello、DataDig、DataReq、DataUpdate；

·建立连接消息：Conn；

·空消息：Empty；

·选举消息：LeadershipMsg；

·身份消息：PeerIdentity；

·状态消息：StateInfo、StateInfoPullReq、StateRequest、StateResponse、StateSnapshot。

来源：我是码农，转载请保留出处和链接！

本文链接：http://www.54manong.com/?id=903

'); (window.slotbydup = window.slotbydup || []).push({ id: "u3646208", container: s }); })();

'); (window.slotbydup = window.slotbydup || []).push({ id: "u3646147", container: s }); })();