Java Android中的平滑WiFi切换

我们正在为Android开发一个小应用程序，用于在同一网络中的两个不同无线接入点之间平滑切换（相同的SSID和相同的网络配置，但不同的物理位置），目标是在执行切换后不中断现有连接。我在这里读了几篇文章，解释如何通过编程控制wifi，现在我们有了一个半工作的解决方案

按照我们的实现方式，该服务正在扫描符合我们的标准和最佳信号的AP，如果它与系统当前连接的AP不同，它将切换到新AP。守则的有关部分：

...
// Some initializations and bestOne is the ScanResult with the best signal
conf.BSSID = bestOne.BSSID;
actualNid = mWifiManager.updateNetwork(conf);
mWifiManager.enableNetwork(actualNid, false);
mWifiManager.saveConfiguration();
conf = getWifiConfiguration(mWifiManager, conf);
if(conf == null) {
    return;
}
if(!mWifiManager.enableNetwork(conf.networkId, true)) {
    return;
}
if (mWifiManager.reconnect()) {
    // Great
} else {
    // Error
}

问题是所有的执行都要经过预期的代码路径。但是，没有真正执行切换，在执行重新连接时会显示日志，并返回true。此外，没有收到来自任何请求者连接、更改或请求者状态、更改或操作的事件，因此切换似乎甚至没有触发

另一个事实是，如果我们在启用网络之前插入mWifiManager.disconnect（），则实际上会执行切换。然而，这不是一个选项，因为正在运行的应用程序会失去连接，从而中断会话，这正是我们想要避免的

---

欢迎提出任何建议。

这可能不仅仅是软件相关的问题。通常，网络适配器（wifi）负责跟踪信号电平，并决定何时漫游以及漫游到何处。这些算法是特定于供应商的，您可能无法影响它们。漫游是通过从客户端发送802.11重新关联帧（请求）完成的，漫游过程是在L2级别完成的（在您的场景中）。但过程可能并不是那么简单。两个AP都应该知道客户端是否漫游，并且向这些AP发送帧的交换机应该在其CAM表中进行更新。客户端从中漫游的AP可能会缓冲发送给客户端的所有帧，并在客户端重新关联时将其发送给新AP，从而不会导致数据丢失。由于802.11标准不要求这样做，漫游可能会导致数据丢失，而简单地重新连接到信号较强的AP会导致连接中断，因为这不仅仅是漫游，而是完全断开并重新连接到网络

---

这可能无法帮助您解决问题，但我想指出的是，这确实应该在较低级别（物理、数据链路或传输）上完成，而不是在应用程序级别。漫游是否能实现无缝连接取决于所使用的硬件（双方）和网络配置，而要改变这一点，你无能为力。唯一需要考虑的是发送802.11探测请求，以便客户端知道其他可能具有更强信号的AP，这是您在代码中已经做过的，并将漫游决定留给网络适配器。

我认为这不可能在应用程序中实现。在WiFi驱动程序级别上可能是这样，但这并不容易：（说“这是一个硬件特有的功能”-因此甚至在驱动程序级别上也可能不是这样）请看我看到的答案，如果是硬件限制，那么就没什么可以做的了。然而，我想知道，即使在这个断开/连接周期中，是否有办法避免操作系统丢弃现有连接。我们有一个远程显示器，在切换时超时并完全断开连接，我们正在寻找一些解决方法，如果可能的话，不涉及完全重新连接应用。如果可以，最好关注如何保持应用内连接，即使网络连接不稳定。这是wifi的一种可能情况，除此之外，即使您漫游到另一个AP，根据硬件和网络实施情况，即使漫游过程持续时间小于0.1秒，您也可能会收到持续数秒的连接中断。如果你的应用程序空闲一段时间，一些路由器/FW还可以向你发送TCP/IP RST（重置连接）。你应该在应用程序中有一些控制来处理这些问题，因为不幸的是你不能完全消除它们。这对于实时应用程序来说可能很棘手，并且在断开/连接到另一个AP而不是漫游时可能会有更严重的缺点。例如，除了完全重置TCP连接之外，DHCP还可以向您发送另一个IP地址，这取决于您实现身份验证的方式，这可能会导致您进行更多的工作，以便快速再次建立连接。对不起，我帮不了你什么忙。我不是安卓方面的专家，所以已经有一些内置机制可以做到（或帮助你做到）这一点，但这不太可能完全可以避免。@René你可以通过使用代理来隐藏一侧的断开连接，使连接保持在一个方向上。在本地网络中保持与显示器的连接并允许重新连接到应用程序，或者在手机上保持本地连接，但这只会将问题转移到处理从应用程序到代理实现的断开连接上，我猜您必须同时执行这两项操作。感谢您的评论。我们考虑过这个问题，但最后，正如你所指出的，这只是将问题向前推进了一步。我们将在应用程序级别实现重新连接机制，这是一个次优的解决方案，但似乎是唯一的解决方案。