无线网络（Wi-fi 或任何其他网络）的有效带宽和可靠性高度依赖于 RF 环境。为了获得一些可预测的性能，每个安装都需要针对特定​​环境进行调整。这意味着进行站点调查以确定正确的 AP 编号和位置、天线配置，以及针对发射机功率、信道频率和数据速率配置 AP。

听起来您需要无线网络的最低​​性能。保证这一点的唯一方法是单独调整每个安装。有些地方可能噪音太大 (RF) 根本无法工作。

我还没有找到任何关于如何使 WiFi 组播更好地工作的可靠信息，所以我为了解决这个问题所做的是编写一个组播模拟器层，它大大减少了我的系统需要的组播流量通过 WiFi 发送和接收，而无需对应用程序本身进行重大的重新设计。

在每个节点上，多播模拟器层定期发送一个非常小的多播数据包，只是为了向全世界宣布它的存在。每当另一个节点收到这些数据包中的一个时，它会将数据包的源 IP 地址添加到列表中，并向发送方发送回单播回复（只是为了确保发送方也知道接收方的存在）。

然后，每当应用程序想要“发送包含实际应用程序数据的多播数据包”时，它不仅仅是通过多播直接发送数据包，而是将数据包交给多播模拟器层，后者通过发送一个“多播”数据包单独复制（通过单播）到其列表中的每个 IP 地址。这不会在具有许多参与者的 WiFi 网络上很好地扩展，但对于较小的基于 WiFi 的系统，这比真正的多播表现更好。

还有一些保持活动/超时逻辑，以便长时间未收到消息的节点从每个人的节点列表中删除，但这几乎就是全部。

我在此过程中发现的另一个有趣的“功能”是（无论如何在 Mac 笔记本电脑上），WiFi 硬件设置为在大约 250 毫秒不活动后自行关闭，一旦关闭，它将需要不确定的时间（ 30 毫秒到 250 毫秒之间的任何地方）使其再次可用，以便可以发送下一个数据包。结果是，如果我每 300 毫秒通过 WiFi 发送一个数据包，由于 WiFi 硬件不断进入睡眠状态然后再次醒来，传输的延迟将遍布整个地图。如果我改为每 150 毫秒发送一个数据包，则延迟会稳定得多，因为 WiFi 硬件始终保持在线（当然，以增加能耗为代价）