动手写RPC框架 - GeeRPC第一天服务端与消息编码 | 极客兔兔 #91

geektutu · 2020-10-08T02:43:07Z

https://geektutu.com/post/geerpc-day1.html

7天用 Go语言/golang 从零实现 RPC 框架 GeeRPC 教程(7 days implement golang remote procedure call framework from scratch tutorial)，动手写 RPC 框架，参照 golang 标准库 net/rpc 的实现，实现了服务端(server)、支持异步和并发的客户端(client)、消息编码与解码(message encoding and decoding)、服务注册(service register)、支持 TCP/Unix/HTTP 等多种传输协议。第一天实现了一个简单的服务端和消息的编码与解码。

gaodansoft · 2020-10-23T01:51:33Z

非常感谢这个教程

geektutu · 2020-10-24T06:14:06Z

@gaodansoft 笔芯~

JYFiaueng · 2020-11-04T05:51:45Z

说点什么，那当然是赞了😏

geektutu · 2020-11-04T12:25:03Z

@JYFiaueng 感谢认可~ 😯

w4096 · 2020-12-25T08:07:42Z

请问下面这一行是什么意思呢？

var _ Codec = (*GobCodec)(nil)

geektutu · 2020-12-25T15:53:23Z

请问下面这一行是什么意思呢？
var _ Codec = (*GobCodec)(nil)

@wy-ei 参考 7days-golang 有价值的问题讨论汇总贴

wangwenjunfromlanzhou · 2021-01-06T08:19:57Z

写的太好了

geektutu · 2021-01-11T17:07:54Z

写的太好了

@wangwenjunfromlanzhou 感谢认可~ 😊😊😊

leigexiaohuozi · 2021-03-09T14:37:55Z

直接这样可以吗defer func() { conn.Close() }() 而不是 defer func() { _ = conn.Close() }()

IAOTW · 2021-03-13T08:07:19Z

client.sending.Lock()
defer client.sending.Unlock()
client.mu.Lock()
defer client.mu.Unlock()
问题1：不太理解为啥terminateCalls方法，需要sending和mu两把锁，而注册call和删除call，只需要mu锁？
问题2：当client的某一个字段比如sending Lock()时，是不是在unlock()之前，这个client对象的sending字段是线程安全的，不会被其他线程或协程访问到吗？

Euraxluo · 2021-03-13T11:57:39Z

@leigexiaohuozi
直接这样可以吗defer func() { conn.Close() }() 而不是 defer func() { _ = conn.Close() }()

应该是 defer conn.Close()

wilgx0 · 2021-03-16T08:07:28Z

再一次被大佬精湛的技术按在地板上摩擦

XiaoyeFang · 2021-03-19T10:47:22Z

刚才照着大佬的代码敲了一遍，发现main函数中的循环发送请求如果不执行readBody或者执行出错，我们的sendResponse就会只打印其中的两三个请求，有时甚至还会报EOF错误：

代码如下：

     for i := 0; i < 5; i++ {
		h := &codec.Header{
			ServiceMethod: "Foo.Sum",
			Seq:           uint64(i),
		}
		_ = cc.Write(h, fmt.Sprintf("geerpc req %d", h.Seq))
		_ = cc.ReadHeader(h)
		//var reply string
		//_ = cc.ReadBody(&reply)
		//log.Println("reply:", reply)
	}

是什么原因阻塞了我们的请求呢，又或者执行什么超时导致主线程退出了

XiaoyeFang · 2021-03-19T10:52:08Z

@wy-ei
请问下面这一行是什么意思呢？
var _ Codec = (*GobCodec)(nil)

就是检查结构体是否实现了这个接口

wilgx0 · 2021-03-23T06:57:07Z

@XiaoyeFang
刚才照着大佬的代码敲了一遍，发现main函数中的循环发送请求如果不执行readBody或者执行出错，我们的sendResponse就会只打印其中的两三个请求，有时甚至还会报EOF错误：

代码如下：
     for i := 0; i < 5; i++ {
		h := &codec.Header{
			ServiceMethod: "Foo.Sum",
			Seq:           uint64(i),
		}
		_ = cc.Write(h, fmt.Sprintf("geerpc req %d", h.Seq))
		_ = cc.ReadHeader(h)
		//var reply string
		//_ = cc.ReadBody(&reply)
		//log.Println("reply:", reply)
	}
是什么原因阻塞了我们的请求呢，又或者执行什么超时导致主线程退出了

因为你的主协程发送完5次请求后就退出了此时运行服务器的协程还没有打印完这5次请求也退出了

liyuxuan89 · 2021-04-05T03:01:13Z

我直接使用的day-1的代码，在windows上可以运行，到我虚拟机的ubuntu上，会阻塞在readRequestHeader，这可能是什么原因呢？

liyuxuan89 · 2021-04-05T05:50:02Z

运行到箭头就阻塞了，不知道为啥？

第一个箭头应该是option，第二个是header和body，client的request应该是发出去了？
在windows上没有问题。

liyuxuan89 · 2021-04-05T06:58:42Z

geektutu/7days-golang#34 不知道是不是这个问题

yangchen97 · 2021-04-08T06:42:18Z

我想问问如果不在header里指定body长度，会有粘包拆包的问题吗？

wilgx0 · 2021-04-08T07:08:50Z

@yangchen97
我想问问如果不在header里指定body长度，会有粘包拆包的问题吗？

json 字符串是有数据的边界的即 "{" 和 "}"所以这里并不会出现粘包的问题

tangwy01 · 2021-04-10T07:28:47Z

问下这行代码 // send options
_ = json.NewEncoder(conn).Encode(geerpc.DefaultOption) 是怎么跟server通讯把option发过去的啊，我看这个conn就是conn, _ := net.Dial("tcp", <-addr).

XiaoyeFang · 2021-04-13T11:22:56Z

@wilgx0

@yangchen97
我想问问如果不在header里指定body长度，会有粘包拆包的问题吗？

json 字符串是有数据的边界的即 "{" 和 "}"所以这里并不会出现粘包的问题

学到了

sam-lc · 2021-04-22T03:45:03Z

func NewGobCodec(conn io.ReadWriteCloser) Codec {
	buf := bufio.NewWriter(conn)
	return &GobCodec{
		conn: conn,
		buf:  buf,
		dec:  gob.NewDecoder(conn),
		enc:  gob.NewEncoder(buf),
	}
}

秒啊enc使用新的buffer，我一开始没注意使用的gob.NewEncoder(conn),导致可能会Option和header一起传过去，就会导致用body的解析为header就报错了

4ttenji · 2021-05-20T08:50:30Z

@sam-lc
func NewGobCodec(conn io.ReadWriteCloser) Codec {
	buf := bufio.NewWriter(conn)
	return &GobCodec{
		conn: conn,
		buf:  buf,
		dec:  gob.NewDecoder(conn),
		enc:  gob.NewEncoder(buf),
	}
}
秒啊enc使用新的buffer，我一开始没注意使用的gob.NewEncoder(conn),导致可能会Option和header一起传过去，就会导致用body的解析为header就报错了

请问这里可以解释一下，没太明白buf := bufio.NewWriter(conn)以及enc: gob.NewEncoder(buf),这两句

pieceof · 2021-05-27T03:02:52Z

感谢这个教程！实现这些项目我一个校招生终于春招找到了大厂工作！确实认认真真的熟悉了golang的编程思想和一些设计模式！十分感谢博主！

gu18168 · 2021-06-04T07:35:56Z

@4ttenji
@sam-lc
func NewGobCodec(conn io.ReadWriteCloser) Codec {
	buf := bufio.NewWriter(conn)
	return &GobCodec{
		conn: conn,
		buf:  buf,
		dec:  gob.NewDecoder(conn),
		enc:  gob.NewEncoder(buf),
	}
}
秒啊enc使用新的buffer，我一开始没注意使用的gob.NewEncoder(conn),导致可能会Option和header一起传过去，就会导致用body的解析为header就报错了
请问这里可以解释一下，没太明白buf := bufio.NewWriter(conn)以及enc: gob.NewEncoder(buf),这两句

encoder 因为是要往 conn 中写入内容, 这里文章中说明了要使用 buffer 来优化写入效率, 所以我们先写入到 buffer 中, 然后我们再调用 buffer.Flush() 来将 buffer 中的全部内容写入到 conn 中, 从而优化效率. 对于读则不需要这方面的考虑, 所以直接在 conn 中读内容即可.

z-learner · 2021-06-06T02:40:20Z

type GobCodec struct {
conn io.ReadWriteCloser
buf *bufio.Writer
dec *gob.Decoder
enc *gob.Encoder
}
codec.GobCodec on pkg.go.dev

cannot use (*GobCodec)(nil) (value of type *GobCodec) as Codec value in variable declaration: missing method

valiner · 2021-06-23T01:47:41Z

json包里面的encode 和 decode只是简单调用的net包的read和write，没有处理tcp的数据边界问题，这样不会有问题吗？

cyj19 · 2021-09-09T03:16:17Z

@XiaoyeFang
刚才照着大佬的代码敲了一遍，发现main函数中的循环发送请求如果不执行readBody或者执行出错，我们的sendResponse就会只打印其中的两三个请求，有时甚至还会报EOF错误：

代码如下：
     for i := 0; i < 5; i++ {
		h := &codec.Header{
			ServiceMethod: "Foo.Sum",
			Seq:           uint64(i),
		}
		_ = cc.Write(h, fmt.Sprintf("geerpc req %d", h.Seq))
		_ = cc.ReadHeader(h)
		//var reply string
		//_ = cc.ReadBody(&reply)
		//log.Println("reply:", reply)
	}
是什么原因阻塞了我们的请求呢，又或者执行什么超时导致主线程退出了

for循环后加一句time.Sleep(2 * time.Second)，在运行就可以看到5个请求都处理了，所以应该就是主程序提前退出导致的

cyj19 · 2021-09-09T03:33:21Z

@sam-lc
func NewGobCodec(conn io.ReadWriteCloser) Codec {
	buf := bufio.NewWriter(conn)
	return &GobCodec{
		conn: conn,
		buf:  buf,
		dec:  gob.NewDecoder(conn),
		enc:  gob.NewEncoder(buf),
	}
}
秒啊enc使用新的buffer，我一开始没注意使用的gob.NewEncoder(conn),导致可能会Option和header一起传过去，就会导致用body的解析为header就报错了

为什么会导致Option和Header一起传过去啊？使用bufio不是为了提高写入的效率吗？按理说使用gob.NewEncoder(conn)也是可以的呀

MoneyHappy · 2021-09-30T02:33:10Z

day1-codec/main/main.go
文件中这行代码
_ = cc.ReadHeader(h)
的作用是啥，没太理解😢

whitebluepants · 2021-10-17T07:29:55Z

@MoneyHappy
day1-codec/main/main.go
文件中这行代码
_ = cc.ReadHeader(h)
的作用是啥，没太理解😢

这里就是读取服务端返回的response的header

whitebluepants · 2021-10-17T07:31:07Z

@wilgx0

@yangchen97
我想问问如果不在header里指定body长度，会有粘包拆包的问题吗？

json 字符串是有数据的边界的即 "{" 和 "}"所以这里并不会出现粘包的问题

但是涉及到json的只有前面的option，后面的header和body是gob编解码的，会有上述的问题吗？

duanbiaowu · 2021-12-10T03:46:52Z

@wy-ei
请问下面这一行是什么意思呢？
var _ Codec = (*GobCodec)(nil)

将空值转换为 *GobCodec 类型
再转换为 Codec 接口
如果转换失败，说明 GobCodec 并没有实现 Codec 接口的所有方法

sportwxp · 2022-01-13T14:13:18Z

@wy-ei
请问下面这一行是什么意思呢？
var _ Codec = (*GobCodec)(nil)

这个是go的一个小技巧，确定GobCodec实现了Codec的接口，java里面不需要这一行

panjianning · 2022-02-03T09:07:30Z

学习一下，分享下我画的图解

AveryQi115 · 2022-03-15T08:33:39Z

我想请问一下main.go中这里client端通过Write函数写request之后就通过ReadHeader，ReadBody读取Response了。但是这里没有任何的同步点，是否可能出现client端ReadBody的时候server端还没有写入Response的情况呢？

for i := 0; i < 5; i++ {
		h := &codec.Header{
			ServiceMethod: "Foo.Sum",
			Seq:           uint64(i),
		}
		_ = cc.Write(h, fmt.Sprintf("geerpc req %d", h.Seq))
		_ = cc.ReadHeader(h)
		var reply string
		_ = cc.ReadBody(&reply)
		log.Println("reply:", reply)
	}

wjh791072385 · 2022-03-19T10:44:10Z

@Nicola115
我想请问一下main.go中这里client端通过Write函数写request之后就通过ReadHeader，ReadBody读取Response了。但是这里没有任何的同步点，是否可能出现client端ReadBody的时候server端还没有写入Response的情况呢？
for i := 0; i < 5; i++ {
		h := &codec.Header{
			ServiceMethod: "Foo.Sum",
			Seq:           uint64(i),
		}
		_ = cc.Write(h, fmt.Sprintf("geerpc req %d", h.Seq))
		_ = cc.ReadHeader(h)
		var reply string
		_ = cc.ReadBody(&reply)
		log.Println("reply:", reply)
	}

我尝试注销cc.write部分，会发现cc.ReadHeader会阻塞住，应该是conn内如果还没有写入数据的话，就不会读出来，直到有数据写入

AveryQi115 · 2022-03-20T05:35:23Z

@wjh791072385
@Nicola115
我想请问一下main.go中这里client端通过Write函数写request之后就通过ReadHeader，ReadBody读取Response了。但是这里没有任何的同步点，是否可能出现client端ReadBody的时候server端还没有写入Response的情况呢？
for i := 0; i < 5; i++ {
		h := &codec.Header{
			ServiceMethod: "Foo.Sum",
			Seq:           uint64(i),
		}
		_ = cc.Write(h, fmt.Sprintf("geerpc req %d", h.Seq))
		_ = cc.ReadHeader(h)
		var reply string
		_ = cc.ReadBody(&reply)
		log.Println("reply:", reply)
	}
我尝试注销cc.write部分，会发现cc.ReadHeader会阻塞住，应该是conn内如果还没有写入数据的话，就不会读出来，直到有数据写入

谢谢。我之前理解错了，conn应该是本身在client端和server端就有独立的数据缓冲区的，所以如果server端还没写入，client端这边就读不到就会被block

Sentiger · 2022-05-09T02:20:53Z

这里应该存在发送options的时候，服务端读取到options后面header的内容吧。导致再次读取后面的内容是不完整的，导致gob编码失败

callmePicacho · 2022-08-04T12:59:06Z

请教各位大佬一个问题，例如在 main.go 中，大量存在

_ = cc.Write(h, fmt.Sprintf("geerpc req %d", h.Seq))
_ = cc.ReadHeader(h)

像这样的返回值既然要抛弃，为何不直接写成这样呢？

cc.Write(h, fmt.Sprintf("geerpc req %d", h.Seq))
cc.ReadHeader(h)

ZAKLLL · 2022-08-23T03:39:15Z

当我尝试将Options 通过gob 编码发送后（服务端也使用 gob 解码）代码会在readRequestHeader 这个函数阻塞，这是为什么呢

main.go

	time.Sleep(time.Second)
	// 告知服务端本次链接的options
	//_ = json.NewEncoder(conn).Encode(server.DefaultOption)
	_ = gob.NewEncoder(conn).Encode(server.DefaultOption)

	//使用GobCodec 作为编辑编解码器
	cc := codec.NewGobCodec(conn)
	// send request & receive response
	for i := 0; i < 5; i++ {
		h := &codec.Header{
			ServiceMethod: "Foo.Sum",
			Seq:           uint64(i),
		}
		_ = cc.Write(h, fmt.Sprintf("geerpc req %d", h.Seq))
		_ = cc.ReadHeader(h)
		var reply string
		_ = cc.ReadBody(&reply)
		log.Println("reply:", reply)
	}

server.go

// ServeConn runs the server on a single connection.
// ServeConn blocks, serving the connection until the client hangs up.
func (server *Server) ServeConn(conn io.ReadWriteCloser) {
	defer func() { _ = conn.Close() }()
	var opt Option
	//if err := json.NewDecoder(conn).Decode(&opt); err != nil {
	if err := gob.NewDecoder(conn).Decode(&opt); err != nil {
		log.Println("rpc server: options error: ", err)
		return
	}
	if opt.MagicNumber != MagicNumber {
		log.Printf("rpc server: invalid magic number %x", opt.MagicNumber)
		return
	}
	f := codec.NewCodecFuncMap[opt.CodecType]
	if f == nil {
		log.Printf("rpc server: invalid codec type %s", opt.CodecType)
		return
	}
	server.serveCodec(f(conn))
}

yikuaibro · 2022-08-24T10:02:29Z

	_ = cc.Write(h, fmt.Sprintf("geerpc req %d", h.Seq))
	//_ = cc.ReadHeader(h)
    time.Sleep(5 * time.Second)
	var reply string
	_ = cc.ReadBody(&reply)

请教下，为什么注释掉ReadHeader，ReadBody会读不到东西，已经加了time.sleep，我理解的不是很清楚。

        &{Foo.Sum 0 } geerpc req 0
        reply:
        &{Foo.Sum 1 } geerpc req 1
        reply: geerpc resp 0
        &{Foo.Sum 2 } geerpc req 2
        reply:
        &{Foo.Sum 3 } geerpc req 3
        reply: geerpc resp 1
        &{Foo.Sum 4 } geerpc req 4
        reply:

simon12138-code · 2022-10-14T01:16:09Z

我出现了一个rpc server: invalid codec type 的报错，代码都是一摸一样的，请问这是哪里出现了问题，我调试出来主要是，没有接收到对应默认option的codectype

simon12138-code · 2022-10-14T02:45:28Z

已经解决， Option属性私有化了，非常的愚蠢

Drum-sys · 2022-10-17T09:14:21Z

@yikuaibro
_ = cc.Write(h, fmt.Sprintf("geerpc req %d", h.Seq))
//_ = cc.ReadHeader(h)
time.Sleep(5 * time.Second)
var reply string
_ = cc.ReadBody(&reply)

请教下，为什么注释掉ReadHeader，ReadBody会读不到东西，已经加了time.sleep，我理解的不是很清楚。
        &{Foo.Sum 0 } geerpc req 0
        reply:
        &{Foo.Sum 1 } geerpc req 1
        reply: geerpc resp 0
        &{Foo.Sum 2 } geerpc req 2
        reply:
        &{Foo.Sum 3 } geerpc req 3
        reply: geerpc resp 1
        &{Foo.Sum 4 } geerpc req 4
        reply:

数据格式|header|body|heder|body
Header 类型codec.header raply 类型string
cc.ReadBody(&reply) reply字符串应该不能解析到codec.header 结构体当中

把reply类型改一下 var reply codec.Header
_ = cc.ReadBody(&reply)
2022/10/17 17:08:36 start rpc server on [::]:62015
2022/10/17 17:08:37 reply: {Foo.Sum 0 }
2022/10/17 17:08:37 reply: { 0 }
2022/10/17 17:08:37 reply: {Foo.Sum 1 }
2022/10/17 17:08:37 reply: { 0 }
2022/10/17 17:08:37 reply: {Foo.Sum 2 }

sunviv · 2022-12-20T08:03:07Z

time.Sleep(time.Second) 为什么这地方要阻塞 1s

huty1998 · 2023-01-29T05:36:50Z

@panjianning

学习一下，分享下我画的图解

请问兄弟用的什么软件画的图？

Asolmn · 2023-05-17T16:49:11Z

@yikuaibro
_ = cc.Write(h, fmt.Sprintf("geerpc req %d", h.Seq))
//_ = cc.ReadHeader(h)
time.Sleep(5 * time.Second)
var reply string
_ = cc.ReadBody(&reply)

请教下，为什么注释掉ReadHeader，ReadBody会读不到东西，已经加了time.sleep，我理解的不是很清楚。
        &{Foo.Sum 0 } geerpc req 0
        reply:
        &{Foo.Sum 1 } geerpc req 1
        reply: geerpc resp 0
        &{Foo.Sum 2 } geerpc req 2
        reply:
        &{Foo.Sum 3 } geerpc req 3
        reply: geerpc resp 1
        &{Foo.Sum 4 } geerpc req 4
        reply:

解析是要安装顺序的，序列化的时候是先header然后body。读取的时候进行反序列化，所以也得安装序列化时候的顺序去解析，这就得先读取header再读body

SCUTking · 2023-11-29T08:53:05Z

@callmePicacho
请教各位大佬一个问题，例如在 main.go 中，大量存在
_ = cc.Write(h, fmt.Sprintf("geerpc req %d", h.Seq))
_ = cc.ReadHeader(h)
像这样的返回值既然要抛弃，为何不直接写成这样呢？
cc.Write(h, fmt.Sprintf("geerpc req %d", h.Seq))
cc.ReadHeader(h)

用_接收不会有警告为了好看

LumosLiang · 2023-12-14T08:50:24Z

@sunviv
time.Sleep(time.Second) 为什么这地方要阻塞 1s

同问，不过结合之前大佬们的回复，这里是解决粘包的问题吗？

callmePicacho · 2023-12-14T08:55:35Z

@sunviv
time.Sleep(time.Second) 为什么这地方要阻塞 1s

同问，不过结合之前大佬们的回复，这里是解决粘包的问题吗？

确保连接成功建立

taosu0216 · 2024-01-27T14:25:47Z

画的有点乱,但是大概逻辑是能理清了

TheWaveLab · 2024-02-24T07:52:56Z

@callmePicacho

@sunviv
time.Sleep(time.Second) 为什么这地方要阻塞 1s

同问，不过结合之前大佬们的回复，这里是解决粘包的问题吗？

确保连接成功建立

粘包是靠在header里指定body长度解决

TheWaveLab · 2024-02-24T07:56:14Z

@callmePicacho
请教各位大佬一个问题，例如在 main.go 中，大量存在
_ = cc.Write(h, fmt.Sprintf("geerpc req %d", h.Seq))
_ = cc.ReadHeader(h)
像这样的返回值既然要抛弃，为何不直接写成这样呢？
cc.Write(h, fmt.Sprintf("geerpc req %d", h.Seq))
cc.ReadHeader(h)

这个只是为了让IDE忽略没有错误处理的警告

TheWaveLab · 2024-02-24T07:58:51Z

@MoneyHappy
day1-codec/main/main.go
文件中这行代码
_ = cc.ReadHeader(h)
的作用是啥，没太理解😢

为了解决tcp粘包，一般报文设计都会有先是header，在里面指定后面body的长度，所以要先读取header，判断报文类型和后续要读取的长度等。其实这个写的不太严谨，这里应该需要判断错误的，而不是直接忽略。

yz627 · 2024-05-02T04:17:56Z

想请教一下，将header和body通过buffer缓冲一起进行发送，在client或server中进行读取的时候会出现粘包问题吗？这里header好像没有固定大小？

vito-go · 2024-05-08T10:10:01Z

想请教一下，将header和body通过buffer缓冲一起进行发送，在client或server中进行读取的时候会出现粘包问题吗？这里header好像没有固定大小？

Although the header and body are sent together, when the header and body are sent separately, the length of the bytes is marked. enc.countState.encodeUint(uint64(messageLen))

source code: go/src/encoding/gob/encoder.go

// writeMessage sends the data item preceded by an unsigned count of its length.
func (enc *Encoder) writeMessage(w io.Writer, b *encBuffer) {
	// Space has been reserved for the length at the head of the message.
	// This is a little dirty: we grab the slice from the bytes.Buffer and massage
	// it by hand.
	message := b.Bytes()
	messageLen := len(message) - maxLength
	// Length cannot be bigger than the decoder can handle.
	if messageLen >= tooBig {
		enc.setError(errors.New("gob: encoder: message too big"))
		return
	}
	// Encode the length.
	enc.countState.b.Reset()
	enc.countState.encodeUint(uint64(messageLen))
	// Copy the length to be a prefix of the message.
	offset := maxLength - enc.countState.b.Len()
	copy(message[offset:], enc.countState.b.Bytes())
	// Write the data.
	_, err := w.Write(message[offset:])
	// Drain the buffer and restore the space at the front for the count of the next message.
	b.Reset()
	b.Write(spaceForLength)
	if err != nil {
		enc.setError(err)
	}
}

geektutu added Gitalk /post/geerpc-day1.html labels Oct 8, 2020

动手写RPC框架 - GeeRPC第一天 服务端与消息编码 | 极客兔兔 #91

动手写RPC框架 - GeeRPC第一天 服务端与消息编码 | 极客兔兔 #91

Comments

geektutu commented Oct 8, 2020

gaodansoft commented Oct 23, 2020

geektutu commented Oct 24, 2020

JYFiaueng commented Nov 4, 2020

geektutu commented Nov 4, 2020

w4096 commented Dec 25, 2020

geektutu commented Dec 25, 2020

wangwenjunfromlanzhou commented Jan 6, 2021

geektutu commented Jan 11, 2021 • edited Loading

leigexiaohuozi commented Mar 9, 2021

IAOTW commented Mar 13, 2021

Euraxluo commented Mar 13, 2021

wilgx0 commented Mar 16, 2021

XiaoyeFang commented Mar 19, 2021

XiaoyeFang commented Mar 19, 2021

wilgx0 commented Mar 23, 2021

liyuxuan89 commented Apr 5, 2021

liyuxuan89 commented Apr 5, 2021

liyuxuan89 commented Apr 5, 2021

yangchen97 commented Apr 8, 2021

wilgx0 commented Apr 8, 2021

tangwy01 commented Apr 10, 2021

XiaoyeFang commented Apr 13, 2021

sam-lc commented Apr 22, 2021

4ttenji commented May 20, 2021

pieceof commented May 27, 2021

gu18168 commented Jun 4, 2021

z-learner commented Jun 6, 2021

valiner commented Jun 23, 2021

cyj19 commented Sep 9, 2021

cyj19 commented Sep 9, 2021

MoneyHappy commented Sep 30, 2021

whitebluepants commented Oct 17, 2021

whitebluepants commented Oct 17, 2021

duanbiaowu commented Dec 10, 2021

sportwxp commented Jan 13, 2022

panjianning commented Feb 3, 2022

学习一下，分享下我画的图解

AveryQi115 commented Mar 15, 2022

wjh791072385 commented Mar 19, 2022

AveryQi115 commented Mar 20, 2022 • edited Loading

Sentiger commented May 9, 2022

callmePicacho commented Aug 4, 2022

ZAKLLL commented Aug 23, 2022

yikuaibro commented Aug 24, 2022

simon12138-code commented Oct 14, 2022

simon12138-code commented Oct 14, 2022

Drum-sys commented Oct 17, 2022

sunviv commented Dec 20, 2022

huty1998 commented Jan 29, 2023

学习一下，分享下我画的图解

Asolmn commented May 17, 2023

SCUTking commented Nov 29, 2023

LumosLiang commented Dec 14, 2023

callmePicacho commented Dec 14, 2023

taosu0216 commented Jan 27, 2024

TheWaveLab commented Feb 24, 2024

TheWaveLab commented Feb 24, 2024

TheWaveLab commented Feb 24, 2024

yz627 commented May 2, 2024

vito-go commented May 8, 2024

动手写RPC框架 - GeeRPC第一天服务端与消息编码 | 极客兔兔 #91

动手写RPC框架 - GeeRPC第一天服务端与消息编码 | 极客兔兔 #91

geektutu commented Jan 11, 2021 •

edited

Loading

AveryQi115 commented Mar 20, 2022 •

edited

Loading