使用广播和带有ack的UDP（我们必须使用它，因为它支持现有系统）。
当 A 向 B 发送 msg 时，A 的计时器将开始运行，在超时之前它会再次向 B 发送相同的 msg。 B 作为许多系统的协调者，可能会迟到回复 A。此外，回复可能会在此过程中丢失。 A 可以随时向 B 发送任何消息。
我们如何降低 A 在 B 的 ack 到达 A 之前再次重新发送 B msg 的危险（我想解决是不可能的），这样 A 可能会将 msg 注册为失败（在重新发送两次之后）然后 B 的 ack 到达 A？
【问题讨论】：
标签： networking udp protocols broadcast
这实际上是广播，即一对多传输吗？听起来不像是纯粹的广播，因为您提到了每个接收器的重传决定。所以我会假设你可以独立地向每个接收者发送数据包。
您可以通过借鉴 TCP 的概念来构建良好的可靠性机制。 TCP 具有最通用和最陈旧的解决方案 - 它处理乱序重组，并且可以扩展到具有高延迟的高带宽（使用 ACK 窗口），并且对通道条件具有一定的适应性。
根据您正在做的事情，这可能是矫枉过正。相反，您可以借鉴 USB，它在数据包传递和确认方面也具有可靠性和消歧机制。但它一次只能处理一个未完成的数据包（例如窗口大小 == 1），并且无法处理无序交付，如果您有高带宽或高延迟要求，这将成为主要的性能限制因素。
在任何一种情况下，您的总体超时（用于向应用层发出传递失败的信号）都应该很长，以至于您在正常操作期间不会遇到它。例如，TCP 实现将等待 15 秒以上以放弃交付并向应用层发出问题信号。
除了基本的一次一包交付之外，设计任何东西都需要认真的协议设计和 QA 才能做到正确。角落案例很难命中。如果您的要求很重要，您需要聘请一些可靠的网络协议工程师，或者想办法使用现有的解决方案，例如 TCP！
另请参阅What do you use when you need reliable UDP? 的相关讨论。
【讨论】：
应用程序 B 需要编写成高优先级、更可取的实时调度线程等待来自应用程序 A 的数据包。当 B 收到一个数据包时，将有效负载复制到内存锁定的循环缓冲区中并立即返回轮询套接字。然后让应用程序 B 中的业务级逻辑从循环缓冲区中读取以进行实际处理。
【讨论】：