network-programmingp2phole-punching

What's so hard about p2p Hole Punching?

I am trying to experiment with some p2p networking. Upon doing some research, one of the biggest obstacle I learnt is "What if a client is behind a NAT/Firewall", later on I discovered about Hole Punching but that it is not always guaranteed to work.

As far a I understand, I don't understand why it might fail, This is what I know so far:

enter image description here
Based on the diagram above, this is how I understand how a successful connection can be established.

  1. Alice joins the network (1) by creating connection to a directory-server. When this happens, Alice's NAT creates a mapping from her public ip to her local ip.
  2. The directory server receives the connection and store Alice's public ip:port in the directory
  3. Bob does the same (2), Joins the network and publishes his ip:port in the directory
  4. Alice wants to communicate with bob. So she looks up Bob's ip:port from the directory. (3)
  5. Alice sends data on Bob's ip:port which she got from the server. (5)
  6. Since Bob also has a mapping from is ip:port to his local ip:port, the NAT simply forwards any data received on Bob's public ip:port to his computer.
  7. Same works for Alice
    I hope I was clear in my explanation of what I understand. My question is, what is so hard or unreliable about this? i must be clearly missing something. Can you explain me what it is?
Solution

  • One problem is that the NAT mappings in Alice's NAT server may time out, either after a fixed time, or after a period of inactivity.

    A second potential problem is that the NAT server could make the restriction that Alice's NAT mapping is only "good" for TCP connections established by Alice, or connections between Alice and the initial IP "she" connected to. (In other words, direct communication between Alice & Bob may be blocked.)

    And so on.

    The problem is that the behaviour of a NAT server is highly dependent on how the managing organization's configuration / policy decisions. Many of these decisions could mean that your particular P2P usage pattern won't work reliably ... or at all.

    So then is my whole idea about hole punching wrong?

    No. It just means that it won't always work.