Hyperledger Fabric从源码分析事件机制（二）

最新推荐文章于 2024-02-08 11:41:33 发布
最新推荐文章于 2024-02-08 11:41:33 发布
阅读量983 收藏 2
点赞数 1
分类专栏： Fabric1.4学习 文章标签： 区块链
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/lvyibin890/article/details/107069063
版权

上篇文章——Hyperledger Fabric从源码分析事件机制（一），我从 cmd 中添加--waitForEvent参数去监听事件这一入口出发，分析了DeliverClient这一侧的相关源代码，接下来这篇文章将会解析DeliverServer这一侧的相关源代码，准备好上车了兄弟们。

从proto文件中发现DeliverServer

事件相关的pb.go文件在protos/peer/events.pb.go中，关于DeliverServer的部分在576行：

// DeliverServer is the server API for Deliver service.
type DeliverServer interface {
	// deliver first requires an Envelope of type ab.DELIVER_SEEK_INFO with
	// Payload data as a marshaled orderer.SeekInfo message,
	// then a stream of block replies is received
	Deliver(Deliver_DeliverServer) error
	// deliver first requires an Envelope of type ab.DELIVER_SEEK_INFO with
	// Payload data as a marshaled orderer.SeekInfo message,
	// then a stream of **filtered** block replies is received
	DeliverFiltered(Deliver_DeliverFilteredServer) error
}

// 通过这个函数注册DeliverServer
func RegisterDeliverServer(s *grpc.Server, srv DeliverServer) {
	s.RegisterService(&_Deliver_serviceDesc, srv)
}

// Deliver流的Handler
func _Deliver_Deliver_Handler(srv interface{}, stream grpc.ServerStream) error {
	return srv.(DeliverServer).Deliver(&deliverDeliverServer{stream})
}

type Deliver_DeliverServer interface {
	Send(*DeliverResponse) error
	Recv() (*common.Envelope, error)
	grpc.ServerStream
}

type deliverDeliverServer struct {
	grpc.ServerStream
}

func (x *deliverDeliverServer) Send(m *DeliverResponse) error {
	return x.ServerStream.SendMsg(m)
}

func (x *deliverDeliverServer) Recv() (*common.Envelope, error) {
	m := new(common.Envelope)
	if err := x.ServerStream.RecvMsg(m); err != nil {
		return nil, err
	}
	return m, nil
}

// DeliverFiltered流的Handler
func _Deliver_DeliverFiltered_Handler(srv interface{}, stream grpc.ServerStream) error {
	return srv.(DeliverServer).DeliverFiltered(&deliverDeliverFilteredServer{stream})
}

type Deliver_DeliverFilteredServer interface {
	Send(*DeliverResponse) error
	Recv() (*common.Envelope, error)
	grpc.ServerStream
}

type deliverDeliverFilteredServer struct {
	grpc.ServerStream
}

func (x *deliverDeliverFilteredServer) Send(m *DeliverResponse) error {
	return x.ServerStream.SendMsg(m)
}

func (x *deliverDeliverFilteredServer) Recv() (*common.Envelope, error) {
	m := new(common.Envelope)
	if err := x.ServerStream.RecvMsg(m); err != nil {
		return nil, err
	}
	return m, nil
}

// grpc服务对象
var _Deliver_serviceDesc = grpc.ServiceDesc{
	ServiceName: "protos.Deliver",
	HandlerType: (*DeliverServer)(nil),
	Methods:     []grpc.MethodDesc{},
	Streams: []grpc.StreamDesc{
		{
			StreamName:    "Deliver",
			Handler:       _Deliver_Deliver_Handler,
			ServerStreams: true,
			ClientStreams: true,
		},
		{
			StreamName:    "DeliverFiltered",
			Handler:       _Deliver_DeliverFiltered_Handler,
			ServerStreams: true,
			ClientStreams: true,
		},
	},
	Metadata: "peer/events.proto",
}

peer 节点启动时注册 DeliverServer

看看RegisterDeliverServer()这个方法在哪被调用了

abServer := peer.NewDeliverEventsServer(mutualTLS, policyCheckerProvider, &peer.DeliverChainManager{}, metricsProvider)
pb.RegisterDeliverServer(peerServer.Server(), abServer)

上述代码在peer/node/start.go的274行。

因此破案了，在peer节点启动的时候，启动了DeliverServer。其中主要是abServer这个对象实现了DeliverServer的相关接口，那么来看下NewDeliverEventsServer这个方法吧，生成了一个DeliverEventsServer对象，在core/peer/deliverevents.go的132行：

// NewDeliverEventsServer creates a peer.Deliver server to deliver block and
// filtered block events
func NewDeliverEventsServer(mutualTLS bool, policyCheckerProvider PolicyCheckerProvider, chainManager deliver.ChainManager, metricsProvider metrics.Provider) peer.DeliverServer {
  // mutualTLS是TLS相关的一些东西
  // policyCheckerProvider主要是做ACL的一些检测，暂时不关心
  // chainManager传进来的是一个空的DeliverChainManager对象
  // metricsProvider是指标相关的东西
	timeWindow := viper.GetDuration("peer.authentication.timewindow")
	if timeWindow == 0 {
		defaultTimeWindow := 15 * time.Minute
		logger.Warningf("`peer.authentication.timewindow` not set; defaulting to %s", defaultTimeWindow)
		timeWindow = defaultTimeWindow
	}
	metrics := deliver.NewMetrics(metricsProvider)
  // 最终返回的是一个server对象
	return &server{
    // NewHandler创建了一个deliver.Handler对象
		dh:                    deliver.NewHandler(chainManager, timeWindow, mutualTLS, metrics, false),
		policyCheckerProvider: policyCheckerProvider,
	}
}

这个server对象最终实现了Deliver和DeliverFiltered接口，实现了DeliverServer。

DeliverFiltered接口的实现

上篇文章中说到，cmd 最终建立的是DeliverFiltered流，因此最终会走到server的 DeliverFiltered方法，看下这个方法的实现，在core/peer/deliverevents.go的101行：

// Deliver sends a stream of blocks to a client after commitment
func (s *server) DeliverFiltered(srv peer.Deliver_DeliverFilteredServer) error {
	logger.Debugf("Starting new DeliverFiltered handler")
	defer dumpStacktraceOnPanic()
	// getting policy checker based on resources.Event_FilteredBlock resource name
	deliverServer := &deliver.Server{
		Receiver:      srv,
		PolicyChecker: s.policyCheckerProvider(resources.Event_FilteredBlock),
		ResponseSender: &filteredBlockResponseSender{
			Deliver_DeliverFilteredServer: srv,
		},
	}
  // 执行Handle方法处理
	return s.dh.Handle(srv.Context(), deliverServer)
}

Handle() 方法

最终执行的是Handle()方法，看一下，在common/deliver/deliver.go的152行：

// Handle receives incoming deliver requests.
func (h *Handler) Handle(ctx context.Context, srv *Server) error {
	addr := util.ExtractRemoteAddress(ctx)
	logger.Debugf("Starting new deliver loop for %s", addr)
  // 指标相关
	h.Metrics.StreamsOpened.Add(1)
	defer h.Metrics.StreamsClosed.Add(1)
  // 死循环从客户端获取消息
	for {
		logger.Debugf("Attempting to read seek info message from %s", addr)
		envelope, err := srv.Recv()
		if err == io.EOF {
			logger.Debugf("Received EOF from %s, hangup", addr)
			return nil
		}
		if err != nil {
			logger.Warningf("Error reading from %s: %s", addr, err)
			return err
		}
		
    // 主要的执行函数deliverBlocks
		status, err := h.deliverBlocks(ctx, srv, envelope)
		if err != nil {
			return err
		}
		
    // 响应statusResponse
		err = srv.SendStatusResponse(status)
		if status != cb.Status_SUCCESS {
			return err
		}
		if err != nil {
			logger.Warningf("Error sending to %s: %s", addr, err)
			return err
		}
		
    // 等待新的SeekInfo信息
		logger.Debugf("Waiting for new SeekInfo from %s", addr)
	}
}

deliverBlocks() 方法

主要逻辑都在deliverBlocks()中，在common/deliver/deliver.go的194行：

func (h *Handler) deliverBlocks(ctx context.Context, srv *Server, envelope *cb.Envelope) (status cb.Status, err error) {
	addr := util.ExtractRemoteAddress(ctx)
  // 获取消息的payload，出错就返回Status_BAD_REQUEST状态
	payload, err := utils.UnmarshalPayload(envelope.Payload)
	if err != nil {
		logger.Warningf("Received an envelope from %s with no payload: %s", addr, err)
		return cb.Status_BAD_REQUEST, nil
	}
	
  // 如果payload.Header为空就返回Status_BAD_REQUEST状态
	if payload.Header == nil {
		logger.Warningf("Malformed envelope received from %s with bad header", addr)
		return cb.Status_BAD_REQUEST, nil
	}
	
  // 获取channelHeader，出错就返回Status_BAD_REQUEST状态
	chdr, err := utils.UnmarshalChannelHeader(payload.Header.ChannelHeader)
	if err != nil {
		logger.Warningf("Failed to unmarshal channel header from %s: %s", addr, err)
		return cb.Status_BAD_REQUEST, nil
	}
  // 验证ChannelHeader，出错就返回Status_BAD_REQUEST状态
  err = h.validateChannelHeader(ctx, chdr)
	if err != nil {
		logger.Warningf("Rejecting deliver for %s due to envelope validation error: %s", addr, err)
		return cb.Status_BAD_REQUEST, nil
	}
  
  // 获取通道信息，也就是链信息，这块不展开了
  chain := h.ChainManager.GetChain(chdr.ChannelId)
	if chain == nil {
		// 通道找不到，就返回Status_NOT_FOUND状态
		logger.Debugf("Rejecting deliver for %s because channel %s not found", addr, chdr.ChannelId)
		return cb.Status_NOT_FOUND, nil
	}
  
  labels := []string{
		"channel", chdr.ChannelId,
    // 这里filtered为true
		"filtered", strconv.FormatBool(isFiltered(srv)),
	}
  // 指标相关
  h.Metrics.RequestsReceived.With(labels...).Add(1)
	defer func() {
		labels := append(labels, "success", strconv.FormatBool(status == cb.Status_SUCCESS))
		h.Metrics.RequestsCompleted.With(labels...).Add(1)
	}()
  
  // 获取SeekInfo，出错就返回Status_BAD_REQUEST状态
  seekInfo := &ab.SeekInfo{}
	if err = proto.Unmarshal(payload.Data, seekInfo); err != nil {
		logger.Warningf("[channel: %s] Received a signed deliver request from %s with malformed seekInfo payload: %s", chdr.ChannelId, addr, err)
		return cb.Status_BAD_REQUEST, nil
	}
  
  erroredChan := chain.Errored()
	if seekInfo.ErrorResponse == ab.SeekInfo_BEST_EFFORT {
		// 在SeekInfo_BEST_EFFORT时（表示尽力而为），设置erroredChan = nil
    // 这样下面就会走default分支，也就是什么都不做
		erroredChan = nil
	}
	select {
	case <-erroredChan:
    // 如果出错，返回Status_SERVICE_UNAVAILABLE状态
		logger.Warningf("[channel: %s] Rejecting deliver request for %s because of consenter error", chdr.ChannelId, addr)
		return cb.Status_SERVICE_UNAVAILABLE, nil
	default:
	}
  
  // 创建一个SessionAccessControl对象，出错就返回Status_BAD_REQUEST状态
  accessControl, err := NewSessionAC(chain, envelope, srv.PolicyChecker, chdr.ChannelId, h.ExpirationCheckFunc)
	if err != nil {
		logger.Warningf("[channel: %s] failed to create access control object due to %s", chdr.ChannelId, err)
		return cb.Status_BAD_REQUEST, nil
	}
  
  // 评估ACL（访问控制权限）相关的一些东西
  // 如果没有权限，就会返回Status_FORBIDDEN状态
  if err := accessControl.Evaluate(); err != nil {
		logger.Warningf("[channel: %s] Client authorization revoked for deliver request from %s: %s", chdr.ChannelId, addr, err)
		return cb.Status_FORBIDDEN, nil
	}
  
  // 如果seekInfo的Start或者是Stop为nil，返回Status_BAD_REQUEST状态
  if seekInfo.Start == nil || seekInfo.Stop == nil {
		logger.Warningf("[channel: %s] Received seekInfo message from %s with missing start or stop %v, %v", chdr.ChannelId, addr, seekInfo.Start, seekInfo.Stop)
		return cb.Status_BAD_REQUEST, nil
	}
  
  logger.Debugf("[channel: %s] Received seekInfo (%p) %v from %s", chdr.ChannelId, seekInfo, seekInfo, addr)
	
  // 这里应该是获取通道账本的迭代器，用来迭代访问区块
  // 迭代器从seekInfo.Start开始，number为起始块号
  // 这块逻辑跟账本有关，就不展开了
	cursor, number := chain.Reader().Iterator(seekInfo.Start)
	defer cursor.Close()
  
  var stopNum uint64
  // 判断seekInfo.Stop的类型
	switch stop := seekInfo.Stop.Type.(type) {
	case *ab.SeekPosition_Oldest:
    // 如果seekInfo.Stop的类型是SeekPosition_Oldest
    // 那就就将stopNum设置为迭代器迭代的起始块号
		stopNum = number
	case *ab.SeekPosition_Newest:
		// 如果seekInfo.Stop的类型是SeekPosition_Start
    // 如果seekInfo.Start的类型也是SeekPosition_Start，那就就将stopNum设置为迭代器迭代的起始块号
    // 否则，stopNum设置为当前账本高度-1
    // 注意需要-1，否则可能会返回多个块，可能预期的只是一个块
		if proto.Equal(seekInfo.Start, seekInfo.Stop) {
			stopNum = number
			break
		}
		stopNum = chain.Reader().Height() - 1
	case *ab.SeekPosition_Specified:
    // 如果seekInfo.Stop的类型是SeekPosition_Specified
    // 那么就将stopNum设置为指定的number
    // 如果指定的stopnum比迭代器起始块的高度还要小，那么就报错
		stopNum = stop.Specified.Number
		if stopNum < number {
			logger.Warningf("[channel: %s] Received invalid seekInfo message from %s: start number %d greater than stop number %d", chdr.ChannelId, addr, number, stopNum)
			return cb.Status_BAD_REQUEST, nil
		}
	}
  
  // 死循环
  for {
    // 如果seekInfo.Behavior是SeekInfo_FAIL_IF_NOT_READY
    // 表示如果块没有准备好久返回错误
		if seekInfo.Behavior == ab.SeekInfo_FAIL_IF_NOT_READY {
			if number > chain.Reader().Height()-1 {
        // 如果当前迭代起始块大于当前区块高度-1，表示找不到，返回Status_NOT_FOUND状态
				return cb.Status_NOT_FOUND, nil
			}
		}
		
    // 定义两个变量
		var block *cb.Block
		var status cb.Status
		
    // 迭代结束通道，发送迭代完成通知
		iterCh := make(chan struct{})
		go func() {
      // 不停的迭代，调用next
			block, status = cursor.Next()
			close(iterCh)
		}()

		select {
		case <-ctx.Done():
      // 表示在区块取回之间上下午退出了，返回Status_INTERNAL_SERVER_ERROR状态
			logger.Debugf("Context canceled, aborting wait for next block")
			return cb.Status_INTERNAL_SERVER_ERROR, errors.Wrapf(ctx.Err(), "context finished before block retrieved")
		case <-erroredChan:
      // TODO, today, the only user of the errorChan is the orderer consensus implementations.  If the peer ever reports
			// this error, we will need to update this error message, possibly finding a way to signal what error text to return.
			// 这块看不太懂这个erroredChan啥意思，好像是共识有关的，给排序节点用的，返回Status_SERVICE_UNAVAILABLE状态
			logger.Warningf("Aborting deliver for request because the backing consensus implementation indicates an error")
			return cb.Status_SERVICE_UNAVAILABLE, nil
		case <-iterCh:
			// Iterator has set the block and status vars
      // 到这表示迭代完了
		}

		if status != cb.Status_SUCCESS {
      // 迭代完status不为Status_SUCCESS则返回对应的status
			logger.Errorf("[channel: %s] Error reading from channel, cause was: %v", chdr.ChannelId, status)
			return status, nil
		}

		// increment block number to support FAIL_IF_NOT_READY deliver behavior
    // 这个值++为下一个循环开始的判断做准备
    // 因为number++以后，number > chain.Reader().Height()-1应该就会成立了
    // 这个时候FAIL_IF_NOT_READY 的行为会返回
		number++
		
    // 继续再评估一下ACL
		if err := accessControl.Evaluate(); err != nil {
			logger.Warningf("[channel: %s] Client authorization revoked for deliver request from %s: %s", chdr.ChannelId, addr, err)
			return cb.Status_FORBIDDEN, nil
		}

		logger.Debugf("[channel: %s] Delivering block [%d] for (%p) for %s", chdr.ChannelId, block.Header.Number, seekInfo, addr)
		
    // 将这次迭代拿到的区块返回，发送失败返回Status_INTERNAL_SERVER_ERROR状态
		if err := srv.SendBlockResponse(block); err != nil {
			logger.Warningf("[channel: %s] Error sending to %s: %s", chdr.ChannelId, addr, err)
			return cb.Status_INTERNAL_SERVER_ERROR, err
		}
		
    //指标设置
		h.Metrics.BlocksSent.With(labels...).Add(1)
		
    //如果block的区块好和stopnum一样，那就要停止了
    //所以一般如果要无限循环的话，stopnum一般就设置为math.MaxInt64了
    //这一点在上一篇文章中提到过
		if stopNum == block.Header.Number {
			break
		}
	}
	
	logger.Debugf("[channel: %s] Done delivering to %s for (%p)", chdr.ChannelId, addr, seekInfo)
	
  // 完成之后还是要返回一个Status_SUCCESS状态
	return cb.Status_SUCCESS, nil
}

代码很长，不过好在没有很多需要跳转的地方。需要注意的一个地方是，发送消息给DeliverClient的时候，只有两种响应类型：

// ResponseSender defines the interface a handler must implement to send
// responses.
type ResponseSender interface {
	SendStatusResponse(status cb.Status) error
	SendBlockResponse(block *cb.Block) error
}

一般拿到一个区块的时候，就会执行SendBlockResponse()，最终返回的响应类型是DeliverResponse_FilteredBlock。在返回一个status时，包括各种错误，或是Status_SUCCESS，都会执行SendStatusResponse()，最终返回的响应类型是DeliverResponse_Status。返回status就代表DeliverServer这边的逻辑处理结束了，需要通知DeliverClient，DeliverClient具体怎么处理就看各自实现了。

通过SendBlockResponse() 发送响应

最后看下SendBlockResponse()方法，它是最终返回一个事件响应的方法，代码在core/peer/deliverevents.go的79行：

type blockEvent common.Block

// SendBlockResponse generates deliver response with block message
func (fbrs *filteredBlockResponseSender) SendBlockResponse(block *common.Block) error {
   // blockEvent主要就是用了另一个类型要包装一下commmon.block类型
  // 以便可以自定义一个toFilteredBlock方法
   b := blockEvent(*block)
  // 这块主要就是过滤区块了
   filteredBlock, err := b.toFilteredBlock()
   if err != nil {
      logger.Warningf("Failed to generate filtered block due to: %s", err)
     // 出错调用SendStatusResponse返回错误状态
      return fbrs.SendStatusResponse(common.Status_BAD_REQUEST)
   }
  // 创建响应类型DeliverResponse，type是DeliverResponse_FilteredBlock
   response := &peer.DeliverResponse{
      Type: &peer.DeliverResponse_FilteredBlock{FilteredBlock: filteredBlock},
   }
   return fbrs.Send(response)
}

toFilteredBlock() 方法过滤区块

来看下toFilteredBlock()方法，在core/peer/deliverevents.go的157行：

func (block *blockEvent) toFilteredBlock() (*peer.FilteredBlock, error) {
  // 创建要返回的FilteredBlock对象，赋值Number字段为区块高度
	filteredBlock := &peer.FilteredBlock{
		Number: block.Header.Number,
	}
	
  // 拿到区块元数据中的common.BlockMetadataIndex_TRANSACTIONS_FILTER部分的内容，
  // TxValidationFlags是一个[]uint8类型，这里是做了一个类型转化
	txsFltr := util.TxValidationFlags(block.Metadata.Metadata[common.BlockMetadataIndex_TRANSACTIONS_FILTER])
  // block.Data.Data就是每条交易数据
  // txIndex是下标，ebytes是一个[]byte类型，是Envelope类型的序列化内容
	for txIndex, ebytes := range block.Data.Data {
		var env *common.Envelope
		var err error
		
    // 当前交易为空，continue
		if ebytes == nil {
			logger.Debugf("got nil data bytes for tx index %d, "+
				"block num %d", txIndex, block.Header.Number)
			continue
		}
		
    // 获取env对象
		env, err = utils.GetEnvelopeFromBlock(ebytes)
		if err != nil {
			logger.Errorf("error getting tx from block, %s", err)
			continue
		}

		// 获取env的payload，这里出错直接返回，而不是continue
		payload, err := utils.GetPayload(env)
		if err != nil {
			return nil, errors.WithMessage(err, "could not extract payload from envelope")
		}
		
    // payload.Header为空continue
		if payload.Header == nil {
			logger.Debugf("transaction payload header is nil, %d, block num %d",
				txIndex, block.Header.Number)
			continue
		}
    // 获取channelHeader
		chdr, err := utils.UnmarshalChannelHeader(payload.Header.ChannelHeader)
		if err != nil {
			return nil, err
		}
		
    // 设置filteredBlock的ChannelID
		filteredBlock.ChannelId = chdr.ChannelId
		
    // 创建FilteredTransaction对象
    // 包括交易ID，头部类型，以及交易验证码（这个东西还不太懂）
		filteredTransaction := &peer.FilteredTransaction{
			Txid:             chdr.TxId,
			Type:             common.HeaderType(chdr.Type),
			TxValidationCode: txsFltr.Flag(txIndex),
		}
		
    // 如果交易类型是HeaderType_ENDORSER_TRANSACTION
		if filteredTransaction.Type == common.HeaderType_ENDORSER_TRANSACTION {
      // 那么就获取交易的具体数据，得到peer.Transaction对象tx
			tx, err := utils.GetTransaction(payload.Data)
			if err != nil {
				return nil, errors.WithMessage(err, "error unmarshal transaction payload for block event")
			}
			
      // 将tx.Actions（类型为[]*TransactionAction）转化为transactionActions类型（是[]*TransactionAction的别名）
      // 本质上是拿到Actions，事件就存储在交易的Acitons字段中
      // 来看下toFilteredActions方法，过滤事件去了
			filteredTransaction.Data, err = transactionActions(tx.Actions).toFilteredActions()
			if err != nil {
				logger.Errorf(err.Error())
				return nil, err
			}
		}
		
    // 设置filteredBlock的FilteredTransactions字段
		filteredBlock.FilteredTransactions = append(filteredBlock.FilteredTransactions, filteredTransaction)
	}
	
  // 最终返回filteredBlock
	return filteredBlock, nil
}

toFilteredActions() 过滤事件信息

看下toFilteredActions()方法，在core/peer/deliverevents.go的222行：

type FilteredTransactionActions struct {
	ChaincodeActions     []*FilteredChaincodeAction 
	XXX_NoUnkeyedLiteral struct{}                   
	XXX_unrecognized     []byte                     
	XXX_sizecache        int32                      
}

type FilteredChaincodeAction struct {
  // ChaincodeEvent就是链码事件结构体，这个在之前的文章中有提到
	ChaincodeEvent       *ChaincodeEvent 
	XXX_NoUnkeyedLiteral struct{}        
	XXX_unrecognized     []byte          
	XXX_sizecache        int32           
}

func (ta transactionActions) toFilteredActions() (*peer.FilteredTransaction_TransactionActions, error) {
  // 创建一个FilteredTransactionActions对象
	transactionActions := &peer.FilteredTransactionActions{}
  // 本质上就是遍历交易的Actions字段,每个action是Action类型
	for _, action := range ta {
    // 获取action的payload字段
		chaincodeActionPayload, err := utils.GetChaincodeActionPayload(action.Payload)
		if err != nil {
			return nil, errors.WithMessage(err, "error unmarshal transaction action payload for block event")
		}
		
    // chaincodeActionPayload.Action为空跳过
		if chaincodeActionPayload.Action == nil {
			logger.Debugf("chaincode action, the payload action is nil, skipping")
			continue
		}
    
    // 获取chaincodeActionPayload.Action.ProposalResponsePayload
    // 是一个ProposalResponsePayload类型
		propRespPayload, err := utils.GetProposalResponsePayload(chaincodeActionPayload.Action.ProposalResponsePayload)
		if err != nil {
			return nil, errors.WithMessage(err, "error unmarshal proposal response payload for block event")
		}
		
    // 获取propRespPayload.Extension字段，事件就存储在其中
    // 该类型是一个ChaincodeAction类型
		caPayload, err := utils.GetChaincodeAction(propRespPayload.Extension)
		if err != nil {
			return nil, errors.WithMessage(err, "error unmarshal chaincode action for block event")
		}
		
    // 获取caPayload.Events字段，该类型就是一个ChaincodeEvents类型
    // 到这里就拿到事件了
		ccEvent, err := utils.GetChaincodeEvents(caPayload.Events)
		if err != nil {
			return nil, errors.WithMessage(err, "error unmarshal chaincode event for block event")
		}
		
    // 获取链码ID
		if ccEvent.GetChaincodeId() != "" {
      // 其实就是一个事件的拷贝操作
      // 注意这里没有把事件的payload拷贝过去
			filteredAction := &peer.FilteredChaincodeAction{
				ChaincodeEvent: &peer.ChaincodeEvent{
					TxId:        ccEvent.TxId,
					ChaincodeId: ccEvent.ChaincodeId,
					EventName:   ccEvent.EventName,
          // 没有拷贝payload字段
				},
			}
      // 加上这个事件
			transactionActions.ChaincodeActions = append(transactionActions.ChaincodeActions, filteredAction)
		}
	}
  // 最终返回结果
	return &peer.FilteredTransaction_TransactionActions{
		TransactionActions: transactionActions,
	}, nil
}

DeliverFiltered 与 Deliver 的差别

好了到这里就分析完了。细心的朋友到这里其实就会发现一个问题，在做事件拷贝的时候，这一部分并没有将事件的payload字段拷贝过去，这就是DeliverFiltered这个服务做的，它最终把事件的部分内容返回回去了，不包括事件的payload信息，也就是事件的具体内容，只包含了TxId,ChaincodeId,EventName三个事件字段信息。

既然这样，那么Deliver服务做的应该就是完整的事件信息了，可以来看一下，代码在core/peer/deliverevents.go的52行：

// SendBlockResponse generates deliver response with block message
func (brs *blockResponseSender) SendBlockResponse(block *common.Block) error {
	response := &peer.DeliverResponse{
    // 直接将整个block返回
		Type: &peer.DeliverResponse_Block{Block: block},
	}
	return brs.Send(response)
}

这里甚至是直接将整个block返回了，都不带过滤事件的，看这个要从block中获取事件的操作应该要有DeliverClient来做了，这样就可以拿到事件的具体信息。

这个问题其实在protos/peer/events.pb.go中已经说明了：

type DeliverResponse_Block struct {
  // 这里直接返回
	Block *common.Block `protobuf:"bytes,2,opt,name=block,proto3,oneof"`
}

type DeliverResponse_FilteredBlock struct {
  // 这里过滤事件后返回
	FilteredBlock *FilteredBlock `protobuf:"bytes,3,opt,name=filtered_block,json=filteredBlock,proto3,oneof"`
}

很多SDK提供了类似BLOCK_FILTERED的标志来让用户选择是注册DeliverFiltered还是Deliver服务，针对不同的类型做出不同的措施。

建议事件如果只是做一个通知的作用，采用DeliverFiltered服务会更轻量，如果需要了解事件中的具体内容，则必须使用Deliver服务

TLpigff
关注
专栏目录
Hyperledger Fabric 事件监听(七)
笔记|思路|总结
01-09 713
Hyperledger Fabric 事件监听(七)
Hyperledger Fabric linux二进制文件
03-29
本压缩包“hyperledger-fabric-linux-amd64-1.1.0”是针对Linux 64位系统的Hyperledger Fabric版本1.1.0的二进制文件，包含了运行和部署Fabric网络所需的全部组件。 1. **Hyperledger Fabric架构**：Hyperledger ...
Hyperledger系列（六） Fabric中的 事件框架
maixia24的专栏
03-26 6220
介绍事件框架支持发出2种类型的event(事件)，block和自定义/chaincode event（在events.proto中定义的ChaincodeEvent类型）的能力。基本思想是，client（event consumers\事件消费者）将注册event类型（当前为“block”或“chaincode”）。并且在chaincode的情况下，它们可以指定附加的注册标准，即chaincode...
【Fabric.js】监听画布or元素的点击、选中、移动、添加、删除销毁、变形等各事件
最新发布
从今年开始写写博客~~
02-08 3069
例子就用vue项目组件里的代码，fabric的使用跟vue、react、angular之类的框架都没任何关系！代码中监听事件回调函数里的第一个参数，根据事件的不同，有目标图形信息、坐标信息等，自己一看就看得懂了，不讲解；在fabric使用过程中，如果想要玩各种花样，那么fabric的事件监听是一定、必须、肯定要掌握！并且本demo只对功能进行讲述，实际项目使用肯定要进行封装，别直接就照抄导致写的丑！代码只简单介绍一些常用的目标监听事件，更全面的、更多花样的玩法自行查阅官网即可~~
菜鸟系列Fabric源码学习 — 区块同步
爱无止
11-30 1448
Fabric 1.4 源码分析 区块同步时光小说网 www.youxs.org 本文主要从源码层面介绍fabric peer同步区块过程，peer同步区块主要有2个过程： 1）peer组织的leader与orderer同步区块 2）peer组织间peer同步区块。 1. peer leader和orderer同步区块 首先，orderer对外主要是broadcast和deliver两个服...
Michael.W谈hyperledger Fabric第21期-详细带读Fabric的源码6-orderer节点接收交易数据与广播区块数据
Revelation_of_Turing
03-17 1178
Michael.W谈hyperledger Fabric第21期-详细带读Fabric的源码6-orderer节点接收交易数据与广播区块数据1 接收交易数据2 广播区块数据 这两个部分围绕着orderer/server.go文件里的server结构体展开： type server struct { // 交易数据的接收 bh broadcast.Handler // 区块数据的广播 ...
学习Hyperledger Fabric 实战联盟链全套视频
09-09
学习Hyperledger Fabric 实战联盟链全套视频，附资料。
Hyperledger Fabric 源码 例子 依赖工具
11-01
一、Hyperledger Fabric源码分析 Hyperledger Fabric的源码分为多个组件，包括： 1. **Chaincode**: 这是业务逻辑的实现，类似于智能合约，负责处理交易并更新账本状态。 2. **Orderer**: 负责接收交易，并按照特定...
hyperledger fabric 结构分析（二）
01-08
接着上图分析，经过Consensus Commit流程生成批数据后，是如何送入到ChainCode呢？我们还是以Invoke命令分析。1）在consensus的helper中调用chaincode的ExecuteTransactions 进入transaction处理流程[cpp] 代码func ...
fabric:fabric-2.3.0原始解析
03-23
fabric-2.3.0原始解析
fabric1.0学习笔记（6）
qq_45955628的博客
10-25 463
fabric1.0学习笔记（1） fabric1.0学习笔记（2） fabric1.0学习笔记（3） fabric1.0学习笔记（4） fabric1.0学习笔记（5） fabric1.0学习笔记（6） 在之前的笔记中了解了fabric基本结构、底层操作的具体实现（排序节点的实现、交易收集、区块打包、扩散的实现、账本存储相关的实现等），这篇笔记涉及智能合约、节点的设置问题 一、智能合约 主要有以下三个问题： 链码生命周期管理 系统链码 链码的编程接口及编程禁忌 智能合约也称为链码，运行在背书节点上，模拟
fabric.js 在vue中的使用
热门推荐
看风听雨
08-08 1万+
Fabric.js 用法总结 （在vue中使用时，因为this的指向不同，所以在Fabric.js方法内部，this是无法使用指向外部的值的） 这只是我在使用fabric.js的过程中的一些总结，文章底部有一个fabric入门的链接，新手入门可以先看一下，适合新手 1. canvas.setBackgroundImage(require('../assets/logo.png')...
06.Fabric源码解析–GRPC服务
boss2967的博客
11-18 927
Fabric源码解析6–GRPC服务 GRPC简介 GRPC是由自谷歌开发的一项多语言开源的RPC技术，在fabric用于实现客户端与服务器端的远程调用。比如chaincode，客户定义了一项rpc服务并相应生成了客户端代码和服务端代码，在此基础上进行业务逻辑上的开发后，分别运行服务端代码和客户端代码，实现客户端调用服务器端服务的目的。由于gprc相对来说还是很复杂的，所有还请自行学习。在gprc...
Hyperledger Fabric从源码分析事件机制（一）
pigff的博客
07-01 1710
Fabric 允许应用程序在调用链码的时候监听链码中设置的事件，在监听到相应的事件后做相应的处理过程。 Fabric1.4 中的事件机制与老版本的事件机制源码部分有所不同，用的是Deliver的方式，所以老版本的代码与 Fabric1.4 版本的代码会有所不同。 本文将从源码解析整个事件机制的处理流程的。 回顾链码调用源码 链码调用监听事件部分代码 在之前的文章——Hyperledger Fabric从源码分析链码查询与调用，我有提到在ChaincodeInvokeOrQuery()函数中有对是否等待链码
hyperledger fabric的区块事件
05-21 4814
      hyperledger v1.1中的事务处理是一个跨越多个组件（application，endorsing peer，order，committing peer）的长操作，需要花费相当长的时间（以秒为单位而不是毫秒）来完成。因此，应用程序必须设计成异步通知的方式来进行对事务生命周期的处理。在交易提案成功通过之后，在事务消息已成功广播给order之前，应用程序应该注册一个侦听器liste...
fabric consensus event源码解析
LemonGirls的博客
08-01 547
代码位置为 fabric/consensus/… 想写pbft的代码解析来着。看到里面的事件流，设计得很赞，学习一下。 Manager 事件管理 主要实现的功能是事件通道的处理，通过相关接口，写入数据到通道中，数据处理方提供处理方法即可，不需关注通道的实现。 //首先，接口事件要做的事主要是，内部提供一个事件通道，暴露出往通道写数据的接口，以及数据处理接收方法，接收方法由Receiver提...
超级账本08：hyperledger fabric完整案例
欧阳桫的技术博客
12-05 2702
1.fabric开发流程 需求整理 合约编写 合约部署 合约交互 外部服务编写 2.需求分析 开发一个资产转让功能模块 平台功能 用户开户和销户 资产登记，解决资产上链和用户绑定资产 资产转让，资产所有权的变更 查询功能，用户查询、资产查询、资产变更历史查询 3.合约编写 assetsExchange.go 4.合约部署 关闭docker 生成通道的创世交易 查看...
hyperledger fabric源码分析
05-13
Hyperledger Fabric是一个面向企业的分布式账本技术平台，旨在为商业网络提供高度可信的解决方案。其源码分析包含了对Fabric的了解和深入研究，为开发者提供了修改和定制Fabric的机会。 Hyperledger Fabric的优点在于其可插拔型的架构，容易定制和扩展。该平台使用Docker容器来部署组件，实现了高度可扩展性和透明性。 在源码分析中，需要关注的重点包括链码部署和执行、交易处理、账本维护、共识协议、安全性等方面的细节。通过分析源码，可以理解Fabric的整个运作过程，包括交易的广播、共识的维护、账本的更新、查询和事务的处理等过程。 在进行源码分析时，需要具备一定的区块链技术基础知识，特别是关于共识机制、加密算法、网络协议、分布式系统和智能合约等方面的知识。通过掌握Hyperledger Fabric的源代码，可以更好地理解和掌握该平台的工作原理，为企业区块链应用的开发和实现提供有力支持。 总之，Hyperledger Fabric的源码分析是对其深入研究的必要过程，也是进一步推动区块链技术发展的关键环节。掌握源码将有助于开发者更好地理解Fabric的设计理念和技术框架，为企业应用提供更好的解决方案。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值