GRPC Source/transport/Client Service side

Review

Http2client implement self-clienttransport interface
Http2server implement self-servertransport interface

Https://github.com/messixukej ...
Added some comments on the basis of liangzhiyang/annotate-grpc-go

Client: HTTP Client connection creation

Principle (quoted from HTTP2-SPEC/HTTP2 Chinese-English version (06-29). MD at Master Fex-team/http2-spec GITHUB.MD)):
Upon establishment of a TCP connection and determination that HTTP/2 would be used by both peers, each endpoint must send a Connection Preface as a final confirmation and to establish the initial SETTINGS parameters for the HTTP/2 connection.
After establishing a TCP connection and detecting that the HTTP/2 will be used by each peer, each endpoint must send a final confirmation of the connection prologue and as an initial setup parameter to establish the HTTP/2 connection.

The Client connection preface starts with a sequence of all octets, which in hex notation is:
The client connection prologue starts with a sequence of 24 bytes, in hexadecimal notation:

0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
(The string PRI * http/2.0rnrnsmrnrn). This sequence was followed by a SETTINGS-frame (section 6.5). The SETTINGS frame may be empty.
(String pri * http/2.0rnrnsmrnrn). This sequence is followed by a set frame, which can be an empty frame.

The server connection preface consists of a potentially empty SETTINGS frame (Section 6.5) This must be the first frame th E server sends in the HTTP/2 connection.
The service-side connection prologue contains a set (SETTING) frame that may be empty (section 6.5), which must be first sent in the HTTP/2 connection.

To avoid unnecessary latency, clients is permitted to send additional frames to the server immediately after sending the Client connection preface, without waiting to receive the server connection preface. It's important to note, however, that's the server connection preface SETTINGS frame might include parameters that Necessar ily alter how a client was expected to communicate with the server. Upon receiving the SETTINGS frame, the client is expected to honor any parameters established.
To avoid unnecessary delays, allow the client to send additional frames immediately after sending the client connection preamble, without waiting to receive a server-side connection prologue. However, it is important to note that the service-side Connection Prologue setting (SETTINGS) frame may contain some parameters that must be modified to expect the client to communicate with the server. After you receive these settings (SETTINGS) frames, the client should follow all the set parameters.

Clients and servers must terminate the TCP connection if either peer does not begin with a valid connection preface. A Goaway Frame (Section 6.8) can being omitted if it is clear, the peer is not using HTTP/2.
If either endpoint does not begin with a valid connection prologue, the client and server must terminate the TCP connection. If the endpoint does not use HTTP/2 then you can omit the timeout (Goaway) frame (Chapter 6.8).

newHTTP2Client {    conn=dial()    t=基于conn建立http2Client    framer 基于conn建立newFramer(conn),    go t.reader() //循环读取所有帧，并分发到对应流中    t.conn.Write(clientPreface) //发送preface帧给服务端    t.framer.writeSettings //发送setting帧。疑问：与writeWindowUpdate的关系。    t.framer.writeWindowUpdate     go t.controller()//用于发送控制消息给服务端}客户端writeWindowUpdate两个时机，最终作用到server端对应的handleWindowUpdate：1、newHTTP2Client->framer.writeWindowUpdate2、io.ReadFull(s1, p)->http2Client.updateWindow->t.framer.writeWindowUpdate

Client: Create Client Data Flow

Function: Newstream
Process:
1. Create Stream:newstream
2. FC inflow for receiving flow control
3. Dec=recvbufferreader for receiving data cache
4. Add the newly created stream to Activestreams

Client: Write Data

Function: Write
Process:
1. Get the Send Data permission from S.sendquotapool.acquire (), T.sendquotapool.acquire ()
2, get write permission from T.writablechan. (The Writablechan is used to control write serialization.) The write represents the release lock, and the read represents the acquire lock. ）
3. T.framer.writedata send data to the server

Client: Read data

function: Reader
Process:
1. Get Setting Frame
2. Loop to get all the frames and distribute them to the corresponding stream.

Service side

Similar to the client code is no longer detailed. The main difference is handlestreams, the method used to receive client requests.

Data Flow processing:
1, handledata receive data, data through Stream.Write write Stream.buf

2, Operateheaders handle parameter is the corresponding data receive processing policy. Read the data written in the STREAM.BUF to handle it accordingly.
One of the SERVER.GO implementations is:
2.1, PROCESSUNARYRPC processing process: Receive message p.recvmsg, processing Md. Handler, send response s.sendresponse, reply status T. Writestatus
2.2, PROCESSSTREAMINGRPC processing process: the establishment of Serverstream-SD. Handler-T.writestatus

3, the handler in step 2 is Registerservice injected.