4

我用多播套接字编写了一个简单的 udp 服务器客户端应用程序。服务器每 6 毫秒向三个客户端发送数据包。数据包大小为 1200 字节。这是每秒 166,66 个数据包。每当其中一个客户端检测到丢失的数据包时，它都会通过单播向服务器发送一个 NACK 数据包。

第一次测试： 服务器和三个客户端通过以太网连接到路由器 TP-Link TL-WDR4300 (dd-wrt)，一切正常。

第二次测试： 只有服务器通过以太网连接到路由器，其他客户端通过无线 2.4 GHz 和固定信道连接。无线出现了两个问题：第一个问题是丢包，客户端只接收到 50% 的数据包。并且丢失出现在突发中，例如收到 400 个数据包，丢失 200 个等。第二个问题是，当客户端将 NACK 数据包发送回服务器时，我可以在 Wireshark 上看到，但我的应用程序无法接收它们。这很奇怪，因为代码与客户端通过以太网连接时的代码相同。那么，有什么想法吗？我会很感激

服务器代码：

while (1) {

    FD_ZERO(&readfds);
    FD_SET(sd, &readfds);

    tv.tv_sec = 0;
    tv.tv_usec = 0;

    rv = select(sd + 1, &readfds, NULL, NULL, &tv);

    while (rv == 1) {

        nack_processing(sd);
        rv = select(sd + 1, &readfds, NULL, NULL, &tv);


    }
}
return 0;

}

我还进行了更新以减少流量：数据包大小：800 字节数据包之间的到达时间：10 毫秒 = 每秒 100 个数据包 = 0.076 MB / s

我测量了服务器端和客户端的流量：服务器 ~ 10 MB/s 客户端 ~ 5 MB /s

一切似乎都很好

4

1 回答 1

1

请注意，您正在比较两个不同的接口/媒体。一种是有线接口，另一种是无线接口。

无线网络中的丢包：

这可能是由于多种原因。然而，第一个即时检查点应该是 SNR、RSSI 和工作频率/同频干扰。wifi 分析仪几乎可以带您接近解决方案。

无线路由器位置- 检查无线路由器是否位于需要覆盖的区域的中心位置。确保避免覆盖区域适当重叠的覆盖漏洞。确保避开建筑物之间以减少干扰。另外，请注意，距离和用户的数据速率之间存在关系。用户越近，数据速率就越高，因为路径损耗减少（因为这反过来会增加 SNR）。

天线类型- 全向天线以球体形式提供覆盖区域。偶极天线以甜甜圈的形式提供覆盖区域。还有各种定向天线。请注意，全向天线可能会在小区尺寸较大的情况下导致隐藏节点问题。带有聚焦光束的天线可能会有所帮助。多扇区定向天线可以提供高容量、范围。天线的类型、位置和天线增益决定了无线电传输范围和覆盖范围。

通信信道/工作频率- 在同一无线电覆盖区域内以相同频率工作的其他 AP 的存在可能会造成干扰。在这种情况下，如果附近只有 802.11 设备，则应相应更改工作信道和信道间隔以减少干扰。

功率级别- 较高的功率级别可以扩大范围，但如果附近有 AP，则可能会导致干扰。对于更高的容量，AP 可能靠得很近，在这种情况下，首选低功率电平以减少干扰。

其他设备- 微波炉、蓝牙、无绳电话等非 802.11 设备也可能引入干扰。在这种情况下，最好将这些设备移除或屏蔽以避免干扰。

突发数据包丢失似乎也表明堆栈无法处理突发流量，其流量整形策略可能只是丢弃此类突发数据包。仔细检查是否生成了此类流量突发。

NACK 未到达服务器： 同样，这可能是由于传输媒体相关问题导致 NACK 在空中丢弃。如果 NACK 已到达主机但未到达服务器应用程序/未处理，则可能是由于服务器的体系结构或堆栈相关的操作系统配置。

分析丢包场景的典型步骤

  1. 检查防火墙设置、操作系统配置、路由器配置和网络硬件能力/配置（吞吐量能力、操作模式）、中间节点配置/能力（MTU、路由/转发表）
  2. 在无线路径上，检查 AP 的位置、工作范围（频率）、信道间隔、SNR 、RSSI、天线类型/增益、覆盖孔、与 AP 的距离、覆盖区域内是否存在其他 802.11 设备和非 802.11 设备。
  3. 检查各种节点和接口的所有输入和输出点的数据包统计信息
  4. 检查应用程序/协议层中所有输入和输出点的数据包统计信息
  5. 重复测试以通过吞吐量、数据包大小、运行持续时间、不同应用程序、不同有效负载大小、不同数量的 pkts、功率级别、AP 位置、信道的各种组合来识别数据包丢失的模式......也是一种方法确定问题区域。
于 2014-10-26T01:54:57.797 回答