Allen

@mreiferson I'm sorry it took so long to reply. I made a few changes： 1. Check the ’r.stopFlag‘ before add a new connection to ’r.connections‘ ， so we can prevent...

so, maybe we can add `stopChan` to notify `lookupdLoop` and `single-connection reconnects` quickly exit.

https://github.com/Allenxuxu/gev/tree/connector 这个分支有热血网友写过一些尝试，但是感觉还不是很完善。

@lvht 回调方式确实不利于写复杂的业务逻辑代码。 我开发 gev 的初衷也并不是为了来写业务逻辑，这样的异步框架更适合用来构建更为底层的基础设施，比如反向代理程序、消息队列等。 个人认为，这类 go 异步框架，使用更少的内存，速度更多，适用于一些有特殊需求的场景。 https://www.freecodecamp.org/news/million-websockets-and-go-cc58418460bb/ https://colobu.com/2019/02/23/1m-go-tcp-connection/

开发效率高，代码维护性好，rust我不了解，但开发效率，可维护性远比c/c++好。

go 相对于c/c++性能稍差，但是可维护性高。我尝试在特殊场景平衡两者，而且我并不认为回调会大幅降低可维护性。 gev 足够简洁，并不会带来多少维护负担。

> 这个issue可以开着做长期讨论 可以，听舒畅的👀

> > > 我有个疑问，net包里的TCPConn本身就是基于epoll进行封装的，作者为何基于原始epoll-go接口来写gev? > > > > > > net包基于epoll封装了自己的go网络模型，可以同步的方式达到异步的效果。gev是纯异步非阻塞的。在绝大部分场景没啥区别，且go网络模型更好用，但是如果是长连接且活跃的连接不多，异步网络模型只是hold住那些不活跃的连接，而go网络模型会分配goroutine，所以相对内存消耗会多一些，但真的多不了多少，简单算一个goroutine 2k，一百万才2G。。。 一百万连接的应用能有几个啊，哈哈哈 > > 我不是很能理解作者的意图。goroutine的benchmark我们在1.5版本的时候就做过，那个时候goroutine所占用的内存就已经相当相当少了，使用者几乎不用做任何优化，其实从官方说法上就能知道：goroutine几乎不会有内存瓶颈。 https://colobu.com/2019/02/23/1m-go-tcp-connection/

> 协成多了cpu在调度上花费很多，目前正在做一个长连接接入服务，一条连接有两个协成分别进行读写，没请求的话单机能抗400w连接，但是实际场景是一条连接维持20s左右，一条连接平均发1次请求，结果一台机子只能抗住30w连接，qps也才1w多，pprof跑了下，调度占了快一半了。我准备换成这个框架看下效果 😄对框架有疑惑的地方，欢迎提出👏

> 用websocekt,调用conn send发送消息失败,看了下是因为websocket消息的封装没在protocol的pack里面做,是在on message里面做的,这么做可能是因为websocket的发送是有messageType和data两部分,这个可以通过修改 protocal pack 和 unpack函数的实现来做吧 websocket 相关的，我们在另一个 issue 下讨论，这个 issue 保留讨论异步相关的。 ➡️ https://github.com/Allenxuxu/gev/issues/33