在 MFC 应用程序中侦听 UDP 或切换到 TCP答案

【问题标题】：Listening UDP or switch to TCP in a MFC application在 MFC 应用程序中侦听 UDP 或切换到 TCP
【发布时间】：2012-10-10 19:24:02
【问题描述】：

我正在编辑旧版 MFC 应用程序，我必须添加一些基本的网络功能。操作方必须接收一个简单的指令（数字 1、2、3、4...）并根据它做一些事情。客户希望延迟尽可能快，所以我自然决定使用数据报 (UDP)。

但是阅读各种资源让我感到困惑。我无法在 MFC 中收听 UDP 套接字 (CAsyncSocket)，只能调用 Receive 阻止并等待。阻止用户界面并不是真正的聪明。所以我想我可以使用一些线程技术，但是由于我对 MFC 的经验并不多，应该如何实现呢？

问题的另一部分是我应该这样做，还是恢复到 TCP，考虑可靠性和实施问题。我知道 UDP 不可靠，但它到底有多不可靠？我读到它的速度提高了 50%，这对我来说非常重要。

我使用的参考资料： http://msdn.microsoft.com/en-us/library/09dd1ycd(v=vs.80).aspx

【问题讨论】：

什么延迟？是发送命令还是接收对命令的响应？
发送命令。远程应用程序应在发出命令后尽快开始工作。
命令的顺序是否相关？
您可能会发现此线程很有用“什么时候适合使用 UDP 而不是 TCP？” -stackoverflow.com/questions/1099672/…
命令的顺序不会导致应用崩溃，也不会在短时间内出现，所以不会混淆。但是，如果一个命令丢失，下一个命令会使应用程序处于当前不需要的状态（状态类似于播放、停止和暂停）。不过，如果我选择了，如何实现 UDP 监听？

标签： c++ networking tcp network-programming udp

【解决方案1】：

TCP 中的大部分“延迟”是建立初始连接所需的握手。

如果您的客户端应用程序要从您的 MFC 应用程序请求大量命令，那么 TCP 是不费吹灰之力的。客户端打开一个 TCP 连接并保持打开状态。

如果您的 MFC 应用程序要接收来自不同客户端的大量临时命令，那么 UDP 可能是合适的，但您必须权衡节省 TCP 握手的微小成本是否值得命令可能由于 UDP 将其丢弃，根本不会发生。

【讨论】：

命令将来自一个地方。但是“服务器”会同时将它们发送给更多的客户端。成本有多低？
如果你使用 TCP，不要忘记禁用 Nagle 的算法（通过 setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, ...) 或者每次 send() 你会得到大约 200 毫秒的延迟打电话。
@JeremyFriesner - 当服务器没有为每个 send() 生成回复时，禁用 Nagle 很重要。在服务器回复每条传入消息的情况下，它不会产生任何影响。
@Roddy Nagle 在所有情况下都会有所作为。自己试试看。服务器的行为没有影响，因为当数据到达服务器时，客户端的 Nagle 算法已经增加了 200mS 的延迟。

【解决方案2】：

谢谢大家。综上所述，我决定尝试使用 UDP。至于我的实施问题，我自己找到了一个答案，这对我很有帮助，看起来它会让我的沟通井井有条。对于将来阅读或提出相同问题的人，两个简单的 CAsyncSocket 包装类：

http://www.codeproject.com/Articles/16581/Sending-Receiving-UDP-Datagrams-with-MFC-s-CAsyncS

【讨论】：

【解决方案3】：

为什么不能在 MFC 中使用 CAsyncSocket 监听 UDP 套接字？我有这样做的代码。使用端口号、SOCK_DGRAM 和 FD_READ 作为参数调用 Create()。 OnReceive() 应该被自动调用。如果没有，您可以通过使用 FD_READ 参数调用 AsyncSelect() 来刺激它。

【讨论】：