我正在尝试通过 WiFi 将我的 Galaxy Ace 连接到我的笔记本电脑.两台设备都通过WiFi连接到路由器，双方都使用Java.

I am experimenting with connecting my Galaxy Ace to my laptop via WiFi. Both devices are connected to a router via WiFi, and both sides use Java.

在 TCP 连接不时给我很高的 ping 之后，我决定将连接基于 UDP，以便能够控制数据包实际发送的时间.

After a TCP connection gave me very high pings from time to time, I decided to base the connection on UDP, to be able to control when the packets are actually sent.

但是，Android 似乎仍在缓冲 UDP 数据包并且不会立即发送它们.如果在几分之一秒内没有传出数据，则此操作或完全关闭 WiFi.

However, it seems like Android still buffers UDP packets and does not send them immediately. This, or it shuts down WiFi completely, if there is no outgoing data transmitted for some fraction of a second.

首先，我以大约每秒一次的不规则间隔 ping 手机，反复发送 ping 请求，只要没有收到应答(包括 UDP 中的丢包):

First, I pinged the phone at irregular intervals of about once a second, repeatedly sending ping requests, as long as no answer was received (covering packet loss in UDP):

    computer -> phone -> computer
    Pinging 192.168.1.40: 148.05968ms
    Pinging 192.168.1.40: 524.41156ms
    Pinging 192.168.1.40: 705.8688ms
    Pinging 192.168.1.40: 3.705367ms
    Pinging 192.168.1.40: 3.872159ms
    Pinging 192.168.1.40: 549.4541ms
    Pinging 192.168.1.40: 479.29843ms
    Pinging 192.168.1.40: 3.89936ms
    Pinging 192.168.1.40: 428.85876ms
    Pinging 192.168.1.40: 739.28125ms

我通过每 100 毫秒仅使用 1 个字节的数据从手机向计算机发送数据包来解决此问题，除此之外没有改变例程:

I worked around this problem by sending packets from phone to computer with just 1 byte of data every 100ms, changing nothing on the routine other than that:

    computer -> phone -> computer
    Pinging 192.168.1.40: 4.147753ms
    Pinging 192.168.1.40: 3.738213ms
    Pinging 192.168.1.40: 14.133768ms
    Pinging 192.168.1.40: 4.470561ms
    Pinging 192.168.1.40: 3.628386ms
    Pinging 192.168.1.40: 3.898334ms
    Pinging 192.168.1.40: 3.512401ms
    Pinging 192.168.1.40: 7.907006ms
    Pinging 192.168.1.40: 5.234216ms
    Pinging 192.168.1.40: 5.639137ms

对于我的应用程序来说，低延迟至关重要，所以我会继续发送这样的空数据包(至少只要没有传输真实数据).我想知道，如果我可以强制 android 尽可能快地响应，而不需要在整个网络中抛出无用的数据.那么，有没有更优雅的解决方案呢?

It is crucial for my application to have low latency, so I would keep sending empty packets like this (at least as long as there is no real data transmitted). I am wondering, if I can force android to respond as fast as possible, without needing to throw useless data all around the network. So, is there a more elegant solution?

顺便说一句，我假设问题出在智能手机上，而不是计算机上，尽管它也可能是计算机等待传入数据包然后发送数据包.不过，根据我对网络的了解，这不太可能.

By the way, I am assuming the problem is the smartphone, not the computer, though it could also be the computer waiting for incoming packets and then sending its packets. From what I know about networking, this is very unlikely, though.

感谢您的帮助！

推荐答案

就Java而言，一旦调用了DatagramSockect.send(...)，数据报就被发送"了.Java 应用程序空间中没有缓冲，也无法控制 OS 中的任何缓冲.

As far as Java is concerned, once DatagramSockect.send(...) has been called, the datagram is "sent". There is no buffering in Java application space, and no way to control any buffering in the OS.

TCP 或 UDP 都不太可能阻止"数据包.更可能的是，根本问题出在 WiFi 级别……或者可能与路由有关……并且操作系统会延迟发送数据包，直到问题自行解决.

It is unlikely that either TCP or UDP is "holding back" packets. It is far more likely that the root problem is something at the WiFi level ... or possibly with routing ... and the OS is delaying sending the packets until the problem resolves itself.

谢谢，我现在只在没有其他数据包发送的情况下才发送那些保持活动的数据包.

Thanks, I now implemented sending those keep-alive packets only if there was no other packet sent during that time.

听起来您的保活 ping 正在产生预期的效果......据此我推断根本问题是/是由于不活动而导致 WiFi链接"被丢弃.(这听起来像是不要耗尽电池"功能......)这表明另一种解决方法是查看您是否可以调整 WiFi 超时.

It sounds like your keep-alive pings are having the desired effect ... and from that I infer that the root problem is / was that the WiFi "link" was being dropped due to inactivity. (It sounds like a "don't drain the battery" feature ...) This suggests that an alternative fix would be to see if you can tweak the WiFi timeout.

除此之外，将数据包发送到另一个没有人在监听的端口会更快吗?没有的话应该还是一样的效果吧?

Besides that, would it be faster to send packets to another port, on which nobody is listening? It should still have the same effect without, right?

这不太可能产生任何影响.没有证据表明问题是由拥堵引起的.证据表明您的手机关闭了不活动的 WiFi 以节省电量...

It is unlikely to make any difference. There is no evidence that the problem is caused by congestion. The evidence points to your phone turning off inactive WiFi to save power ...