python - 使用 MinGW 时，Windows 上的 C 中的 recvfrom 函数会跳过 UDP 数据

Question

我在Windows 上遇到recvfrom 函数问题，无法解决。
请参阅我编写的以下部分代码。我在 Linux 和 Windows 上运行此代码，并在 udp 比特率值中得到不同的结果。

当使用 Cygwin 在 Windows 上编译它时，我得到了与 Ubuntu 上相同的结果，这没关系。我将其与引用工具进行了比较。

当使用 MinGW 在 Windows 上编译它时，我得到较小的 upd 比特率值，这是由一秒内 while(1) 循环迭代次数较少(计数器变量)引起的，以及相关的 - 1 中捕获的数据量较小第二个(data_in_1_sec 变量)。看来Windows上使用MinGW的recvfrom函数是最慢的并且会跳过udp数据。
请注意，在更新比特率约为 0.200 Mbps 的情况下，使用 MinGW 在两个操作系统上的结果是相同的。 UDP 比特率约为 20 Mbps 的数据会出现问题。

不幸的是，我必须使用 MinGW，因为该代码作为静态库加载到 Python 代码中。使用 CygWin dll，我在 Python 下运行此函数时遇到访问冲突。

如何处理这个问题？

我使用 Windows 7 Professional 64。

我使用的代码:

while (1) {
    #ifdef _WIN32
        // start timer
        QueryPerformanceCounter(&t1);           
    #elif __linux
        clock_gettime(CLOCK_MONOTONIC, &start);
    #endif

   udp_packet_len = recvfrom(sock, udp_packet, buff_len, 0, (struct sockaddr *) &addr, &addrlen);
    #if DEBUG == 1
        counter++;
    #endif

    #ifdef _WIN32
       // stop timer
       QueryPerformanceCounter(&t2);        
    #elif __linux
       clock_gettime(CLOCK_MONOTONIC, &finish);
    #endif

   data_in_1_sec += (double)udp_packet_len;

    #ifdef _WIN32
       temp = (t2.QuadPart - t1.QuadPart);
       temp *= 1000000000.0;    
       temp /= frequency.QuadPart;
       temp /= 1000000000.0;
       second += temp;
    #elif __linux
       temp = (finish.tv_sec - start.tv_sec);
       temp += (finish.tv_nsec - start.tv_nsec) / 1000000000.0;
       second += temp;
    #endif

   if(second >=1.0) {
       processing.udp_bitrate = (((data_in_1_sec) * 8.0) /second);

        #if DEBUG == 1
            fprintf(stderr,"\nudp_bitrate: %f\n",processing.udp_bitrate);
            fprintf(stderr,"data_in_1_sec: %f\n",data_in_1_sec);
            fprintf(stderr,"second: %f\n",second);
            fprintf(stderr,"counters: %d\n",counter);
            counter = 0;
        #endif

       data_in_1_sec = 0;
       second = 0.0;
   }

此代码的结果，
对于 Windows:

udp_bitrate: 19799823.828382
data_in_1_sec: 2505664.000000
second: 1.012399
counters: 1904

udp_bitrate: 19389475.566430
data_in_1_sec: 2451708.000000
second: 1.011562
counters: 1863

udp_bitrate: 18693904.033320
data_in_1_sec: 2367484.000000
second: 1.013158
counters: 1799

udp_bitrate: 18963187.258098
data_in_1_sec: 2399068.000000
second: 1.012095
counters: 1823

udp_bitrate: 19452989.621014
data_in_1_sec: 2459604.000000
second: 1.011507
counters: 1869

udp_bitrate: 19795284.196391
data_in_1_sec: 2509612.000000
second: 1.014226
counters: 1907

相同数据的 Ubuntu 输出

udp_bitrate: 22016976.870087
data_in_1_sec: 2788604.000000
second: 1.013256
counters: 2119

udp_bitrate: 22022223.539749
data_in_1_sec: 2787288.000000
second: 1.012536
counters: 2118

udp_bitrate: 22003055.797884
data_in_1_sec: 2785972.000000
second: 1.012940
counters: 2117

udp_bitrate: 22041580.024322
data_in_1_sec: 2788604.000000
second: 1.012125
counters: 2119

udp_bitrate: 22025510.655441
data_in_1_sec: 2782024.000000
second: 1.010473
counters: 2114

udp_bitrate: 22412560.109513
data_in_1_sec: 2801764.000000
second: 1.000069
counters: 2129

Answer 1

UDP 是一种不可靠的传输。丢弃数据包是一种允许的行为，并且当数据传输速率超过接收器处理数据的速率时，这是可以预料的。

Cygwin 和 MinGW 是独立的项目。它们各自提供了构建在 Windows 内核和 API 之上的自己的 recvfrom() 包装器。可以想象，Cygwin 的实现效率更高一些，在您的测试条件下，提供的带宽比 MinGW 高 10%。

也可能是您的仪器干扰了您的测量。至少某些版本的 Cygwin 默认情况下不会导致 _WIN32 由预处理器定义，而 MinGW 会，因此您可能在 Cygwin 中使用 clock_gettime()以及带有 MinGW 的 Windows 性能计数器。您可能认为 Windows 性能计数器的开销足够低，因此这种差异可以忽略不计，但您对其进行了大量调用。您应该考虑通过运行固定次数的迭代测试来最小化这两个来源的开销，并对所有这些迭代的总次数进行计时(每次速率测量仅启动/停止一个计时器)。

底线:您的测试方法可以改进，但即使结果很好地反射(reflect)了被测不同实现的行为，它们也没有揭示出任何根本性的错误。