7

最近，我开始使用 WP7 的 Mango 版本中引入的 System.Net.Sockets 类，并且总体上很喜欢它，但注意到在调试模式下传输数据的延迟与在手机上正常运行时的延迟存在差异。

我正在编写一个“远程控制”应用程序，当用户点击应用程序中的按钮时，它通过 Wifi 将单个字节传输到我的 LAN 上的本地服务器。因此，应用程序的感知响应性/及时性对于良好的用户体验非常重要。

通过 USB 电缆将手机连接到我的 PC 并在调试模式下运行应用程序，TCP 连接似乎在用户点击按钮时传输数据包的速度很快。

在手机与 PC 断开连接的情况下，用户最多可以点击 7 个按钮（因此，在发送所有 7 个字节之前，有 7 个带有 1 个字节有效载荷的“发送”命令。）如果用户点击一个按钮并在两次点击之间稍等片刻，似乎有1秒的延迟。

我已经尝试将 Socket.NoDelay 设置为 True 和 False，它似乎没有任何区别。

为了查看发生了什么，我使用了数据包嗅探器来查看流量情况。

  • 当手机通过 USB 连接到 PC（使用 Wifi 连接）时，每个单独的字节都在自己的数据包中，间隔约 200 毫秒。

  • 当手机在自己的 Wifi 连接（从 USB 断开）上运行时，字节仍然有自己的数据包，但它们都以 4 或 5 个数据包的突发分组在一起，每组与下一组相距约 1000 毫秒。

顺便说一句，从我的笔记本电脑测量，我的 Wifi 网络上到服务器的 Ping 时间只有 2 毫秒。

我意识到将“发送”缓冲在一起可能可以让手机节省能源，但是有没有办法禁用这种“延迟”？应用程序的响应能力比省电更重要。

4

6 回答 6

2

Andrew Burnett-Thompson 在这里已经提到过，但他也写道，它对你不起作用。我不明白，我不明白为什么。那么，让我解释一下这个问题：

引入 Nagle 算法是为了避免必须通过 TCP 网络发送许多小数据包的情况。任何当前最先进的 TCP 堆栈都默认启用 Nagle 算法！

因为：TCP 本身会为通过 IP 连接的任何数据传输内容增加大量开销。并且应用程序通常不太关心通过这些 TCP 连接以优化的方式发送数据。所以，毕竟在操作系统的 TCP 堆栈内部工作的 Nagle 算法做得非常非常好。

可以在 Wikipedia 上找到对Nagle 算法及其背景的更好解释。

因此，您的第一次尝试：通过在套接字上设置选项 TCP_NODELAY 来禁用 TCP 连接上的 Nagle 算法。这是否已经解决了您的问题？你觉得有什么不同吗？

如果不是这样，那就给我一个信号，我们将进一步深入研究细节。

但是，请仔细检查这些差异：检查详细信息。也许毕竟你会了解你的操作系统的 TCP/IP 堆栈中的东西是如何工作的。

于 2012-01-02T06:55:28.350 回答
2

这确实是一个有趣的问题！我将投入 2 美分，但请注意，我不是 WP7 上 System.Net.Sockets 的专家。

首先，应该忽略调试器中的性能测试。原因是记录堆栈跟踪的额外开销总是会减慢应用程序的速度，无论操作系统/语言/IDE如何。应用程序应在发布模式下进行性能分析，并与调试器断开连接。在您的情况下，它实际上断开连接速度较慢！好的，让我们尝试优化它。

如果您怀疑数据包正在被缓冲（这是一个合理的假设），您是否尝试过发送更大的数据包？尝试线性增加数据包大小并测量延迟。您能否在设备上的代码中编写一个简单的微分析器，即：使用 DateTime.Now 或 Stopwatch 类来记录延迟与数据包大小的关系。绘制该图可能会让您更好地了解您的理论是否正确。如果您发现 10 字节（甚至 100 字节）的数据包会立即发送，那么我建议您只需在每次传输时推送更多数据。我知道这是一个蹩脚的黑客，但如果它没有坏...

最后你说你正在使用 TCP。你可以试试UDP吗？TCP 不是为实时通信而设计的，而是为精确通信而设计的。相比之下，UDP 没有错误检查，您无法保证交付，但您可以期待更快（更轻量级，更低延迟）的性能。Skype 和在线游戏等网络是基于 UDP 而不是 TCP。如果您确实需要确认收据，您始终可以在 UDP 上构建您自己的微协议，使用您自己的循环冗余检查进行错误检查和请求/响应（确认）协议。

确实存在此类协议，请查看上一个问题中讨论的Reliable UDP。有一个基于 Java 的 RUDP 实现，但我确信某些部分可以移植到 C#。当然，第一步是测试 UDP 是否真的有帮助！

找到了讨论该问题的上一个问题。也许是 Wp7 问题？ Windows Phone 7.1 (Mango) 的 UDP 性能不佳

仍然有兴趣看看增加数据包大小或切换到 UDP 是否有效

好的，所以这两个建议都没有奏效。我找到了对 Nagle 算法的描述，该算法按照您的描述对数据包进行分组。设置 NoDelay 应该会有所帮助，但正如您所说，没有。

http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.nodelay.aspx

还。请参阅上一个问题，其中将 Keepalive 和 NoDelay 设置为开/关以手动刷新队列。他的证据是轶事，但值得一试。您可以尝试一下并编辑您的问题以发布更多最新结果吗？

通过临时启用 NoDelay 来“刷新”套接字

于 2011-12-29T17:11:59.177 回答
1

听起来你的读/写被缓冲了。您可以尝试将 Socket 上的 NoDelay 属性设置为 true，也可以考虑调整发送和接收缓冲区的大小。响应速度降低可能是 wifi 流量不足的副产品，我不确定调整 MTU 是否是一种选择，但降低 MTU 可能会改善响应时间。

所有这些都只是低带宽解决方案的选项，如果您打算在任一方向铲除数兆字节的数据，您将需要更大的 wifi 缓冲区，足够大以补偿传输延迟，通常在 32K-256K 范围内。

    var socket = new System.Net.Sockets.Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp)
    {
        NoDelay = true,
        SendBufferSize = 3,
        ReceiveBufferSize = 3,                
    };

我没有测试这个，但你明白了。

于 2011-12-30T00:29:32.387 回答
1

很可能不是软件问题。如果手机使用 WiFi，延迟可能会超过 70 毫秒（取决于服务器的位置、带宽大小、繁忙程度、对 AP 的干扰以及与 AP 的距离），但大部分延迟只是WiFi。使用 GMS、CDMA、LTE 或手机用于蜂窝数据的任何技术甚至更慢。我不会想象你在蜂窝设备上得到的时间会低于 110 毫秒，除非你站在蜂窝塔下面。

于 2011-12-23T21:38:00.930 回答
1

您是否尝试过设置 SendBufferSize = 0？在“C”中，您可以通过将 SO_SNDBUF 设置为 0 来禁用 winsock 缓冲，我猜 SendBufferSize 在 C# 中的含义相同

于 2012-01-02T09:01:16.053 回答
0

您是否曾经使用过 Lumia 610 和 mikrotik 接入点？

我遇到过这个问题，它使 Lumia 610 在关闭最后一个连接后立即关闭 wifi 无线电。例如，与 Lumia 800 相比，这增加了可感知的延迟。所有连接都受到影响 - 只需关闭 wifi 即可使所有应用程序更快。我的管理员说这是 mikrotiks 当时不支持的一些功能与 WMM 设置相结合。奇怪的是，大多数其他手机都运行得很好，所以我们一开始就归咎于 610 的便宜。

如果您仍然可以复制问题，我建议您尝试以下操作：

  • 在后台打开另一个连接并一直ping它。
  • 使用 3g/gprs 而不是 wifi（需要将您的服务器暴露在互联网上）
  • 使用不同的（或升级的）手机
  • 使用不同的（或升级的）AP
于 2013-01-07T13:55:29.927 回答