Nattraversal - Revision history

Omeringen at 21:14, 6 May 2010

2010-05-06T21:14:44Z

Omeringen at 20:58, 6 May 2010

2010-05-06T20:58:46Z

DavidXanatos at 06:44, 15 July 2007

2007-07-15T06:44:17Z

DavidXanatos at 06:43, 15 July 2007

2007-07-15T06:43:38Z

85.125.230.208 at 17:23, 17 June 2007

2007-06-17T17:23:41Z

Leuk he: text copy and image

2007-03-22T08:18:03Z

text copy and image

Leuk he at 08:17, 22 March 2007

2007-03-22T08:17:11Z

Leuk he at 21:14, 21 March 2007

2007-03-21T21:14:24Z

Leuk he: New page: todo.

2007-03-21T21:13:38Z

New page: todo.

New page

todo.

← Older revision		Revision as of 21:14, 6 May 2010
Line 22:		Line 22:
	Developed by David Xanatos, [[Neomule]].		Developed by David Xanatos, [[Neomule]].

−	[[Category:Features]][[Category:NeoMule ~~Features~~]]	+	[[Category:Features]][[Category:NeoMule features]]

← Older revision		Revision as of 20:58, 6 May 2010
Line 22:		Line 22:
	Developed by David Xanatos, [[Neomule]].		Developed by David Xanatos, [[Neomule]].

−	[[~~category~~:~~features~~]][[~~category~~:~~NeoFeatures~~]]	+	[[Category:Features]][[Category:NeoMule Features]]

@@ Line 1: / Line 1: @@
 ''nat traversal'' Makes LowID to LowID connections possible in by creating a UDP tunnel.
-[image:http://wiki.emule-web.de/image/Nat-traverse-net.gif]
+http://wiki.emule-web.de/image/Nat-traverse-net.gif
 The basic tunneling procedure is:
@@ Line 13: / Line 13: @@
 UmTCP Sync    ..................
 </pre>
-<nowiki>*</nowili> The remote callback is needed in order to tell the requester the actual UDP port of the target client.
+<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.

@@ Line 1: / Line 1: @@
-''nat traversal'' Makes LowID to LowID connections posible in most cases by creating a tunnel.
+''nat traversal'' Makes LowID to LowID connections possible in by creating a UDP tunnel.
 [image:http://wiki.emule-web.de/image/Nat-traverse-net.gif]
-. 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)
+The basic tunneling procedure is:
-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….
+After the tunnel is made the 2 clients starts an streaming connection similar to TCP but self made.<br>
-. 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…
+Developed by David Xanatos, [[Neomule]].
-−
-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]][[category:NeoFeatures]]

← Older revision		Revision as of 17:23, 17 June 2007
Line 17:		Line 17:
	developed by david xanatos, Neomule.		developed by david xanatos, Neomule.

−	[[category:features]]	+	[[category:features]][[category:NeoFeatures]]

← Older revision		Revision as of 08:18, 22 March 2007
Line 1:		Line 1:
	''nat traversal'' Makes LowID to LowID connections posible in most cases by creating a tunnel.		''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)		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)

← Older revision		Revision as of 08:17, 22 March 2007
Line 1:		Line 1:
−	~~todo~~.	+	''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]]

← Older revision		Revision as of 21:14, 21 March 2007
Line 1:		Line 1:
	todo.		todo.
		+
		+	[image:http://wiki.emule-web.de/image/Nat-traverse-net.gif]