2

考虑自定义网络协议。此自定义协议可用于从基于 .NET 的中央工作站通过 LAN 控制机器人外围设备。（如果很重要，机器人正忙于在芯片生产环境中移动晶圆厂）。

  • 对话中只有 2 方：.NET 站和机器人外围板
  • 机器人端只能接收请求和发送响应
  • .NET 端只能发起请求和接收响应
  • 每个请求总是应该有一个响应
  • 随后的请求可以一个接一个地紧跟，无需等待响应，但永远不会超过同时服务请求的固定限制（例如 5 个）

我与我的朋友（他拥有设计，我作为旁观者讨论过这件事）就所有好的细节和想法进行了详尽的讨论。在讨论结束时，我们对错过超时有强烈的分歧。我朋友的论点是双方的软件应该无限期地等待。我的论点是任何网络协议总是需要超时。我们根本无法达成一致。

我的一个理由是，如果发生任何故障，无论付出什么代价，你都应该“快速失败”，因为如果无论如何已经发生故障，恢复成本将继续与接收有关故障信息所花费的时间成正比增长。说在 LAN 上 1 分钟后，您绝对应该停止等待并发出一些警报。

但他的论点是，恢复应该包括修复失败的部分（在这种情况下是恢复网络连接），即使需要花费数小时才能确定网络丢失并修复，软件应该立即透明地继续运行重新连接 LAN 电缆后。

在这次讨论之前，我永远不会认真考虑永恒的协议。

哪一方的论点是正确的？“快速失败”还是“永不失败”？

编辑：失败的例子是通信丢失，通常由 TCP 层检测到。这部分也进行了讨论。如果 TCP 层返回错误，更高的自定义协议层将重试发送，并且没有关于它的参数。问题是：让下层继续尝试多久？

编辑接受的答案：答案比 2 个选择更复杂：“最常见的方法是永远不要放弃连接，直到实际尝试发送失败并确认连接已长期丢失。要计算连接已长期丢失，请使用心跳，但请保持损失年龄仅用于此确认，不用于立即警报“。

示例：当进行 telnet 会话时，您可以永远保持终端运行，并且您永远不知道在按 Enter 之间是否存在可被较低级别例程检测到的故障。

4

2 回答 2

1

在...的场景中

  • 控制器已发送请求
  • 机器人未收到请求
  • 网络故障

...然后请求已发送，但已丢失并且永远不会到达。

因此，当网络恢复时，控制器必须重新发送请求：控制器不能简单地永远等待响应。

于 2009-11-28T03:23:41.413 回答
0

我更喜欢您的“快速失败”方法，但我认为您已经发现，这是非常优先的。

我使用的思科设备的工作方式非常相似——你发送请求，他们就会响应。（通过 telnet。）问题出在网络出现故障时：我失去了 TCP 连接。但是，在尝试发送数据之前，任何一方都不会关闭该连接，并且由于 cisco 侧很少这样做，因此它永远不会关闭。更糟糕的是，您一次只能有 1 个连接，因此如果出现网络故障，您将被锁定。（它们可以重置，但这只是一件麻烦事。）

现在，要测试网络连接，您需要某种 ping，只是“你还在吗？” - 许多协议都这样做，例如 AIM 和 IRC。但是这些 ping 会消耗带宽，具体取决于您发送它们的频率。

那么，错误检测值得带宽成本吗？ping 到底需要多大？我会说您应该能够将其设置为 <50 个八位字节/ping，并且您可以每隔 10 秒、30 秒、1 米 ping 一次，类似的，我会说这是非常值得的。越早知道自己有问题越好。如果软件本身可以使用这些 ping 来知道它失去了连接并自动重新建立联系，我会说这很好，就像“计算机，治愈你自己”一样，并且为操作员减少了麻烦。

If you're using TCP/IP, it can do this automatically for you -- see TCP Keepalives. Alternatively, you can do it within your application's protocol, as AIM & IRC do.

于 2009-11-28T03:37:00.353 回答