在复杂的多子网LAN中的对等通信

我们正在开发一个P2P应用程序，并且在同一个本地局域网中的两个对等体之间进行通信的部分，但是有两个不同的子网。

我们知道有很多情况下，同一局域网中的某些个人电脑肯定是某些路由器设置“不可连接”的原因。我们正在努力的只是了解情况，找出我们能做的最好的事情。（与我们有限的networking知识和你的帮助）

考虑一个如下图所示的结构的局域网。假设局域网是由我们的客户devise的，我们什么都不知道。我们只是从安装我们的程序的个人电脑的angular度来看局域网。因此，我们所知道的是我们的本地IP /子网掩码和整个局域网的公共IP。（其余未知＆显示为云）

在这里输入图像说明

我们有几个问题，我们高度appricated任何答案：

假设PC1组播数据包，并且数据包以某种方式到达PC2。 PC2将看到PC2的IP地址是PC1的LocalIP（如图192.168.1.111所示）还是Router_A_1或Router_A的外部IP？
在＃1之后，如果PC2回复给PC2在＃1中看到的IP的另一个数据包（单播），数据包是否会到达PC1？
在＃2的全球案例中，PC1和PC2用来将数据包发送到另一个IPAddress的IPAddress是什么？（或者，我们在NAT路由器之后使用2台PC进行互联，就像upnp，hole-punching或intermediate-superNode一样？
有没有PC1和PC2分配相同的IP地址的情况？如果这是真的，那么：
- 一个。这是一个“合法”的情况吗？
- 湾 PC2在＃1中看到的发件人的IP以及对＃2的回答是什么？

更新附加问题：

这是真的，如果一个对等多播和数据包可以到达另一个对端那么这两个PC是“单播” – 如果多播包不能到达另一个对端，那么2台PC注定是？对于“可单播 – >可多播”这是否正确？

我写了很less的点对点应用程序，我可以告诉你，对等点的可达性是这类应用程序的主要问题。这里有几点提示：

如果你使用TCP，你唯一的希望就是UPnP。但是，您不能认为它始终可用。实际上，UPnP（a）主要由家庭networking路由器支持（b）它经常被禁用，因为人们看不到它的价值，所以对它的支持是零星的。如果你的客户端支持2层路由器，每个都做自己的NAT，那么你的机会更小。但是，如果您可以告诉您的客户启用UPnP或指定UPnP作为您的应用程序的先决条件，那么这是一种方式。
另一个select是使用UDP并在路由器上打一个针孔，但是您需要外部代理来跟踪对等地址，并将主机标识与全局可访问的IP地址相匹配（在您的情况下，它可能会部署为“未知”）。请注意，UDP针孔的TTL通常非常短（我估计它在20秒到5分钟之间），所以你需要经常ping你的代理。 UDP的另一个问题是，如果您的应用程序交换大于1个数据包的数据位，您可能需要实现自己的stream量控制协议。

希望这可以帮助。

在最佳情况下，您的networking拓扑结构不可靠，难以维护。

考虑这个（假设/ 24子网）：PC1（192.168.1.111）试图发送一个数据包到PC2（192.168.1.22）。为什么Router_A_1（甚至是Router_A）通过“未知”云将数据包转发到另一个子网？就“A”路由器而言，数据包已经在它所属的子网上。在路由器上转发一些路由表来转发特定的地址并不是不可能的 – 但是你会发现这是“不可靠和困难”部分的来源（根据“未知”云中的内容，甚至可能不实际）。

是否有一些原因，你不能简单地分配一个不同的/ 24到“B”路由器子网？比如192.168.2.0/24？

你没有说但是..
如果使用传统的24位子网掩码（即两个networking都是192.168.1.0/24），那么这些机器将永远不能通信，因为根据定义，它们将试图通过广播来parsingMAC地址，而不是去网关因为它会假定机器在本地networking上。

你可以通过在不同的networking中分配一个地址来解决这个问题。
SO PC1 = 192.168.2.111

在这种情况下，只要中间路由器具有正确的路由表条目，并允许多播，并且允许尝试的任何端口/协议应该工作。