This project is a bit similar to a home automation project so keep home automation in mind.
- I have a Globally Accessible Server known as
S
- There is a mobile client known as
M
- There is a hub known as
H
Since a lot of IP's are dynamic and ISP's charge extra costs for static IP's and having customers to port forward their ports for my applications is impractical.
I've heard that TCP Hole punching for P2P can be unreliable, However using S
as a proxy for all requests seems impractical as there would be a huge load on S
.
My Goal:
Connect M
to H
so they can make RESTful HTTP Requests to eachother.
My Questions
- How would I manage a situation where neither
M
orH
can initiate a connection via TCP? (use UDP?) - If TCP Hole punching doesn't work in the situation, could I send UDP packs instead? (UDP's are unreliable in terms of delivery, so would sending multiple duplicate packets guarantee delivery?)
Notes
I know generally how hole punching works, S
must give the endpoints of both clients to eachother so they can both try initiate a connection. and I also have a good understanding of NAT's
Maybe for the rarer cases that TCP Hole Punching is ineffective, S
could act as a proxy
Yes via UDP. Or using TCP through S.
It depends. You have to have checks on receiver side which will determine if the packet is received or not and then send a notification to the sender. Because you may send 10/20 same packets and still they may not reach the receiver. But if you want to have reliable packet delivery and also UDP then there is a protocol called RUDP.
Note that whether you use TCP or UDP, you can't always establish P2P connection successfully. Many of the time you must make connection through S or you fail to connect. The scenario is if one of the end point has Symmetric NAT and other has PRC/Symmetric NAT. Now a days many of the LTE based connection uses Symmetric NAT.