考虑自定义网络协议。此自定义协议可用于从基于.NET的中央工作站控制LAN上的机械手外围设备。 （如果重要的话，机器人正忙于在芯片生产环境中移动晶圆厂。）
我与我的朋友（他拥有设计，我已经讨论了作为旁观者的事情）进行了详尽的讨论，讨论了所有不错的细节和想法。在讨论结束时，我们对缺少超时有很强的分歧。我朋友的论点是，双方的软件应该无限期地等待。我的论点是任何网络协议总是需要超时。我们根本不可能同意。
我的一个理由是，如果出现任何故障，您应该“快速失败”任何成本，因为如果已经发生故障，恢复成本将继续与接收故障信息所花费的时间成比例增长。在局域网上1分钟后说你肯定应该停止等待并且只是发出一些警报。
但他的论点是，恢复应该包括修复失败的内容（在这种情况下恢复网络连接），即使需要花费数小时才能确定网络丢失和修复，软件应该只是透明地继续重新连接LAN电缆后立即运行。
在讨论之前，我永远不会认真考虑永恒的协议。
论证的哪一方是对的？ “快速失败”或“永不失败”？
编辑：失败的示例是通信丢失，通常由TCP层检测到。这部分也进行了讨论。在TCP层返回错误的情况下，较高的自定义协议层将重试发送，并且没有关于它的争论。问题是：允许较低级别继续尝试需要多长时间？
编辑已接受的答案： 答案比2个选择更复杂：“最常见的方法是永远不会放弃连接，直到实际尝试发送失败并且确认连接长时间丢失。要计算连接长时间丢失使用心跳，但保持年龄仅对此确认丢失，而不是立即报警“。
示例：当进行telnet会话时，您可以永久保持终端，并且您永远不知道在点击Enter之间是否存在可由较低级别例程检测到的故障。
答案 0 :(得分：1)
在......的场景中
...然后请求已发送，但已丢失且永远不会到达。
因此，当网络恢复时，控制器必须重新发送请求：控制器不能简单地等待响应。
答案 1 :(得分：0)
我更喜欢你的“快速失败”方法，但正如我认为你发现的那样，这是非常优惠的。
我工作的思科设备工作非常相似 - 您发送请求，他们回应。 （通过telnet。）问题是当网络出现故障时：我松开了TCP连接。但是，在尝试数据发送之前，任何一方都不会关闭该连接，并且由于cisco方很少这样做，因此它永远不会关闭。更糟糕的是，您一次只能连接一个，所以如果网络出现故障，您就会被锁定。 （它们可以重置，但这只是一个麻烦。）
现在，要测试一个网络连接，你需要某种ping，只是“你还在吗？” - 许多协议都这样做，例如AIM和IRC。但是这些ping会花费带宽，具体取决于你发送它们的频率。
那么，错误检测是否值得带宽成本？ ping真的需要多大？我会说你应该能够达到<50个八位字节/ ping，你可以像每10秒，30秒，1米一样ping一次，我会说它非常值得。你越早知道自己有问题就越好。如果软件本身可以使用这些ping知道它丢失了连接并自动重新建立联系，我会说这很好，就像“计算机，治愈你自己”，并为操作员减少麻烦。 / p>
如果您正在使用TCP / IP，它可以自动为您执行此操作 - 请参阅TCP Keepalive。或者，您可以在应用程序的协议中执行此操作，如AIM＆amp; IRC做。