socketreadtimeout solution_Golang lightweight high-concurrency socket framework – chichat

This is a lightweight development framework chitchat based on golang socket that supports high concurrent operations. This article will introduce the basic usage of chichat – analyze the specific workflow of the framework through source code – and briefly explain the Demo file left by the author and the usage skills of the framework – download link. Through this framework, we can easily establish Server-Client long connections and communicate.
Using chitchat
The key to chitchat’s ability to support high concurrent connections is its ability to quickly respond to connections initiated by the client and start goroutine in a timely manner to ensure one-to-one communication. For users, they are only responsible for registering the correct IP socket with the framework. ipAddr ipPort The address Addr all refers to addr:port） and the functions for processing receiving data and exception handling are correctly written to run normally.
Start a Server
Just create a Server instance and call its Listen() method to make a Server start working normally. A Server is usually only used to listen to one port and is responsible for the scheduling and processing of one type of things. Let’s take a look at the specific scheduling API：

func NewServer(ipaddrsocket string,delim byte, readfunc ServerReadFunc, additional interface{}) Server

Yes See ，Creating a Server instance requires providing four parameters，respectively listening object，separator， Handling functions，Additional data. Among them, Additional data can be set to empty (nil). Listening object is the IPsocket that the Client can connect to. When the Server reads a series of data, it will slice the data through delim delimiter and hand it over to readfunc for processing. ，Multiple pieces of data will call readfunc multiple times. delim can be set to 0. At this time, the server will continue to read EOF before delivering the data. When delim is set to ‘n’，Server will default to newline delivery，At this time, corresponding adjustments will be made according to Windows’rn’；Processing function will process the delivery of Server Data flow ；Additional data is to cooperate with readfunc to better complete the processing of data. Later, when explaining how to write readfunc, we will mention how to use the data given by additional.
Server is actually a callable external API interface interface， which contains the Listen() method to start the Server to start listening.

func (t *server) Listen() error

Listen is an asynchronous method ， If the configuration parameters are found to be incorrect or the port is occupied When an error occurs, it will be returned directly. Otherwise, a new goroutine will be launched in the background to handle specific transactions. The Listen() method does not block the process, nor does it wait until all background goroutines are working properly before returning.
If the background goroutine encounters an error during operation and processing, it will notify the user through the Err channel， Therefore, the user needs to explicitly receive and handle the error. Note that even if these error messages are not needed, we still need to have a receiving process, otherwise the background process will be blocked. Get the Channel：

type Errsocket struct {Err errorRemoteAddr string
}func (t *server) ErrChan() <-chan The error message sent by Errsocket

contains two parts ，error and peer ip(addr:port).

When we want to shut down the Server， just call its Cut function：

func (t *server) Cut () error

The Cut() method will cause the Server to stop listening to the Socket， and release all connected Connections. This method is the same as Listen() and will not wait for all Connections to be closed before returning. If we want to close a specific Connection, of course we can use the CloseRemote method：

func (t *server) CloseRemote(remoteAddr string) error

At this point, the more important Server API has been briefly introduced ， Others are relatively simple You can know its function based on the name of the API – I won’t go into details here. Later we will demonstrate the usage of these APIs through a simple example.

type Server interface {Listen() errorCut() errorCloseRemote(string) errorRangeRemoteAddr() []stringGetLocalAddr() stringSetDeadLine(time.Duration, time.Duration)ErrChan() <-chan ErrsocketWrite( interface{}) error
}

Open a Client

Create a Client instance through the NewClient function， and report it to the server by calling its API method Initiate a connection.

func NewClient(ipremotesocket string,delim byte, readfunc ClientReadFunc, additional interface{}) Client {

You can find ， Create a Client instance The form and meaning of function parameters are basically the same as those used to create a Server instance NewServer. Again no further explanation will be given. Note that the “v1.0.0 version Client has not been able to specify its own ipaddr” and can only be randomly connected after the connection is successful.After ientcalls Close() to close the connection, all opened goroutines and errChannels will be closed.
hC4s and hC4c are very similar，Let’s focus on analyzing the hC4s source code：

func handleConnServer(h *hConnerServer, eC chan Errsocket, ctx context.Context, s * server) {...}
type hConnerServer struct {conn net.Connd bytemu *sync.Mutexreadfunc ServerReadFunc
}

hConnerServerStructure main Contains the following content：Connection instanceconn，Separatord，Ordinary lockmu， readfunc，mutex is mainly used to maintain the normal work of eD；eC is the error sending channel passed down from the upstream；listens ctx.Done () Guarantees to receive the exit signal together with the upstream – but does not guarantee the order of exit – server provides the API used by readfunc. The defer() statement ensures that the conn and eD goroutine will be safely closed when hC4s exits.
The pulled up readgoroutine will send the read DATA fragments to hC4s through the channel，hC4s will hand over the DATA to readfunc for processing：

//hC4scase strReq, ok := <-strReqChan: //read a data slice successfullyif !ok {return //EOF && d!=0}err := h.readfunc (strReq, &server{currentConn: h.conn,delimiter: h.d,remoteMap: s.remoteMap,additional: s.additional,})if err != nil {h.mu.Lock()eC <- Errsocket{ err, h.conn.RemoteAddr().String()}}}

A server struct implements all methods in the Server interface and ReadFuncer interface at the same time, and passes the interface’s The method exposes specific methods to users of the framework – this design enables some repeated methods to be reused in the code.

hC4c is slightly different in this code：

//hC4ccase strReq, ok := <-strReqChan: //read a data slice successfullyif !ok {return //EOF && d!=0}if h.readfunc != nil {h.rcmu.Lock()err := h.readfunc(strReq, client) if err != nil {h.eD.mu.Lock()eC <- Errsocket{err, h.conn.RemoteAddr().String()}}h.rcmu.Unlock()}}

The difference is that：

1. For the Client,，its readfunc can be nil，In this way, the data can be read normally but not Processed ；
2. Compared with Server, there is one more rcmu lock. This lock is to prevent the error Channel from being closed early after the Close() method is called in readfunc, causing the error message of readfunc to not be delivered correctly. We can take a look at the Client’s Close() method：

func (t *client) Close() {go func() {t.rcmu.Lock() t.mu.Lock()t.closed = trueclose(t.eU)t.mu.Unlock()t.rcmu.Unlock()t.cancelfunc()}()
}

You can see that the Close() method will wait for the rcmu lock to be released before performing subsequent operations. And why does Server not need to lock it? Because the Close() method called by Server in readfunc will not close the upstream error Channel.
Server stores the ip socket and cancelFunc corresponding to each Conn through a concurrent and safe map to ensure that any Conn can be closed independently.
Demo analysis
As above, firstly show the process relationship between the operation and scheduling of each goroutine in the form of a diagram, and briefly explain the role of each goroutine：

Provided by Master The Listen() method will register a readfunc named registerNode； When the Node node successfully registers with the Master，Node The node pulls up a dHBL (daemon-HeartBeatListener) goroutine， initiates listening on port 7939 and registers hb4node readfunc， for Receive ping message and send pong response；Master will pull up adHBC(daemon-HeartBeatChecker)，initiate connection to Node regularly and send ping message，and Register hb4masterreadfunc， and actively close the connection after successfully receiving the pong message. If an error occurs while receiving the message, the error message will be sent to the HBC/L error error handler for further processing.
When dHBC receives more than three error messages in a row ， it is determined that the peer Node has lost the connection； when HBL error is not received for more than ten seconds After receiving the message from the Master, it is determined that the Master has lost itself.
Demo Tricks
In hb4master/node readfunc，regardless of whether the result is successful or not， an error（”succeed” or specific error， will be sent #xff09;，In this way, the HBC/L error can know the result of this message transmission based on the error and perform further operations.
Github
Github：chitchat
Or you can also get github.com/ovenvan/chitchat