我应该使用多播+广播，仅多播还是多播+ IPv6来处理此问题？

Question

所以我遇到这种情况，我需要通过远程计算机通过TCP套接字从远程计算机上收集信息（确保没有信息丢失比速度更重要），然后通过多播将其“可靠”端重新转播给其他听众。这台远程计算机是一个移动目标，因此无法简单地调整所有内容以获得良好的视野。我在下面创建了一个图表。

这台远程计算机功能不是很强大，因此所有侦听器都不能通过TCP套接字连接到它，因为它的可用资源已经有所限制了。

然而，还希望当有人连接到其WiFi网络时，该远程计算机能够“发现”。据我了解，这通常是通过定期的UDP广播来实现的。

现在我的问题是;我应该如何从网络角度这样做？根据我的理解，UDP广播通常不应该越过其局域网，在这种情况下只会是10.0.1.0/8子网...意味着路由器后面的“中继设备”将无法看到它。显然，如果你有一个允许复杂配置的路由器（例如一个运行DD-WRT / Tomato），那么你可以在各自的VLAN中强制这种行为......这显然不是一个好主意？我认为这也会搞砸DHCP，允许来自路由器上客户端的DHCP请求被远程WiFi网络意外服务。

我的另一个选择是通过组播端口和多播地址进行“服务发现”，所有客户端都知道要监听（即224.239.74.2:45454），因为多播应该能够跨越LAN（经过简单的配置，我想）。

关于多播，我一直都知道通过WiFi做这件事通常是一个坏主意（虽然不知道为什么）。一些监控设备可以通过从中间路由器广播的WiFi连接。我可以改变它，使得所有监控设备都通过TCP连接到中继，但是如果中继相对较弱（即另一台嵌入式计算机），或者如果添加了前所未有的监控设备，那么这似乎不可扩展。未来的网络。

由于此网络完全关闭（未连接到互联网），我一直想知道IPv6是否可以成为解决方案。除了荒谬的地址数量以外，我对IPv6知之甚少，基本上没有更多的子网划分。我在网上看到，多播是协议所固有的（与IPv4不同），这让我相信无论在WiFi上通过IPv4进行多播的问题都已得到解决。这也假设所有现代设备基本上都是“IPv6就绪”。

有人可以告诉我我应该从这里做些什么吗？我对这些东西不是很有经验，我写的所有内容都是推测性的。