C++ 套接字使用并发FTP传输接收错误数据

有一个讨厌的线程（客户端）正在等待来自远程设备（服务器）的事件。事件由专用网络通过TCP套接字接收（我必须分配一个静态IP）。该操作不是阻塞操作，而是轮询操作（

select

+

recv

）。对于特定操作，线程使用

CURL

库与设备启动

FTP

传输。然后，有时，我们接收的不是下一个正常操作，而是垃圾。这种行为可以在三台计算机中的两台上系统地复制。在其中一个设备上，如果设备直接通过网络端口连接，则它可以工作，但如果通过网络USB适配器（允许Internet连接），则无法工作。另一方面，在这种情况下，适配器在另一台计算机上工作得非常好。如果我们消除FTP传输，一切正常。该行为与使用的卷曲版本和最后一个版本7.40相同

我是这里的维护人员，有一个庞大的老项目，我几乎无法更改/重写东西，尤其是在这种情况下，这段代码显然已经运行了好几年（尽管有一些问题被指出），而且距离测试版只有近两个月的时间。但我必须解决这个问题，如果有必要，我会通过示例将操作从轮询更改为阻塞。其他同事已经看到了代码，

应用程序验证程序

没有检测到任何东西（不再），从recv接收到的缓冲区已经损坏，

Wireshark

说我们正在接收正确的数据包-没有！调试有点困难，因为这个庞大的“应用程序”没有调试设置，通过远程调试和一些“精心选择的”断点。。。错误行为消失了。我用了将近两周的时间尝试了大多数常见的（过去获胜的）方法，其余的方法看起来也不太有希望——而且它们都需要时间：1）直接调试其中一台计算机（如果调试可复制，并且在安装VS后，从服务器获取整个代码）——我不知道还应该尝试什么2）编写“正确的”代码在一个单独的项目（已经开始了）3）替代llvm构建（巨大的努力）

如果您有任何想法，我将很高兴对任何澄清要求作出反应

编辑 我们在一个最小的测试程序中再现了这种情况。这是通过三台计算机的两台计算机上的USB网络适配器实现的。 我们通过TCP套接字从设备中获得两个命令。我们只读取第一个（1字节），使用CURL库进行FTP传输，然后读取另一个（7字节），但只有垃圾。如果我们在读取第二个命令的同时切换FTP调用，那么一切都很好，即使是在无休止的循环中。Wireshark显示数据（7个字节）是正确的，因此很明显，在FTP传输过程中发生了一些事情。但是它如何影响不相关的套接字呢？ 当前步骤是识别损坏套接字的CURL调用

编辑2

---

我们没有准确识别脏卷发呼叫，因为。。。这不是一个固定的点。我们通过

recv（…，MSG_PEEK）

和跟踪来进行识别，有时它可以位于两条

printf

指令之间，尽管它位于相同的代码区域。IMHO，这只可能是因为一些CURL-connect调用产生了另一个线程（名为

_SockAsyncThread@4

，显然是Windows内部使用的），这可能会改变套接字的堆栈。通过在某些地方添加

睡眠（1500）

。。。它起作用了。64位版本也有同样的“不工作”行为。虽然它从不与CURL一起工作，但通过将其替换为

FtpGetFile

，它可以在循环中工作，但有一个例外。。。第一次呼叫：（.我的想法是“D-Link DUB-E100 USB 2.0快速以太网适配器”的驱动程序中存在一些严重问题（顺便说一句，最新的Windows 7版本与Vista one相同）。在我看来，一个解决办法似乎是先读取套接字上的通知，然后再处理它们。或者可能只是使用另一个线程来执行FTP工作。

这是一个罕见的问题，问题实际上是其他人代码中的错误；OP已确认以太网设备驱动程序有故障

“另一方面，适配器工作得很好，在这种情况下，在另一台计算机上”-可能值得检查工作的计算机与不工作的计算机之间的差异，例如，网络驱动程序版本、防病毒软件、固件修订、防火墙配置等。当前的过程是比较日志（内部，Wireshark）在我们识别了这两种行为的计算机上：它通过直接连接工作，而不是适配器。@HarryJohnston Windows防火墙可能是个主意，即使我看不出它如何以这种方式影响行为。有趣的是，只有工作的计算机有防病毒软件。听起来可能是网络中的一个bugriver用于USB适配器，或者甚至USB总线驱动程序。驱动程序错误可能很难重现，问题没有出现在第三台计算机上的原因可能与此完全无关。@HarryJohnston这是我们的最新想法，但我不相信套接字堆栈是由驱动程序管理的-我总是应该是WIndows内核本身吗