doc: Improve PacketHandshake explanation (#124)

Closes #123

docs/netfox.noray/assets/packet-handshake.uml

@@ -1,15 +1,28 @@
 @startuml
 
 actor "Player A" as A
+entity "Router A" as RA
 boundary Internet as Net
+entity "Router B" as RB
 actor "Player B" as B
 
-A -> Net : "$-w-"
-B -> Net: "$-w-"
-A -> B : "$-w-"
-B -> A : "$rw-"
-A -> B : "$rw-"
-B -> A : "$rwx"
-A -> B : "$rwx"
+A ->x RB : $-w-
+note over RB: Packet denied
+
+B ->x RA : $-w-
+note over RA: Packet denied
+
+note over RA, RB: NAT table updated on both routers
+
+A -> B: $-w-
+note over RB: Packed allowed
+
+B -> A: $-w-
+note over RB: Packed allowed
+
+A -> B: $rwx
+B -> A: $rwx
+
+note over Net #lightgreen: Connection established
 
 @enduml

docs/netfox.noray/guides/packet-handshake.md

@@ -10,10 +10,32 @@ This is an important step before establishing connection for actual game
 play, as this lets both the client's and server's routers ( if any ) know 
 that traffic is expected and should be let through.
 
+## NAT punchthrough
+
+Most players are behind a router. Routers are directly connected to the
+internet, and protect machines behind them from unwanted traffic.
+
+When routers receive packets from an unknown source, those packets are rejected
+and don't reach the player's device. When data was sent to that address first,
+routers see traffic as a reply and allow incoming data.
+
+To take an example, if a random PC starts sending traffic your way, the router
+will reject it. If you send data to the host behind godotengine.org, your
+router will allow incoming traffic from it. Otherwise, you wouldn't be able to
+open the website in your browser, as the incoming HTTP response would be
+rejected.
+
+This can be used to our advantage. If both players start sending traffic
+towards eachother, eventually the routers will assume it's a response to some
+request and allow the traffic.
+
+> This is a very simplified description of how routers work. NAT punchthrough
+> does not always work. For further reading, see [Network address translation].
+
 ## Handshake process
 
-To confirm two-way connectivity, a special string is sent back and forth,
-encoding the player's knowledge about the connection:
+To confirm two-way connectivity, a string is sent back and forth, encoding the
+player's knowledge about the connection:
 
 The *Read flag* is set once we have received data from the other player.
 
@@ -27,7 +49,8 @@ both ways.
 The handshake process is successful when both players have the *Duplex flag*
 set *and* both players know that the other player has the *Duplex flag* set.
 
-Each flag is encoded as its specific character or a hyphen. The encoded string is prepended with a dollar sign. For example:
+Each flag is encoded as its specific character or a hyphen. The encoded string
+is prepended with a dollar sign. For example:
 
 * *$rw-* means that we have sent and received data from the other player
 * *$rwx* means that the *read*, *write*, and *duplex* flags are all set
@@ -56,3 +79,5 @@ until timeout. Handshake will always be considered successful.
 
 If the connectivity exists, players will simply connect. Otherwise,
 connectivity will fail as expected, regardless of the handshake results.
+
+[Network address translation]: https://en.wikipedia.org/wiki/Network_address_translation