Gonet2 Game Server Framework parsing GRPC improved (5)

The previous blog is about the basic use of the GRPC framework, if the GRPC is only remote to send a few parameters, that and a normal HTTP request is not much different. So today I'm going to learn how to use the GRPC advanced point. Flow!

Streams can be divided into unidirectional and bidirectional depending on how they are used:

• Unidirectional
  –client->server
  –server->client
• Bidirectional
  –client<=>server

Here is a new example where the parameter represents a piece of land, and the return is the building above the ground. Unlike the previous one, the return type is preceded by a quantifier stream, which means that the result will be returned as a stream, and above this piece of land may contain a large number of buildings.

syntax="proto3"Point{}Path{}message Ground{}message Construction{}{    // Server Side Stream    rpc ListConstructions(Ground) returns (stream Construction) {}    // Client Side Stream    Point) returns (Path){}    // Bidirectional streaming    OffsetPointPoint){}}

Run the command to generate the code:

protoc --go_out=plugins=grpc:. test.proto

The generated code is too long, a section of the post, first the object definition part, here should be a little simpler:

 PackageTestImportProto"Github.com/golang/protobuf/proto"Import(Context"Golang.org/x/net/context"Grpc"Google.golang.org/grpc")//Reference imports to suppress errors if they is not otherwise used.var_ = Proto. MarshaltypePointstruct{}func(M *point) Reset () {*m = point{}}func(M *point) String ()string{returnProto.compacttextstring (M)}func(*point) Protomessage () {}typePathstruct{}func(M *path) Reset () {*m = path{}}func(M *path) String ()string{returnProto.compacttextstring (M)}func(*path) Protomessage () {}typeGroundstruct{}func(M *ground) Reset () {*m = ground{}}func(M *ground) String ()string{returnProto.compacttextstring (M)}func(*ground) Protomessage () {}typeConstructionstruct{}func(M *construction) Reset () {*m = construction{}}func(M *construction) String ()string{returnProto.compacttextstring (M)}func(*construction) Protomessage () {}//Reference imports to suppress errors if they is not otherwise used.var_ Context. Contextvar_ Grpc. Clientconn

Several struct definitions of the generated go language correspond exactly to the 4 message definitions in the proto file. Comparing the examples in the above and the previous ones, there are no more complicated objects than many. Skip over!

Service side

As soon as I saw this code, I was a little bit high. But think of the previous sentence, "The same code, look carefully, feel the difficulty is 5, do not look carefully, a bit on the mask, the difficulty may be 8." So, the roots are not difficult, but lazy to look at.

When I hit this, I found a familiar piece of code, in the last paragraph of the generated file,

var _MapService_serviceDesc = grpc.ServiceDesc{}

Because this paragraph is the name of the service and corresponding to the mapping of handler, so, this all of a sudden have read 23 lines of code. But there is a difference, this time is not the method array, but the streams array, it is obvious that this time the service is the form of the stream, so Grpc is the method name of the service, as the name of the stream, and for each stream, the corresponding generated a handler method:

• _mapservice_listconstructions_handler
• _mapservice_recordpath_handler
• _mapservice_offset_handler

The above analysis shows that the approximate structure is still unchanged. See generated code the top two pieces of code, has been annotated, not many attached to explain, I believe that the previous blog friends can easily understand:

//Server APIForMapserviceservice//The service approach we're going to implement type mapserviceserver interface { listconstructions(*Ground,  Mapservice_listconstructionsserver) errorrecordpath (mapservice_recordpathserver)  ErrorOffset (mapservice_offsetserver) error}         We tell the GRPC framework that we implement the server-side object instance.func Registermapserviceserver(S *grpc.Server, SRVMapserviceserver) {s.Registerservice(&_mapservice_servicedesc, SRV)}

• Service method One, the Server side one-way flow.
  As the name implies, the service side to the client has a one-way channel, the portal on the server, export at the client, and the server will naturally have a data to this entry operation.

//Server Side Stream//RPC listconstructions (Ground) returns (stream construction) {}func_mapservice_listconstructions_handler (SRVInterface{}, Stream grpc. Serverstream) Error {m: =New(Ground)ifERR: = stream. Recvmsg (m); Err! =Nil{returnERR}returnSrv. (Mapserviceserver). Listconstructions (M, &mapservicelistconstructionsserver{stream})}typeMapservice_listconstructionsserverInterface{Send (*construction) error GRPC. Serverstream}typeMapservicelistconstructionsserverstruct{Grpc. Serverstream}func(x *mapservicelistconstructionsserver) Send (M *construction) error {returnX.serverstream.sendmsg (M)}

First, the _mapservice_listconstructions_handler method is called when the server receives the request, parses the data, and generates a mapservicelistconstructionsserver to provide the service.
The Mapservicelistconstructionsserver implements the Mapservice_listconstructionsserver interface, which contains a grpc encapsulated Serverstream, which is the entrance to the channel, And a send method for sending messages.

• Service method Two, Client side one-way flow.
  There is also a channel between client & server, and this time the server receives the point data sent by the client.

func_mapservice_recordpath_handler (SRVInterface{}, Stream grpc. Serverstream) Error {returnSrv. (Mapserviceserver). Recordpath (&mapservicerecordpathserver{stream})}typeMapservice_recordpathserverInterface{sendandclose (*path) Error Recv () (*point, error) Grpc. Serverstream}typeMapservicerecordpathserverstruct{Grpc. Serverstream}func(x *mapservicerecordpathserver) Sendandclose (M *path) error {returnX.serverstream.sendmsg (M)}func(x *mapservicerecordpathserver) Recv () (*point, error) {m: =New(point)ifERR: = X.serverstream.recvmsg (M); Err! =Nil{return Nil, err}returnMNil}

Handler is used to receive requests from clients and to generate service objects for specific processing.
Service definition Package A Stream object, receive method, used to receive the client's non-stop point data, and finally return the path, because it is a one-time return, so named Sendandclose.

• Bidirectional flow

func_mapservice_offset_handler (SRVInterface{}, Stream grpc. Serverstream) Error {returnSrv. (Mapserviceserver). Offset (&mapserviceoffsetserver{stream})}typeMapservice_offsetserverInterface{Send (*point) Error Recv () (*point, error) Grpc. Serverstream}typeMapserviceoffsetserverstruct{Grpc. Serverstream}func(x *mapserviceoffsetserver) Send (M *point) error {returnX.serverstream.sendmsg (M)}func(x *mapserviceoffsetserver) Recv () (*point, error) {m: =New(point)ifERR: = X.serverstream.recvmsg (M); Err! =Nil{return Nil, err}returnMNil}

After reading the code in the face of unidirectional flow and bidirectional flow, this part seems to be understood at a glance!

With two blog, basic to the GRPC framework has a understanding, the next one, will return to the GONET2 framework! Look at the frame, how to use the GRPC bar!

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Gonet2 Game Server Framework parsing GRPC improved (5)