Hyperledger Fabric PBFT Algorithm--A brief analysis __ algorithm

What has been harvested and what has been done is an important issue.
This article is only to learn to exchange information, personal summary. A brief analysis of Hyperledger fabric PBFT algorithm Architecture

Fabric Consensus algorithm code is all in the Consensus folder, consensus folder is mainly divided into Controller,executor,helper,noops,pbft,util file module.
Among them, consensus.go mainly contains the internal interface of the algorithm plug-in to externally exposed and hyperledger external to the internal exposed interface of the algorithm. Controller: The consensus algorithm module is pluggable, in the controller can choose the specific use of the consensus algorithm. Currently Hyperledger it provides a pbft algorithm and a relatively simple noops algorithm. Executor:executor and helper are two interdependent modules that provide a piece of code for consensus algorithms and external cohesion. Mainly responsible for the transfer of event handling. Helper: This includes a call to an external interface, such as performing a processing transaction,stateupdate, persisting some objects, and so on. Noops:noops means no operations! (correct) PBFT:PBFT algorithm, the following will be a brief introduction to the PBFT algorithm call flow. Util: Some of the tools needed for interaction, one of the most important implementations is its messaging mechanism.

The following is a brief introduction to two points, a little PBFT algorithm code inside the beginning and end of a call process, one is the PBFT algorithm inside the event mechanism and a brief analysis of the timeout code.

Internal Call Flow

Inside the engine.go there is a consensus algorithm plugin

Func Getengine (coord peer. Messagehandlercoordinator) (peer. Engine, error) {
    var err error
    Engineonce.do (func () {
        engine = new (Engineimpl)
        engine.helper = Newhelper (coord)
        Engine.consenter = controller. Newconsenter (Engine.helper)
        engine.helper.setConsenter (engine.consenter)
        engine.peerendpoint, err = coord . Getpeerendpoint ()
        engine.consensusfan = util. Newmessagefan ()

        go func () {
            logger. Debug ("Starting up message thread for Consenter")

            //The channel never closes, so this should never break for
            ms G: = Range Engine.consensusFan.GetOutChannel () {
                ENGINE.CONSENTER.RECVMSG (msg). MSG, MSG. Sender)
            }} ()}
    )
    return engine, Err
}

It initializes a consenter and a helper, and assigns a handle to each other. The purpose of doing this is to allow external calls inside, internally to invoke external.

Let's start by looking at how it Initializes a consensus module:

1. Call the controller to get a plugin, and when selected is the PBFT algorithm, it calls Getplugin in Pbft.go (c consensus. Stack) method, pbft.go all external parameters into the algorithm inside.

Func New (Stack consensus. Stack) consensus. Consenter {
    Handle, _, _: = Stack. Getnetworkhandles ()
    ID, _: = Getvalidatorid (handle)

    switch strings. ToLower (config. GetString ("General.mode")) {case
    "batch":
        return Newobcbatch (id, config, stack)
    default:
        Panic (FMT . Errorf ("Invalid pbft mode:%s", config. GetString ("General.mode"))
    }
}

2. Use the method Newobcbatch (id uint64, config *viper. Viper, stack consensus. Stack) Initializes a Obcbatch object. The purpose of this batch object is to make the request cache, improve the efficiency of transaction execution, if every request to make a consensus, it will be very expensive. The cache is stored in the Batchstore.
 3. At Newobcbatch, an instance of the Pbftcore is initialized, which is the core module of the algorithm. And a Batchtimer is started (this batchtimer is a timer that triggers a sendbatch operation when the Batchtimer timeout, which is only done by the primary node). Of course, an event-handling mechanism is created, which is a bridge for each module's communication.
 4. When initializing the Pbftcore, three timer is created while reading the used configuration     

Instance.newviewtimer = ETF. Createtimer ()
instance.vcresendtimer = ETF. Createtimer ()
instance.nullrequesttimer = ETF. Createtimer ()

Newviewtimer corresponds to viewchangetimerevent{}, a ViewChange event is triggered when the timer does not have close at a certain time. Vcresendtimer corresponds to Viewchangeresendtimerevent, emitting viewchange will trigger a new send ViewChange. Nullrequesttimer corresponds to Nullrequestevent, if the primary node has not sent Preprepare messages for a long time, that is, the reqbatch assigned seq. It thinks that the master node hangs up and sends a VIEWCHANGE message when it is timeout.

Of course understanding the above need to understand the PBFT algorithm of the specific process. The above is the initialization process of the PBFT algorithm plug-in, and explains some of the information that I think is more important to initialize. The specific initialization needs to look at the code.

the event mechanism inside the algorithm

Why should the event mechanism be presented separately, because to fully understand its invocation process, it must understand its flow of events. It's a complicated stream of events, and I don't think it's going to be that complicated.

It has two streams of events, one in helper and one in batch.

First analysis of its event flow tool, it is the entire code in the util package of events.go, I think this design is still very good, in my own consensus algorithm test environment, it modified a bit, it feels good.

First look at the interface it provides

Type Manager Interface {
    Inject (Event)   //A temporary interface to allow the Event Manager thread to skip the Queu E
    Queue () chan<-Event/Get a write-only reference to the Queue, to submit events
    Setreceiver (Receiver)/Se t the target to route events
    to Start ()              //Starts the Manager thread TODO, these thread management things should p Robably go away
    Halt ()                //Stops the Manager thread
}

Setreceiver (Receiver) is an important interface that determines the flexibility of this event mechanism. It's time to test my ability to express. An event mechanism must have an input and an output, and the Setreceiver (Receiver) interface method determines where the event flow is going. The following is the interface of receiver, where the recipient of the event must implement the Processevent (E Event) event method. This method is implemented in batch.

Type Receiver Interface {
    //processevent delivers an event to the Receiver, if it returns NON-NIL, the return is the Next processed event
    processevent (E event) event
}

That corresponds to the output, the Queue () chan<-event, which returns an event channel, all your messages in spite of being sent inside. Receiver depends on receiver.

Func sendevent (receiver receiver, event event) {
    Next: = event for
    {
        //If an event returns something Non-nil, Then process it as a new event
        next = receiver. Processevent (Next)
        If Next = nil {
            break
        }
    }
}

This code is to pass events to receiver processing. Give an example of the batch event flow mechanism.

The interface that receives request for outside requests is implemented inside the external.go. The Obcbatch initialization is created for it and the event manager is copied to Externaleventreceiver. So all messages received by this manager will go into batch.

Recvmsg is called by the stack when a new message is received
func (EER *externaleventreceiver) recvmsg (ocmsg *pb.m Essage, Senderhandle *PB. Peerid) Error {
    eer.manager.Queue () <-batchmessageevent{
        msg:    ocmsg,
        Sender:senderhandle,
    }
    return Nil
}

When a request is received, the batchmessageevent is placed in the event stream, and then

Func (em *managerimpl) EventLoop () {for
    {
        Select {case
        Next: = <-em.events:
            em. Inject (next) Case
        <-em.exit:
            logger. Debug ("EventLoop told to exit")
            return
        }
    }

This dead loop receives the event carried out by EM. Inject (next), and executes

Func sendevent (receiver receiver, event event) {
    Next: = event for
    {
        //If an event returns something Non-n Il, then process it as a new event
        next = receiver. Processevent (Next)
        If Next = nil {
            break
        }
    }
}

Then this operation was performed in Obcbatch processevent.

Case batchmessageevent:
        ocmsg: = et
        return op.processmessage (ocmsg.msg, Ocmsg.sender)

This is the message of the process of throwing, in the same vein, the message is thrown out, is the algorithm inside the event to the external executor to the event manager.

Timer mechanism

The timer mechanism is very much associated with the event mechanism, and when time is out, the pre-created event is plugged into the stream of events in the EventManager.

Type Timer Interface {
    Softreset (duration time). Duration, event event)//Start a new countdown, only if one was not already started
    Reset (Duration time. Duration, event event)     //Start a new countdown, clear any pending events
    stop ()                                         //Stop the countdown, clear Any pending Events
    Halt ()                                         //Stops the Timer thread
}

Setting time Out is primarily the Softreset and reset methods. As a result, the manager is passed to the timer during initialization.

But such an event mechanism may be problematic when it comes to large data processing.