处理TCP故障的正确机制是什么?

时间:2017-04-12 00:25:41

标签: c++ sockets tcp

我正在用c ++编写套接字程序。该程序在一组集群机器上运行。

我刚刚进入套接字编程,刚学会了如何发送和接收。我认为,在程序长时间运行期间,一些TCP连接可能会丢失。在这种情况下,需要平稳地重新连接服务器和客户端。

我想知道是否有一个众所周知的基本机制(或算法?协议?)来实现它。我发现有许多套接字错误代码具有不同的语义,这使我难以启动。

任何人都可以建议我可以学习的任何参考代码吗?

谢谢,

2 个答案:

答案 0 :(得分:3)

这并不复杂。只有两个对连接不致命的错误代码是:

  • EAGAIN / EWOULDBLOCK,实际上是相同数字的两个名称,意味着可以在一段时间后或select()/poll()/epoll()如此指示后重新尝试操作;
  • EINTR,这意味着中断了系统调用' - 再试一次。

所有其他人对此连接都是致命的,应该让你关闭它。

答案 1 :(得分:-1)

实际的特定错误代码无关紧要。如果您有活动的套接字连接,则读取或写入失败表示连接已断开。错误代码可能会给你一些解释,但现在有点太晚了。套接字消失了。它不复存在了。它不复存在。它是一个前插座。您可以使用错误代码提出一个丰富多彩的解释,但它只是一些小的安慰。无论具体原因是什么,但你的套接字已经消失,你必须处理它。

当使用非阻塞套接字时,有一些特定的返回码和errno值表明套接字仍然正常,但只是还没准备好读或写任何东西,你必须要专门检查和处理。这是唯一的例外。

此外,EINTR 通常并不一定意味着套接字真的坏了;所以这可能是另一个需要检查的例外。

一旦你有一个破损的套接字,唯一的一般设计原则(如果有的话)是你必须close()作为第一个业务订单。文件描述符完全没用。在那之后,完全取决于你接下来要做什么。对于这种情况,没有任何规则,刻在石头上。通常,应用程序会以某种形式或方式记录错误,或尝试进行另一个连接。一般由你决定要做什么。

关于唯一的#34;众所周知的基本机制"套接字编程中的显式超时。网络错误和故障不会总是被底层操作系统立即检测到。出现网络问题时,并不总是可以立即检测到。协议栈声明一个损坏的套接字可能需要几分钟,并给出一个错误指示。

因此,如果您正在编写特定应用程序的编码,并且您知道您应该在某个规定的时间范围内读取或写入某些内容,则常见的设计模式是编写显式超时,如果没有任何反应,则超时到期,假设套接字已损坏 - 即使您没有明确的错误指示 - close()它,然后继续执行下一步。