Editing Nattraversal

''nat traversal'' Makes LowID to LowID connections posible in most cases by creating a tunnel.

[image:http://wiki.emule-web.de/image/Nat-traverse-net.gif]

1. The local client (A) is a normal NATed client, the remote client (B) is behind a Full Cone NAT (incoming UDP packets from any host will be forwarded instantly)

In this case we don’t need the KAD buddy, we send a UDP packet (2 bytes ProtID+Opcode) (NAT Ping) to B this enabling our NAT to forward incoming packets to us. The remote side answers with a own ping when we gets the remote NAT ping we have a tunnel….

2. Client A is behind a Full Cone NAT and client B is behind a normal NAT We send ping request over the buddy (E) of B, When B receives it he send’s a NAT ping packet to us, when we receive the packet we have a tunnel…

3. A and B are behind normal NATs A sends a ping request over E to B and in the request request’s a remote request. When B receives the Ping request from E he sends a NAT Ping to A, whitch is expected to be dropped on A’s NAT. And He sends a own Ping request to A over A’s buddy E2. When A gets the remote Ping Request he have the most actual extern UDP port of B and send a NAT Ping on this port. B receives the NAT ping and answers with a own second NAT Ping, when the ping arrives by A we have a Tunel…

3b. A and B are behind normal NATs, we trust the UDP port B have published on KAD A sends a ping request over E to B and at the same time sends a NAT Ping to B, this enabling our NAT to forward packets from B to us, the ping is expected to be dropped on B’s NAT. When B receives the Ping request from E he sends a NAT Ping to A, when the ping arrives by A we have a Tunel…

When A see that a tunnel is established he send’s a NAT Config Packet which contains some configuration informations for the Streaming connection. When B receives the config he send the own config. At the moment when A or B have send a config and got the remote the Streaming connection is being activated. A have the choice to send the config or not to send, in case he don’t send we remain in UDP mode for example for an UDP file Reask Ping saving us some overhead.

developed by david xanatos, Neomule. 

[[category:features]]
@@ Line 1: / Line 1: @@
-''nat traversal'' Makes LowID to LowID connections possible in by creating a UDP tunnel.
+''nat traversal'' Makes LowID to LowID connections posible in most cases by creating a tunnel.
-http://wiki.emule-web.de/image/Nat-traverse-net.gif
+[image:http://wiki.emule-web.de/image/Nat-traverse-net.gif]
-The basic tunneling procedure is:
+. The local client (A) is a normal NATed client, the remote client (B) is behind a Full Cone NAT (incoming UDP packets from any host will be forwarded instantly)
-<pre>
-Requester(A)      Kad/Svr/Xs         Target(B)
-ReqCallback    -->           -->     A's IpPort
-[droped]      <----------------      SendPing
-B's IpPort    <--           <--      ReqCallback*
-SendPing       ---------------->
-              <----------------      SendPong
-UmTCP Sync    ..................
-</pre>
-<nowiki>*</nowiki> The remote callback is needed in order to tell the requester the actual UDP port of the target client.
-It is not always the case that the ping from B is dropped on FullConeNats it can pass through, there for the remote callback is delayed by a few seconds to see if A answers with a Ping.
-After the tunnel is made the 2 clients starts an streaming connection similar to TCP but self made.<br>
+In this case we don’t need the KAD buddy, we send a UDP packet (2 bytes ProtID+Opcode) (NAT Ping) to B this enabling our NAT to forward incoming packets to us. The remote side answers with a own ping when we gets the remote NAT ping we have a tunnel….
-The So called "User Mode TCP" can almost everything the normal TCP can, it handles missing or duplicated packets, as well as packets arriving out of order. It have full TCP congestion control implemented. All this assures a fast and reliable streaming connection.
+. Client A is behind a Full Cone NAT and client B is behind a normal NAT We send ping request over the buddy (E) of B, When B receives it he send’s a NAT ping packet to us, when we receive the packet we have a tunnel…
-Developed by David Xanatos, [[Neomule]].
+. A and B are behind normal NATs A sends a ping request over E to B and in the request request’s a remote request. When B receives the Ping request from E he sends a NAT Ping to A, whitch is expected to be dropped on A’s NAT. And He sends a own Ping request to A over A’s buddy E2. When A gets the remote Ping Request he have the most actual extern UDP port of B and send a NAT Ping on this port. B receives the NAT ping and answers with a own second NAT Ping, when the ping arrives by A we have a Tunel…
-[[Category:Features]][[Category:NeoMule features]]
+b. A and B are behind normal NATs, we trust the UDP port B have published on KAD A sends a ping request over E to B and at the same time sends a NAT Ping to B, this enabling our NAT to forward packets from B to us, the ping is expected to be dropped on B’s NAT. When B receives the Ping request from E he sends a NAT Ping to A, when the ping arrives by A we have a Tunel…
+When A see that a tunnel is established he send’s a NAT Config Packet which contains some configuration informations for the Streaming connection. When B receives the config he send the own config. At the moment when A or B have send a config and got the remote the Streaming connection is being activated. A have the choice to send the config or not to send, in case he don’t send we remain in UDP mode for example for an UDP file Reask Ping saving us some overhead.
+developed by david xanatos, Neomule.
+[[category:features]]