netpoll
netpoll copied to clipboard
cloudwego
SetIdleTimeout调用SetKeepAlive的原因？
Connection接口中SetIdleTimeout的具体实现是调用了SetKeepAlive，我的理解是连接的空闲时间超过了Idle timeout后连接被关闭，但是KeepAlive应该是定期发送维持连接存活的报文，怎么能实现超过空闲时间后连接被关闭呢？
确实，踢空闲连接和 keep alive 没什么关系，踢掉空闲连接需要类似于 timer 的东西来支持，可以参考 muduo 书的 7.10 使用时间轮来踢
确实，踢空闲连接和 keep alive 没什么关系，踢掉空闲连接需要类似于 timer 的东西来支持，可以参考 muduo 书的 7.10 使用时间轮来踢
Do you have an example of this implementation we can use as a workaround in the meantime?
确实，踢空闲连接和 keep alive 没什么关系，踢掉空闲连接需要类似于 timer 的东西来支持，可以参考 muduo 书的 7.10 使用时间轮来踢
Do you have an example of this implementation we can use as a workaround in the meantime?
You may refer to http://www.cs.columbia.edu/~nahum/w6998/papers/ton97-timing-wheels.pdf.
And Google something like heap-based timer, timing-wheel, etc.
其实就是 SetReadDeadline，timing-wheel 不够精确、tick间隔越低越精确但是就可能empty loop更多，所以并不是很划算，定时器这种优先级队列场景还是 heap timer 更好些。有兴趣可用参考下我这的实现：
https://github.com/lesismal/nbio/blob/master/conn_unix.go#L223
其实就是
SetReadDeadline，timing-wheel 不够精确、tick间隔越低越精确但是就可能empty loop更多，所以并不是很划算，定时器这种优先级队列场景还是 heap timer 更好些。有兴趣可用参考下我这的实现： https://github.com/lesismal/nbio/blob/master/conn_unix.go#L223
评论区出人才
其实就是
SetReadDeadline，timing-wheel 不够精确、tick间隔越低越精确但是就可能empty loop更多，所以并不是很划算，定时器这种优先级队列场景还是 heap timer 更好些。有兴趣可用参考下我这的实现： https://github.com/lesismal/nbio/blob/master/conn_unix.go#L223评论区出人才
早期用的自实现的heap timer，但其实用在deadline这种超时后的回调只是close的fast callback场景，标准库timer也是足够了，所以把早期版本自实现的heap timer废弃了，现在用的是标准库timer，之前的链接已经失效了，新的： https://github.com/lesismal/nbio/blob/master/timer/timer.go#L46
另外，tcp keepalive和应用层的keepalive是有区别的，之前gnet里有人问、也聊过这个： https://github.com/panjf2000/gnet/issues/332#issuecomment-1066725834
连接少的场景其实都没有设置这个的必要，所以考虑的场景至少也是上万连接的场景。而上万连接对象时，维护 idle time 的代价可能会非常高。这也是为什么一直没实现的原因。
即便用go timer，上万的timer在go runtime中，且还需要不停modtimer（因为连接会有新读写），代价也是很大的。
