有一个讨厌的线程(客户端)正在等待来自远程设备(服务器)的事件。这些事件是由专用网络通过TCP套接字接收的(我必须分配一个静态IP)。该操作不是阻塞操作，而是轮询(select + recv)。对于某些操作，线程使用FTP库开始与设备的CURL传输。然后，有时会收到下一个垃圾，而不是下一个常规操作。该行为可以在三台计算机中的两台上系统地重现。如果设备是通过网络端口直接连接的，则其中之一可以工作，但如果通过网络USB适配器(允许Internet连接)则不能工作。另一方面，在这种情况下，适配器可以在另一台计算机上很好地工作。如果我们取消FTP传输，则一切正常。该行为与所使用的CURL版本以及上一个版本7.40相同。
我是这里的维护者，有一个古老的庞大项目，我几乎无法更改/重写任何事情，特别是在这种情况下，这段代码显然已经工作了好几年(尽管发出了一些问题的信号)，而在将近两个月之前测试版。但是我必须解决这个问题，例如，如有必要，我会将操作从轮询更改为阻止。其他同事已经看到该代码了，Application Verifier没有检测到任何东西(不再)，从recv接收的缓冲区已经损坏，Wireshark说我们正在接收正确的数据包-什么都没有!调试有点困难，因为没有针对此庞大的“应用程序”的调试设置，并且没有通过远程调试和一些“精心选择的”断点...错误的行为消失了。我尝试了大多数常用的(过去赢得)的方法，将近两个星期，其余的方法看起来也不是很乐观-它们都需要时间:1)直接调试其中一台计算机(如果调试可复制并在安装VS之后，从服务器获取整个代码)-我不知道该怎么做2)编写“正确的”代码以在一个单独的项目中进行(已经以某种方式启动)3)另一种llvm构建(非常努力)。
任何想法都将受到赞赏，我将很高兴对任何澄清要求做出回应。
编辑
我们以最小的测试程序重现了这种情况。它是通过USB-网络适配器在三台尝试过的两台计算机上进行的。
我们通过TCP套接字从设备中获得两个命令。我们只读取第一个(1个字节)，我们使用CURL库进行FTP传输，然后读取另一个(7个字节)，但是只有垃圾。如果我们通过读取第二个命令来切换FTP调用，那么即使处于无限循环中，一切都很好。 Wireshark显示数据(7个字节)正确输入，因此很明显在CURL FTP传输期间发生了某些事情。但是它如何影响不相关的套接字？
当前步骤是确定损坏我们套接字的CURL调用。
编辑2
我们没有精确地识别出脏的CURL调用，因为...这不是一个固定点。我们通过recv(..., MSG_PEEK)和跟踪来进行此标识，尽管有时它位于同一代码区域内，但有时可以在两个printf指令之间。恕我直言，这仅是可能的，因为某些CURL connect调用会产生另一个线程(名为_SockAsyncThread@4，显然是Windows内部使用的)，该线程可能会更改套接字的堆栈。通过在某些地方添加Sleep(1500)，它可以工作。与64位版本相同的“不工作”行为。尽管它永远无法与CURL一起使用，但是通过将其替换为FtpGetFile，它可以在循环中工作，但第一个调用除外... :(。我的想法是“D-Link DUB-E100 USB 2.0快速以太网适配器”具有一些它的驱动程序中存在严重问题(最新的Windows 7版本与Vista版本相同，BTW)。在我看来，一种变通办法是先读取套接字上的通知，然后再处理它们，或者只是使用另一个线程来执行FTP工作。
最佳答案
这是一些罕见的问题，其中的问题实际上是其他人的代码中的错误。 OP已确认以太网设备驱动程序有故障。
关于c++ - 套接字通过并发FTP传输接收到错误的数据，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27982893/