【问题标题】:UDP response received after timeout超时后收到 UDP 响应
【发布时间】:2014-11-10 08:42:46
【问题描述】:

我们有一个与服务器通信的 UDP 客户端。

服务器对每个请求都给出一个响应。

客户端发送请求,等待 5 秒得到响应。

如果在 5 秒内未收到服务器的响应 - 客户端假定数据包在网络中丢失(这是 UDP...),将报告写入日志,并发送下一个请求。

但是,有时我们的网络有任何延迟,服务器的响应会在 5 秒后出现。

让我们描述一下场景:

客户端发送了一个名为“X”的数据包。

5秒超时,客户端报“X”为丢包。

客户端发送了另一个名为“Y”的数据包。

服务器对“X”的响应现在到达客户端。

客户端看到响应与请求不兼容,将其报告到日志中。

客户端发送了另一个名为“Z”的数据包。

服务器对“Y”的响应现在到达客户端。

客户端看到响应与请求不兼容,将其报告到日志中。

这是一个无限循环!

我们能做什么?

【问题讨论】:

  • 你是说如果客户端收到的回复与最近的请求不一致,它会停止等待真正的回复(因此它不会等待整整 5 秒)?
  • 处理过程很少需要 6 秒或更长时间(我无法识别)。
  • 好的,但是我问的问题呢?您的客户是否在收到意外回复后立即发送新请求?
  • 是的。错误答案可能是任何其他错误/错误的结果。
  • 那么不要让客户端在收到无效回复后立即发送新请求。而是让它丢弃无效的回复,并等待 5 秒超时的剩余时间。

标签: sockets networking udp timeout


【解决方案1】:

许多基于 UDP 的协议都包含一个标识符,用于指示给定响应属于哪个请求。客户端选择标识符并将其作为请求的一部分发送到服务器,然后服务器在响应中回显它。这允许客户端将响应与请求相匹配,尤其是在您描述的情况下。如果客户端在继续前进后收到对X 的响应,它可以简单地忽略该响应。

【讨论】:

  • 是的 - 又名“序列号”:)
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-07-13
  • 1970-01-01
  • 1970-01-01
  • 2018-01-04
  • 2018-06-29
相关资源
最近更新 更多