TCP behind NAT

It’s assumed that host A B both behind NAT, and UDP hole punching is already working.
There are two more requirements for A to initiate a TCP connection to B.
1. natA has to tolerate B’s sending A a SYN by not replying a RST.
2. natB allows A’s SYN to come in, while natB normally expects A’s SYN/ACT.
Most NAT doesn’t meet these two requirements, which explains TCP hole punching seldom works.


Ternary conditional operator is not shortcut of if-else

Reference can be initialized by ?:, but cannot by if-else.
The same is true for const initialization and initialization list on constructors.
Consider this code snippet:

	int a = 0, b = 1, bCondition = false;
	int & c = bCondition ? a : b;
	c = 2;
	_ASSERT(b == 2);
	(bCondition ? a : b) = 3;
	_ASSERT(b == 3);

The root distinction is that ?: is expression but if-else is statement.

UDP behind NAT

There are challenges when communicating through NAT.
1. client is behind NAT. It doesn’t know it’s own public IP, which is needed by, e.g. RTSP
The public IP can be learned from STUN server.
2. server is behind NAT. No private-to-public port map in NAT initially.
server talks to STUN to establish the map, and STUN tells client server’s public IP-port.
With STUN, for both restricted and unrestricted NAT, two hosts can talk to each other directly.
TCP is not discussed here, which is more complicated.

A few words on NAT type:
Cone: one private IP-port maps to one public IP-port, when talking to multiple destinations
Symmetric: one private IP-port maps to different public IP-port pairs for different destinations

Communication cannot be established if both A and B are behind symmetric NAT, because neither A nor B and the STUN server can possibly know B’s pubic port number.