Fabric Source Analysis 2--peer command structure __fabric

Fabric Source Analysis 2--peer command structure Peer directory Structure

Peer directory structure itself is very clear, a main.go file, the rest of the folder, in addition to the COMMON,GOSSIP are all sub-command set, there are chaincode,channel,clilogging,node,version five, their respective duties, For Main.go integrated use. In a child command folder, the. Go file with the same name as the folder is the primary source file, and the rest is the source of the action command, which is divided by function. In the node directory, for example, node itself acts as a child of the root command, Implemented in Node.go, and node This command itself has start,status,stop these three actions to perform different tasks, respectively, in the corresponding START.GO,STATUS.GO,STOP.GO implementation. Notice that Start,status,stop is also a subcommand, a subcommand to the subcommand of node, because they are the people at the bottom of the command level who end up working, and I think it's more appropriate to describe them by action. Chaincode channel clilogging Common gossip node
Node.go start.go status.go stop.go version main.go Third Party Package

In getting started, either the command that is executed by default when the peer container is started, or the command entered in the terminal window when the transaction is executed manually, the class has a similar format, such as Peer Channel...,peer node...,peer Chaincode ... COMMAND + subcommand + option style, so that people feel no sense of Shong. The peer command relies primarily on the Third-party package Github.com/spf13/cobra, which makes up the basic Peer command architecture. So here is a brief introduction to Cobra.

Cobra is both a library for generating command-line programs and a program for generating programs and command files (that is, a series of operations with the Cobra command at the command line, formatted to generate some source code files that use the Cobra framework, where the user can program). At present, the peer source only uses Cobra as a library. The basic usage of Cobra is to create a (root) command object whose prototype is command, and each command is an instance of a Command object. Creating a Command object is actually the process of populating a member of the command. It is important to note that there are a number of members in the command, including a batch of fields named *run,*rune, whose function is similar to run, which differs from whether the Quilt command inherits, or returns an error, if the running time is first available.

Type command struct {use  
    string   //Command Name field, if you knock at the command line is peer ..., the field value is "peer"
    short string//Brief description field
    Long String  //detail field
    run func (cmd *command, args []string)//function performed by this command ...
}
Rootcmd: = &cobra.command{...}

If necessary, add flag to the command, which can be easily understood as a command option.

Rootcmd.persistentflags (). Boolvarp (&verbose, "Verbose", "V", False, "Verbose output")
rootcmd.flags (). Stringvarp (&source, "source", "s", "", "source directory to read from")

If necessary, add a subcommand to the root command, and the child command is the same as the root command, but is artificially differentiated at the level.

Rootcmd.addcommand (Versioncmd)

Run the command.

Rootcmd.execute ()

Because the article is focused on peer, so just do a brief introduction, more detailed methods of use, can be on the Go doc or Github.com/spf13/cobra to learn. In fact, reading fabric source process has a feeling, is the project of the Great God of the selection of Third-party libraries, generally are both to meet the needs, but also easier to learn and start. PEER command structure parsing

We are now officially from the Peer/main.go file to parse the source code, this article is intended to resolve the peer command structure, so will only involve the relevant source code, the other parts will be in other topics in the corresponding analysis. If you are a little familiar with the usage of Cobra, you can easily read the construction of the main function. The peer directory is very similar to the source structure of the subcommand, and can not escape the basic operation described above about Cobra.

First defines a maincmd command,var maincmd = &cobra.command{...}, which populates the Use,persistentprerune and run members. Use, as we foresee, is assigned to peerand Persistentprerune is assigned an anonymous function before run. Because Maincmd is simply a root command and does not implement a specific transaction transaction implemented by the subcommand, it implements only the Persistentprerune specified check, initialize the log system, and caches the configured features, and the version print, command Help features specified by run

The command line identifier Object mainflagsThe generated Maincmd object,mainflags: = Maincmd.persistentflags (), which is the option of the Peer command, and maintains the identity to the image. Added two options for Version,logging_level. This also corresponds to its ability to set Persistentprerune and run in its own object.

Add Child command,maincmd.addcommand (...). The added command has version. CMD (), node. CMD (), Chaincode. CMD (nil), clilogging. CMD (nil), channel. CMD (nil) five. CMD () is a function that is exposed in each child command file, each of which integrates its own action commands.

Start root command,maincmd.execute (). The root command is started and all commands under it are started. Sub-command structure parsing, taking node as an example

In fact, read the peer command, the rest of the child command analogy can be. Here's a long-winded sentence. The source structure of the subcommand is very similar to the previous one, where node is the only example.

In Node.go, you first define a node command object,var nodecmd = &cobra.command{...}

In the CMD function, add startcmd (), Statuscmd (), Stopcmd () three functions to return the START,STATUS,STOP subcommand (Action command), respectively implemented in Start.go,status.go,stop.go. The source structure of these three commands is also basically consistent, with only start and start.go as examples.

In Start.go, you first define a Start command object,var nodestartcmd = &cobra. command{...}, where an anonymous function is assigned to the Rune member, and the serve function is executed in the function body, which is also the function that the command will eventually call. The serve function is a very important, very complex function. Remember that in the article on the thread of fabric project mentioned above, the default execution after each peer container startup is the peer node start–peer-defaultchain=false command, where it is docked, The command ultimately invokes the serve function, which means that the serve function does a lot of preparation. PEER command Structure