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:
-
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?
-
After #1, if PC2 reply with another packet (unicast) to the IP that PC2 see in #1, will the packet reach PC1?
-
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?)
-
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:
- 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" ?
Best Answer
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.