Development of Bitcoin Mining Machine (II.)

This is a creation in Article, where the information may have evolved or changed.

LSP API:

We now use the go language to write the LSP protocol. You have to use an accurate API to facilitate automated testing, which can guarantee compatibility issues in different runs.

The LSP API can be found in the LSP folder, which is also the beginning of the code. The file defines several outputs, including excuses, interfaces and constants, as well as detailed file descriptions that describe the content and compatibility of the various layers of the API. Can be queried on a regular basis.

LSP Information:

The different LSP information is defined as the following constant shaping:

Type Msgtype int

Const (

Msgconnect msgtype =iota//Connection request fromclient.

Msgdata//Datamessage from client or server.

Msgack//acknowledgment from client or server.

)

EACHLSP message consists of four

ELDs, and is declared as a Go struct:

Type Message struct {

Type Msgtype//oneof the message types listed above.

Connid int//uniqueclient-server connection ID.

SeqNum int//messagesequence number.

Payload []byte//data message Payload.

}

This is actually said before the queue ordinal, connection ID what the implementation of the parameters of the several, I believe it is more easily familiar. However, if you want to transfer information over the network, you must first convert the structure into a UDP packet by sorting the information into a sequence of bytes.

This method can be implemented using the marshal function in the Go language JSON package.

LSP Parameters:

In both the client and server, the API provides a mechanism to specify the time limit K, the time-point length B, and the size of the sliding window when the server and client are established. These parameters are sealed in the following structure:

Type Params struct {

Epochlimit int//Default value is 5.

Epochmillis int//Default value is 2000.

windowsize int//Default value is 1.

}

Client API for LSP:

The application invokes functions to establish new clients and initialize various activities of the client. However, this function fails when the connection to the client and server has been started but returns a non-null error about the connection not being established. The function is defined as follows:

Func newclient (Hostport string, params *params) (Client,error)

The client API of the LSP is defined by the client interface as follows:

Connid () int

Read () ([]byte, error)

Write (payload []byte) error

Close () Error

Like the client, the server interface allows the application to read and write to the client. Note, however, that because the server connects several LSP clients simultaneously, the write and Closeconn modes require the client to provide its own connection ID as a credential indicating whether the connection should be written or closed.

For a more detailed description of the file and the patterns and functions of each function, refer to the Server_api.go and server_impl.go files.

Initial code:

The initial code can be in the p1/src/github.com/cmu440/directory, the specific functions and distribution are as follows:

The LSP folder contains the API, the test, and the start code that needs to be perfected:

Client_api.go, Server_api.go, Message.go, and Params.go files contain definitions of LSP,API. In order to debug the normal, these files can not be changed.

The Client_impl.go file contains some framework for the client design and you have to fill in the details yourself.

The Server_impl.go file contains some of the framework for server design, and you have to fill in the details yourself.

The *_test.go file contains the test code that we want to run on the Autolab and evaluates your final commit.

The Lspnet folder contains all the UDP operations you need. In the background, the Lspnet package provides additional functionality to enhance the robustness of the system.

The Srunner (Server-runner) and Crunner (client-runner) Folders provide an executable program that can be used for debugging, respectively. The way these programs are used is placed in Project's readme.md.

It also provides the executable files in Srunner and Crunner that were previously compiled before the intended test. All two files have been compiled through an LSP instance, so you'll find it useful to program early in the morning, for example, if you want to test your client without writing a server. These instructions are used at the same time in readme.md.

For the start code provided, you may need to add some useful documentation. For example, you might suddenly be curious to add a common.go and then use it to store code that can be used both on the client and the server.

(not to be continued)