fabirc1.0 official version of the source code analysis---Peer admin and endorser Services __ block chain Fabric

Continue to start. Go Serve function, Peerserver object after Chaincodesupport service, also registered Admin,endorser service:

Pb. Registeradminserver (Peerserver.server (), Core. Newadminserver ())
serverendorser: = endorser. Newendorserserver ()
PB. Registerendorserserver (Peerserver.server (), Serverendorser)

1 2 3 1 2 3

Its registration is consistent with the registered Chaincodesupport service, in Fabirc Source resolution 7 has been detailed, so this article will only focus on the admin and endorser service itself. Admin

The admin service implements access and control to the server, module log levels. Service prototypes are defined in/fabric/protos/peer/admin.proto and corresponding generated admin.pb.go files. The core code is in/fabric/core/admin.go, which implements the admin service-side service in Admin.pb.go.

Proto defined service prototypes and defined service status//in/fabric/protos/peer/admin.proto defines the service admin {RPC GetStatus (google.protobuf.Empty) ret Urns (serverstatus) {} RPC StartServer (google.protobuf.Empty) returns (Serverstatus) {} RPC Stopserver (Google.prot Obuf.
Empty) returns (Serverstatus) {} ...}
        Proto the service state message Serverstatus {enum StatusCode {UNDEFINED = 0) defined using the enumeration;
        started = 1;
        STOPPED = 2;
        paused = 3;
        ERROR = 4;
    UNKNOWN = 5;
}//state StatusCode status = 1; //proto the generated server-side interface and registration function////In/fabric/protos/peer/admin.pb.go define type AdminServer Interface {GetStatus (context. Context, *google_protobuf. Empty) (*serverstatus, error) startserver (context. Context, *google_protobuf.
Empty) (*serverstatus, error) ...} Func Registeradminserver (S *grpc. Server, SRV adminserver) {s.registerservice (&_admin_servicedesc, SRV)}//Core code Implementation Admin Services//in/fabric/core/admin.go To define type ServerAdmin struct {}//server open, stop, get State function func (*serveradmin) StartServer (context. Context, *empty. Empty) (*PB. Serverstatus, error) {status: = &PB. SERVERSTATUS{STATUS:PB. serverstatus_started} log. DEBUGF ("Returning Status:%s", Status return status, nil} func (*serveradmin) startserver (...) ...
{...} Func (*serveradmin) GetStatus (...) ...
{...} Func (*serveradmin) startserver (...) ...
{...} Module log acquisition, Setup, Recovery function func (*serveradmin) getmoduleloglevel (...) ...
{...} Func (*serveradmin) setmoduleloglevel (...) ...
{...} Func (*serveradmin) revertloglevels (...) ... {...}

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26-27--28 29---30 31--32 33 34 35 36 37 38-39 40 41 42 45 46 47 48 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22-23--24 25---26 27--28 29 30 31 32 33 34-35 36 37 38 0 41 42 43 44 45 46 47 48

There are some questions about admin's startserver and stopserver operations, which literally seem to start and stop the service, but in practice, such as the StartServer function, it simply returns a state object with a state of started and no other action. Since it is a return state, it is possible that this state is needed elsewhere, but the startserver is not found to be called as expected by the grep search. In this break pen, if the other modules found in the two operational uses of the intention, will complement. 【。。。 】

Admin services on the module log function, involving the flogging, in Fabirc source resolution 3 has been detailed, can be reviewed and then traced back to the admin of these three functions. If you have an understanding of the fabric log system, the function of the three functions here is well understood. Taking Setmoduleloglevel as an example, the function is to obtain the module keywords and the log levels to be set in the Requst from the client, and then set them in flogging. endorser

endorser, personal habits literal translation into endorser. An endorsement of a cheque, as of an act or a right. In fabric, a subject receives an application message sent by another peer point, supports and approves the sender by checking the signature in the application message, so that the request or application can be finally submitted for use in the system. It is said that it is possible to refer to an application may also need to meet some conditions, such as the need to get a certain proportion of the endorsement, only to the whole system of identification. And these conditions, is refers to the endorsement strategy.

Endorser endorser in a transaction flow as follows: The client sends an endorsement request (Signedproposal) to endorser. Endorser the application for endorsement, sending an application reply (Proposalresponse) to the client. The client assembles the endorsement of the application response into a transaction request (Signedtransaction).

Here's a quick look at the concept of trading (Transaction), which will be detailed in the topic article. Trading is a larger concept, and any operation of fabric, such as chaincode operations, or even the operation of configuration systems, is defined as a transaction. and endorsement is only a preparation for the transaction request data, the transaction request data is ready, will be sent to the orderer. It should be noted that the general transaction and Chaincode exchange of the endorsement process is consistent, but the endorsement process of the exchange of data contained in the content of the items are different. Refer to the annotations and data prototyping definitions in/fabric/protos/peer/proposal.proto and Proposal_response.proto. Endorsement Service prototype and implementation

The prototype of the Endorser service is defined in the/fabric/protos/peer/peer.proto and corresponding generated peer.pb.go, and the core code is implemented under/fabric/core/endorser.

Service prototypes defined in Proto//in/fabric/protos/peer/peer.proto endorser {RPC processproposal (signedproposal) returns (P roposalresponse) {}}//proto the generated server-side interface and registration function////define type in/fabric/protos/peer/peer.pb.go Endorserserver interface {proces Sproposal (context. Context, *signedproposal) (*proposalresponse, error)} func registerendorserserver (S *grpc. Server, SRV endorserserver) {s.registerservice (&_endorser_servicedesc, SRV)}//Core code Implementation endorser service type Endorser St ruct {policychecker policy. Policychecker}//endorser dedicated initialization function func Newendorserserver () pb. Endorserserver {e: = new (endorser) E.policychecker = policy. Newpolicychecker (peer. Newchannelpolicymanagergetter (), Mgmt. Getlocalmsp (), Mgmt. Newlocalmspprincipalgetter (),) return E}//Implementation Processproposal service Func (e *endorser) processproposal (...)
{...} Func (e *endorser) endorseproposal (...)
{...} ...

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18-------------19 20 21 22 23 24 25 26 27-28 29 30 31, 1 17 18 19 20, 21 22 23 24 25 26 27 28 29 30 31

In the core implementation of endorser service, there is only one core function processproposal, The rest of the functions in the endorser.go are mutually compatible for processproposal calls, processing the signedproposal data sent by the client, returning the Proposalresponse data and accomplishing the final task.

The SIGNEDPROPOSAL data structure is as follows:

The Proposalresponse data structure is as follows:

Netizens, let's follow the Processproposal function to see how the Endorser function handles the signedproposal data from the client and then wraps what data to Proposalresponse and returns it.

The Processproposal function calls
prop, HDR, Hdrext, err: = Validation. Validateproposalmessage (Signedprop)

1 2 1 2

First, in the first step, the Processproposal function validates the received Signedprop data using Validateproposalmessage, and returns the data after Unmarshal of some fields in Signedprop. This function is still relatively round, and write here is not too logical, because it involves data validation, so at least to know what data received or what kind of data is legitimate, you can verify, and this involves the client operation, we have not mentioned. You can look at this in the future when it comes to client-related operations.

The validation process involves MSP. MSP will be detailed in the relevant topic article, put aside a simple introduction: MSP is a relatively large concept, is the abbreviation of Membership service provider, personal custom literal translation is a member relations service provider. Similar to a running fabric system network, there are a number of participants, and MSP is to manage these participants, identify who is qualified, who is not qualified, both to maintain the rights of one participant, but also to maintain the relationship between the participants.

Back to the main line of this article, Validateproposalmessage is defined in/fabric/core/common/validation/msgvalidation.go, calling the auxiliary validation functions in the same file and/fabric/ Protos/utils the tool function (putils. A class of functions such as XXX, described below with Putils, Signedproposal step-by-step verification of the structure. The tool functions under/fabric/protos/utils are basically unmarshal operations on the data prototypes defined in Protos, such as the Getproposal function in Proputils.go, that is, trying to pass in the [] The data in byte format is unmarshal into the proposal structure data defined in/fabric/protos/peer/proposal.pb.go.

The Validateproposalmessage function calls
///Validateproposalmessage functions in the same file
Chdr, SHDR, err: = Validatecommonheader ( HDR)
err = Checksignaturefromcreator (SHDR. Creator, ...)
Err = Utils. Checkproposaltxid (...)
Switch common. Headertype (CHDR. Type) {case
    ...
    Case common. Headertype_endorser_transaction:
        chaincodehdrext, err: = Validatechaincodeproposalmessage (prop, HDR)
    Default: ...
}

1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11-12

See the structure chart, the Validatecommonheader function validates the header in the proposalbytes in the Signedproposal, the creator in the primary validated Signatureheader is not NULL, Nonce is not empty and exists, the type in Channelheader must be one of the endorser_transaction, Config_update, and CONFIG, and by the return of the corresponding structural body data object unmarshal.

The Checksignaturefromcreator function uses the structure data returned by Validatecommonheader to verify the validity of the certificate, endorsement strategy, initiator identity and so on in Signedproposal, and is the core verification function. This inside great article, also used to MSP, and then used to BCCSP, but also because of this, put this detail into the MSP Service topic article in detail.

The CHECKPROPOSALTXID function compares the hash string value generated by Nonce and creator in Signatureheader with Channelheader in Txid. This also shows that TXID is the hash value generated by nonce and creator Union. The nonce here is designed to prevent replay attack, which is often used in encryption techniques.

The Validatechaincodeproposalmessage function simply verifies that payloadvisibility in the corresponding structure body chaincodeheaderextension in the proposal is empty 。 This field controls the extent to which proposal's payload can be used in the final transaction and in Ledger. At this point, the signedprop of the received Signedproposal object is validated and the header and Chaincodeheaderextension fields in the Proposal,proposal in Signedproposal are returned. The Prop,hdr,hdrext are respectively. For signedproposal validation content, when defining Signedproposal prototypes in/fabric/protos/peer/proposal.proto, 4 points are commented and can be read for reference.

The Processproposal function calls
Chdr, err: = Putils. Unmarshalchannelheader (HDR. Channelheader)
Shdr, err: = Putils. Getsignatureheader (HDR. Signatureheader)
if SYSCC. Issysccandnotinvokableexternal (HdrExt.ChaincodeId.Name) {...}

1 2 3 4 1 2 3 4

Immediately thereafter, the second step, in the Processproposal function, is the validation. Validateproposalmessage did not return, all again using the function under Putils to get the Channelheader and Signatureheader under the header, respectively, Chdr,shdr. The function issysccandnotinvokableexternal is then used to verify whether the Chaincode ID of the signedproposal involved in the current processing is a system chaincode, and if so, whether it can be called externally. Returns True if the Chaincodeid is a system chaincode and cannot be called externally, then enters the if branch and returns the corresponding error. This indicates that the chaincode of the sending signedproposal, if the system Chaincode, to ensure that the system Chaincode allowed to be called outside. In the system Chaincode, the Invokableexternal field sets whether it can be invoked by the outside world.

Channel ID
Chainid: = Chdr. Channelid
//transaction ID
txid: = Chdr. Txid
if Chainid!= "" {
    lgr: = Peer. Getledger (Chainid)
    If _, err: = Lgr. Gettransactionbyid (TXID); Err = = Nil {return}
    if!syscc. ISSYSCC (hdrExt.ChaincodeId.Name) {
        If Err = E.checkacl (Signedprop, Chdr, SHDR, hdrext);
        ...
    }
} else{
    //do Nothing
}

1 2 3 4 5 6 7 8 9 10 11 12 13-14