FULI

ReadTimeout是deadline，是绝对值，每次都需要SetReadDeadline(time.Now().Add(timeout))

你需要检查下client library有没有bug， 服务器端是经过大量用户良好测试的。

你把问题和相关资料，发我邮箱[email protected]，我空了回复。

后面文档说明一下不能并发

为什么不用NewConn传入拨好的udpconn呢

真的好难啊，windows

写法参考benchmark

poll vs epoll。 需要两个数据结构：一个按sn排序，另一个按照timeout排序，这样才能既满足fastack/ack的需要，也能满足RTO的需要。但timeout如果用离散存储结构，根据测试： ``` BenchmarkLoopSlice-4 2000000000 0.39 ns/op BenchmarkLoopList-4 100000000 54.6 ns/op ``` 如果用离散内存结构，那么必须 54.6* logN > 0.39*N 的时候，才是一个划算的改动。（假设你的数据结构查询是O(logN). polling的问题我可以尝试优化一下，但我估计不会有大的提升，假如包的到达在时域上是均匀的，那么每个timeout在时域上也是均匀分布的，也就是说，timeout的时钟触发也是均匀的，比如在一个200ms的时延的网络上存在1024个等待确认的包，且20%丢包率。下一个timeout 的平均触发时延应该就是 (200ms/1024) * (1/20%) = 0.9765625ms，1/20% = 5即下一个丢包的位置。实际可能会更加频繁的触发flush()

第二点的原版minrto我不知道你说的是kcp.c的还是kcp-go的，这个不会有影响，RTO的计算方式的一个下界，实际RTO是远大于“等待几毫秒”的。

https://github.com/xtaci/kcp-go/tree/auxdata 这个是做过数据结构优化的，去掉了整个队列的polling遍历，但我测过，没什么用，如同上面的数据分析一样，在队列大小只有1K这个级别时，甚至cpu使用率还比用朴素队列方法高。