Peer to peer communication in complicated multi-subnets LAN

Question

We are developing a P2P application and stucked at the part of making communication between 2 peers which are in same local LAN but 2 different subnets.

We know that there are a lot of cases that 2 certain PCs in same LAN are definitely "un-connectable" cause of some routers' settings. What we are trying is just to make sense of the situation & find out the best we can do. (with our limited knowledge on networking and your help)

Consider a LAN with structure like following figure. Suppose the LAN is designed by our client and we don't know anything. We are just watching the LAN from the point of view of a PC which installed our program. Thus all that we know are our localIP/subnetMask & the common public-IP of entire LAN. (The rest is unknown & is displayed as a cloud)

We have several questions that we are highly appricated for any answer:

1. Suppose that when PC1 multicast a packet and the packet reaches PC2 somehow. What IP-Address will PC2 see for packet's sender: LocalIP of PC1 (as in figure 192.168.1.111) or external IP of Router_A_1 or Router_A?

2. After #1, if PC2 reply with another packet (unicast) to the IP that PC2 see in #1, will the packet reach PC1?

3. In global cases of #2 what can be appropriate IPAddress that PC1 & PC2 use to send packets to the other? (Or it's the same as we do over Internet with 2 PCs behind NAT Routers: upnp, hole-punching or an intermediate-superNode?)

4. Is there any case that PC1 & PC2 are assigned with the same IP Address? If it's true then:

   • a. Is that a "legal" case?
   • b. What about the sender's IP that PC2 sees in #1 and answer for #2?

---

Update additional question:

5. Is this true that if 1 peer multicast & the packet can reach the other peer then the 2 PCs are "unicast-able" - and if the multicast-packet can not reach the other peer then 2 PCs are doomed ? Is that true for "unicast-able --> multicast-able" ?

Answer 1

I wrote few peer-to-peer application and I can tell you that reachability of peers is the main problem with this kind of applications. Here are few pointers:

• if you use TCP your only hope is UPnP. However, you cannot assume that it is always available. In fact UPnP is (a) mostly supported by home network routers (b) it is often disabled as people see little or no value in it, so support for it rather sporadic. Your chances are even slimmer if your clients are behind 2 layer of routers each doing its own NAT. But, if you can tell your customers to enable UPnP or specify UPnP as prerequisite for your app then it is a way to go.

• Another option is using UDP and punch a pinhole in the router but you would need external agent that keeps track of peer address and matches host identity to a globally accessible IP address (in your case it will likely be deployed in "Unknown"). Note, that TTL of UDP pin holes is usually very short (by my estimate it is between 20 sec and 5 min), so you would need to ping your agent quite often. Another problem with UDP is that if you may need to implement your own flow control protocol if your application exchanges bits of data that are larger than 1 packet.

Hope this helps.

Answer 2

Your network topology in the best case is unreliable and difficult to maintain.

Consider this (assuming /24 subnets): PC1 (192.168.1.111) tries to send a packet to PC2 (192.168.1.22). Why should Router_A_1 (or even Router_A) forward that packet thru the "unknown" cloud over to the other subnet? As far as the "A" routers are concerned, the packet is already on the subnet it belongs. It's not impossible to hack some routing tables in the routers to forward specific addresses - but you'll find that's where the "unreliable and difficult" part comes from (and may not even be practical depending on what's in the "unknown" cloud).

Is there some reason you couldn't simply allocate a different /24 to the "B" router subnets? Such as 192.168.2.0/24?

Answer 3

You did not say but..
If you are using the traditional 24 bit subnet mask (ie both networks are 192.168.1.0/24) then these machines will never be able to communicate because by definition they will attempt to resolve the MAC address by broadcast instead of going to the gateway for routing because it will assume the machine is on the local network.

You could fix this by assigning PC1 an address in a different network.
SO PC1=192.168.2.111

In that case as long as the intermediate routers have the correct routing table entries and allow multicast and allow whatever port/protocol you are attempting it should work.