CODEWITHSUNDEEP
hyperledger-fabric
Count Chu
Count Chu

Reputation: 31

How does an offline peer update state in Hyperledger Fabric?

All,

As I know, in Hyperledger Fabric environment, an orderer delivers messages to peers. If there is an off-line peer. How is the message delivered to the peer when it recovers to ON-LINE? How does the orderer know the peer recovers to ON-LINE?

Regards, Count

Upvotes: 3

Views: 1022

Answers (3)

Dave Enyeart
Dave Enyeart

Reputation: 2573

When the peer comes back online it will get blocks as follows:

  • If the peer is a gossip leader in the org, then it requests a stream of blocks from an orderer via deliver API, starting at the peers current block height.

  • If the peer is not a gossip leader and is current or just a little behind (within a small threshold), then it gets blocks via gossip from the org's leader peer (or potentially another peer in the org).

  • If the peer is not a gossip leader and is way behind (beyond the threshold), then it gets blocks via block transfer from another peer (can be cross-org).

For more details see the gossip data dissemination layer documentation.

Upvotes: 5

arnabkaycee
arnabkaycee

Reputation: 1644

enter image description here You can refer to this image for a brief overview

Upvotes: 1

Artem Barger
Artem Barger

Reputation: 41232

I'd like to add more details on the flow of state replication. First of all ordering service provides following API:

service AtomicBroadcast {
    rpc Broadcast(stream common.Envelope) returns (stream BroadcastResponse) {}

    rpc Deliver(stream common.Envelope) returns (stream DeliverResponse) {}
}

Where Broadcast used to send transactions for ordering to the ordering service and Deliver used by peers to request blocks from the ordering service starting from certain position. Possible options for Deliver are

message SeekPosition {
    oneof Type {
        SeekNewest newest = 1;
        SeekOldest oldest = 2;
        SeekSpecified specified = 3;
    }
}

There are two possible mode of operations for the peer considering status synchronization and replication of the ledger. Generally speaking ledger blocks distributed across the network by using gossip algorithm. In order to prevent all peers connecting to the ordering service there is a notion of leader election, e.g. for each organization there is one peer selected to open connection to the ordering service and start pulling blocks and forward them to the gossip layer to make them distributed between peers in the network. Before start leader check what is the ledger height and ask to deliver new blocks starting from it, all peers monitor availability of the leader and initiate new leader election if needed.

Now, there is additional background process which collects state messages from the peers and if it discovers there is a gap between local ledger height and height of others peers in the network it will initiate replication of missing blocks, via "state transfer" process as was mentioned by @Dave.

Hence, to conclude if peers comes online and for some reason elected to be a leader it will replicate ledger blocks directly from ordering service, otherwise he will get either via gossip layer or state transfer in case of significant gap in ledger height.

Upvotes: 2

Related Questions