NatT protocol - Revision history

Omeringen: Undo revision 2887 by SierraGranai (Talk)

2010-07-22T17:53:22Z

Undo revision 2887 by SierraGranai (Talk)

2010-07-22T13:33:44Z

Introduction

2007-10-17T19:50:04Z

OpCodes

2007-07-25T10:25:52Z

Neo XS

2007-07-23T13:50:19Z

NAT Tunneling: fix

2007-07-23T08:28:09Z

XS (Neo & Co)

2007-07-21T08:43:30Z

2007-07-21T08:41:44Z

2007-07-21T08:37:08Z

2007-07-20T07:42:42Z

Kad (*Unofficial*)

@@ Line 5: / Line 5: @@
 NAT (Network Address Translation) Traversal allows Low ID to Low ID connections.
 There are different techniques to achieve this, like STUN (Simple Traversal of UDP through NATs), or TURN (Traversal Using Relay NAT). For obvious reasons TURN is not suitable for any kind of file sharing applications.
-The NatT for eMule uses there for STUN, as well as a attempt to become a High ID by reusing the Listening port for outgoing connections, if the NAT device is a Full Cone this technique will [http://www.casino-spielen.biz/spielautomat/ automaten spiele] make the client fully connectible, but it works only in a few cases.
+The NatT for eMule uses there for STUN, as well as a attempt to become a High ID by reusing the Listening port for outgoing connections, if the NAT device is a Full Cone this technique will make the client fully connectible, but it works only in a few cases.
 The main implementation using STUN can connect even through hardware firewalls, it only fails on Symmetric NAT’s, there are as well methods to penetrate these but they require to much overhead and are there fore like TURN not suitable for file sharing.

@@ Line 5: / Line 5: @@
 NAT (Network Address Translation) Traversal allows Low ID to Low ID connections.
 There are different techniques to achieve this, like STUN (Simple Traversal of UDP through NATs), or TURN (Traversal Using Relay NAT). For obvious reasons TURN is not suitable for any kind of file sharing applications.
-The NatT for eMule uses there for STUN, as well as a attempt to become a High ID by reusing the Listening port for outgoing connections, if the NAT device is a Full Cone this technique will make the client fully connectible, but it works only in a few cases.
+The NatT for eMule uses there for STUN, as well as a attempt to become a High ID by reusing the Listening port for outgoing connections, if the NAT device is a Full Cone this technique will [http://www.casino-spielen.biz/spielautomat/ automaten spiele] make the client fully connectible, but it works only in a few cases.
 The main implementation using STUN can connect even through hardware firewalls, it only fails on Symmetric NAT’s, there are as well methods to penetrate these but they require to much overhead and are there fore like TURN not suitable for file sharing.

← Older revision		Revision as of 19:50, 17 October 2007
Line 512:		Line 512:

	Note: The UDP range 0xD0 to 0xDF is completely reserver for NatT		Note: The UDP range 0xD0 to 0xDF is completely reserver for NatT
		+
		+	== See also ==
		+
		+	* [[Nattraversal]]

	[[category:Mod_protocol_extensions]]		[[category:Mod_protocol_extensions]]

@@ Line 254: / Line 254: @@
 The Source Packet is built the following way:
 <pre>
-[hast128 16]    // file hash
+[hash128 16]    // file hash
 [uint16 2]      // source count
 // Source entries 1:

@@ Line 30: / Line 30: @@
 <pre>
 [uint8] pOPS   // bit Field
-                // 4 reserved
+                // 5 reserved
-                // 3 IdKind
+                // 2 IdKind
                 // 1 req answer
 [ID]           // variable length determined by the Ping Options above may not be set at all

@@ Line 143: / Line 143: @@
 </pre>
-Please refer to the Additional Features for NatT section for further informations on the XS Buddy feature.
+Please refer to the [[NatT_protocol#Additional Features for NatT|Additional Features for NatT]] section for further informations on the XS Buddy feature.
 == User Mode TCP ==

← Older revision		Revision as of 08:43, 21 July 2007
Line 513:		Line 513:
	Note: The UDP range 0xD0 to 0xDF is completely reserver for NatT		Note: The UDP range 0xD0 to 0xDF is completely reserver for NatT

−	[[category:~~Mod_protocol_Extensions~~]]	+	[[category:Mod_protocol_extensions]]

← Older revision		Revision as of 08:41, 21 July 2007
Line 513:		Line 513:
	Note: The UDP range 0xD0 to 0xDF is completely reserver for NatT		Note: The UDP range 0xD0 to 0xDF is completely reserver for NatT

−	[[category:~~ModProtocol~~]]	+	[[category:Mod_protocol_Extensions]]

← Older revision		Revision as of 08:37, 21 July 2007
Line 512:		Line 512:

	Note: The UDP range 0xD0 to 0xDF is completely reserver for NatT		Note: The UDP range 0xD0 to 0xDF is completely reserver for NatT
		+
		+	[[category:ModProtocol]]

@@ Line 112: / Line 112: @@
 [hash128 16]     // File Hash of the pinged file
 // the part below is the unofficial mod part (unchanged)
 ...
 </pre>