Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

连接断掉,conn的HandleChannel里的packet未处理给丢弃了 #14

Closed
zhaoyuexian opened this issue Jun 23, 2016 · 3 comments
Closed

Comments

@zhaoyuexian
Copy link

当客户端关闭连接的时候 , HandleChannel还在处理其中的Packet, 结果这个时候直接调用了Close,导致HandleChannel直接关闭不可用,这样就丢了其中的消息,能否在关闭的时候加个超时或者处理完再关闭

@gansidui
Copy link
Owner

确实,我想下怎么改比较好

@lesismal
Copy link

客户端应用层写入socket只是进入内核缓冲区,缓冲区、在途都未必能保证到达,客户端关闭后、服务端成功读取和处理前,客户端发出的数据也是有可能丢失在网络链路的,所以并不能保证到达、包括不能保证到达handle的chan中,所以保证这个剩余包的处理,意义不大。
另外,一个conn开三个协程比较浪费,可以改成两个,读协程读到一个处理一个,读失败再退出,这样既省了协程数量也能解决这个issue。处理速度阻塞了读取速度通常不必担心、那通常意味着生产者一方的生产速度过快了,而且即使放进单独的handle协程里,handle这个协程依然是串行的,加速收取读缓冲的意义不大。并且,如果需要异步处理,可以用各个模块的任务池进行异步消费,一样可以解决问题。

@gansidui
Copy link
Owner

客户端应用层写入socket只是进入内核缓冲区,缓冲区、在途都未必能保证到达,客户端关闭后、服务端成功读取和处理前,客户端发出的数据也是有可能丢失在网络链路的,所以并不能保证到达、包括不能保证到达handle的chan中,所以保证这个剩余包的处理,意义不大。
另外,一个conn开三个协程比较浪费,可以改成两个,读协程读到一个处理一个,读失败再退出,这样既省了协程数量也能解决这个issue。处理速度阻塞了读取速度通常不必担心、那通常意味着生产者一方的生产速度过快了,而且即使放进单独的handle协程里,handle这个协程依然是串行的,加速收取读缓冲的意义不大。并且,如果需要异步处理,可以用各个模块的任务池进行异步消费,一样可以解决问题。

非常认同你说的,这个package的初衷是为了快速搭建tcp服务程序,如果要在大型和的项目中,还要加入更多的功能才行。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants