@
ufo5260987423 谢谢老哥耐心回复 在这里解释下你提出的几点:
关于 2 这个 srv 一开始的设计打算就是内置一个 http api 来提供使用者调用,而且 http 的是用 go 的标准库实现的也没必要引入了什么外部包了
3 、关于目录命名问题,protocol 下的代码主要负责对 tcp 数据流的封包和解包,我认为这和 protocol (协议)相关所以这样命名自认为没什么问题;关于目录架构问题,由于 go 规定每个文件夹只能有 1 个包名,所以为了区分各个文件的组织架构,只能通过文件夹区分,而且一开始的目标是完成基本的功能,一些包的功能模块只写了最基本的功能,所以导致一些目录下的代码文件只有一两个,去年写完这些功能后,打算以“连接数达到操作系统所支持的最高数的情况下能长时间稳定运行,并且保证并发性能”作为验收标准,最后经过一些测试,满负荷运行的情况下,单机的 qps 在 1000 左右,也算是达到了目标,后面因为想玩的 3a 出了就打游戏去了,搁置了没继续往下写,结果一搁置就快半年了。。。
4 、这个确实有问题,每次写完一大坨就想着保存,但总是涉及到了好几个模块的功能,自己也记不清了所以 commit 写的很敷衍,完全就是有了些完成度想“存个档”而已