But it's not only one. It's many. It's the same as other things but it exactly likes nothing else...
Clients Behind Different NATs
Suppose clients A and B both have private IP addresses and lie behind
different network address translators. The peer-to-peer application
running on clients A and B and on server S each use UDP port 1234. A
and B have each initiated UDP communication sessions with server S,
causing NAT A to assign its own public UDP port 62000 for A's session
with S, and causing NAT B to assign its port 31000 to B's session
with S, respectively.
Server S
18.181.0.31:1234
|
+----------------------+----------------------+
| |
NAT A NAT B
155.99.25.11:62000 138.76.29.7:31000
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Now suppose that client A wants to establish a UDP communication
session directly with client B. If A simply starts sending UDP
requests to B's public address, 138.76.29.7:31000, then NAT B will
typically discard these incoming messages because the source address
and port number does not match those of S, with which the original
outgoing session was established. Similarly, if B simply starts
sending UDP requests to A's public address, then NAT A will discard
these messages.
Suppose A starts sending UDP requests to B's public address, however,
and simultaneously relays a request through server S to B, asking B
to start sending UDP requests to A's public address. A's outgoing
messages directed to B's public address (138.76.29.7:31000) will
cause NAT A to open up a new communication session between A's
private address and B's public address. At the same time, B's
messages to A's public address (155.99.25.11:62000) will cause NAT B
to open up a new communication session between B's private address
and A's public address. Once the new UDP sessions have been opened
up in each direction, client A and B can communicate with each other
directly without further reference to or burden on the "introduction"
server S
My doggie BEN said:Smiling is a good beginning of a wonderful day.
