如何不用心跳包检测TCP连接断开

frank529 2012-05-17 10:27:07

TCP keepalive不行，因为必须socket长时间没有收发数据才会发keepalive包，而我的程序有可能一直在发数据。TCP有个超时重传机制，应该是可以通过重传多次失败知道连接断开的，但是不知道应用层如何获取连接断开的信息？还请高人指点

...全文

588 9 打赏收藏转发到动态举报

写回复

用AI写文章

9 条回复

切换为时间正序

请发表友善的回复…

发表回复

开发者说 2012-05-17

打赏
举报

直接close掉socket

qq120848369 2012-05-17

打赏
举报

[Quote=引用 8 楼的回复:]

引用 7 楼的回复:
还有,我觉得你混淆了一个概念, 即便是阻塞接口也不是等待ACK之后send才返回的。服务端唯一能做的就是正常的时候发送数据，失败的时候关闭socket，其他的都无法保证。逻辑必须做在客户端。

现在问题就是我怎么知道数据发出去对端有没有ACK？网络断连了，进行send、select返回值都是正常的，这个你可以写个程序测试下。
[/Quote]

我不是说了吗？服务端没法保证，服务端只会在发送之后某一刻接受到ACK或者RST，那么close就行了。
只有客户端知道自己接受了多少数据，逻辑是做在客户端的。服务端只知道你连接上来，你要多少偏移量开始的数据，然后就开始发，TCP保证数据可靠，足够了。至于服务器到底发出去多少，服务器不care，客户端care。

frank529 2012-05-17

打赏
举报

[Quote=引用 7 楼的回复:]
还有,我觉得你混淆了一个概念, 即便是阻塞接口也不是等待ACK之后send才返回的。服务端唯一能做的就是正常的时候发送数据，失败的时候关闭socket，其他的都无法保证。逻辑必须做在客户端。
[/Quote]

现在问题就是我怎么知道数据发出去对端有没有ACK？网络断连了，进行send、select返回值都是正常的，这个你可以写个程序测试下。

qq120848369 2012-05-17

打赏
举报

还有,我觉得你混淆了一个概念, 即便是阻塞接口也不是等待ACK之后send才返回的。服务端唯一能做的就是正常的时候发送数据，失败的时候关闭socket，其他的都无法保证。逻辑必须做在客户端。

qq120848369 2012-05-17

打赏
举报

[Quote=引用 5 楼的回复:]

引用 4 楼的回复:
引用 3 楼的回复:

引用 2 楼的回复:
向客户端写失败就踢掉客户端。
客户端需要有重连逻辑。

TCP keepalive你还是忘掉吧，它与我们毫无关系。

非阻塞写网络断连也不会失败

你检查返回值了？

对端不ACK你怎么会成功？

调用send肯定要判断返回值啊，非阻塞send只要缓冲区没满返回就是正确，不管有没……
[/Quote]

非阻塞不代表就没有ACK了,你非阻塞返回了,数据已经出去了,对端回复RST将会导致你的socket可读或者出错,都可以select监听的到,意识到错误就踢掉客户端.

客户端应该自己控制已接受数据量, 下一次上线向服务器请求断点续传, 服务器是没法记录这个已发送量的, 客户端实际拿到的才是真实的.

frank529 2012-05-17

打赏
举报

[Quote=引用 4 楼的回复:]
引用 3 楼的回复:

引用 2 楼的回复:
向客户端写失败就踢掉客户端。
客户端需要有重连逻辑。

TCP keepalive你还是忘掉吧，它与我们毫无关系。

非阻塞写网络断连也不会失败

你检查返回值了？

对端不ACK你怎么会成功？
[/Quote]

调用send肯定要判断返回值啊，非阻塞send只要缓冲区没满返回就是正确，不管有没有收到ACK

qq120848369 2012-05-17