TCP Stream Connection and Handshaking - Revision history

Dcat: /* Introduction */

2008-12-31T14:57:51Z

Introduction

← Older revision		Revision as of 14:57, 31 December 2008
Line 5:		Line 5:

	TCP stream connections are established between Gnutella2 nodes when they elect to		TCP stream connections are established between Gnutella2 nodes when they elect to
	form a ~~permeant~~ link, creating the fundamental network topology of a highly		form a permanent link, creating the fundamental network topology of a highly
	interconnected hub network serving dense clusters of leaf nodes.		interconnected hub network serving dense clusters of leaf nodes.

Ag: /* Node State Negotiation */

2007-09-20T20:34:08Z

Node State Negotiation

← Older revision		Revision as of 20:34, 20 September 2007
Line 179:		Line 179:
	</pre>		</pre>

	- NOTE: because X-Ultrapeer and X-Ultrapeer-Needed has been used on Gnutella2 for longtime, there should be some ~~backword~~ compatibility code to comunicate with older nodes until they ~~disapper~~.		- NOTE: because X-Ultrapeer and X-Ultrapeer-Needed has been used on Gnutella2 for a longtime, there should be some backward compatibility code to comunicate with older nodes until they disappear.

	=== Hub Address Exchange ===		=== Hub Address Exchange ===

Ag: /* Content Type (Protocol) */

2007-09-20T20:00:15Z

Content Type (Protocol)

← Older revision		Revision as of 20:00, 20 September 2007
Line 116:		Line 116:
	The first step is to advertise support for the content type (Gnutella2) in the first		The first step is to advertise support for the content type (Gnutella2) in the first
	header block with "Accept: application/x-gnutella2". The responding node will then		header block with "Accept: application/x-gnutella2". The responding node will then
	indicate that it will send Gnutella2 content with "Content-Type: application/~~xgnutella2~~",		indicate that it will send Gnutella2 content with "Content-Type: application/x-gnutella2",
	and that it also supports Gnutella2 with "Accept: application/x-gnutella2".		and that it also supports Gnutella2 with "Accept: application/x-gnutella2".
	The initiating host then confirms that it will be sending Gnutella2 with "Content-		The initiating host then confirms that it will be sending Gnutella2 with "Content-

CyberBob: changed "X-Ultrapeer" to "X-Hub". this should be used for Gnutella2

2007-03-28T16:54:03Z

changed "X-Ultrapeer" to "X-Hub". this should be used for Gnutella2

← Older revision		Revision as of 16:54, 28 March 2007
Line 37:		Line 37:
	User-Agent: Shareaza 1.8.2.0		User-Agent: Shareaza 1.8.2.0
	Accept: application/x-gnutella2		Accept: application/x-gnutella2
	X-~~Ultrapeer~~: False		X-Hub: False
	</nowiki>		</nowiki>
	</pre>		</pre>
Line 51:		Line 51:
	Content-Type: application/x-gnutella2		Content-Type: application/x-gnutella2
	Accept: application/x-gnutella2		Accept: application/x-gnutella2
	X-~~Ultrapeer~~: True		X-Hub: True
	X-~~Ultrapeer~~-Needed: False		X-Hub-Needed: False
	</nowiki>		</nowiki>
	</pre>		</pre>
Line 63:		Line 63:
	GNUTELLA/0.6 200 OK		GNUTELLA/0.6 200 OK
	Content-Type: application/x-gnutella2		Content-Type: application/x-gnutella2
	X-~~Ultrapeer~~: False		X-Hub: False
			</nowiki>
			</pre>

	The latter two stages may be replaced with an error condition if the connection is		The latter two stages may be replaced with an error condition if the connection is
	being rejected. Appropriate error status codes are returned in this case, for example:		being rejected. Appropriate error status codes are returned in this case, for example:

			<pre>
			<nowiki>
	GNUTELLA/0.6 503 Too many connections		GNUTELLA/0.6 503 Too many connections
	(more headers)		(more headers)
Line 132:		Line 138:

	As the handshake sequence is compatible with Gnutella1, the headers involved in		As the handshake sequence is compatible with Gnutella1, the headers involved in
	negotiating node types ~~are~~ identical to those used to negotiate Gnutella1 ~~"Ultrapeer"~~		negotiating node types should not be identical to those used to negotiate Gnutella1 to minimize network pollution.
	states:		states:

	<pre>		<pre>
	<nowiki>		<nowiki>
	X-~~Ultrapeer~~: [True\|False]		X-Hub: [True\|False]
	X-~~Ultrapeer~~-Needed: [True\|False]		X-Hub-Needed: [True\|False]
	</nowiki>		</nowiki>
	</pre>		</pre>
Line 144:		Line 150:
	Both headers contain a Boolean value, "true" or "false", case insensitive.		Both headers contain a Boolean value, "true" or "false", case insensitive.

	The X-~~Ultrapeer~~ header indicates whether the transmitting node is currently		The X-Hub header indicates whether the transmitting node is currently
	operating as a hub. Hub nodes will send "X-~~Ultrapeer~~: True" while leaf nodes will		operating as a hub. Hub nodes will send "X-Hub: True" while leaf nodes will
	send "X-~~Ultrapeer~~: False".		send "X-Hub: False".

	The X-~~Ultrapeer~~-Needed header indicates whether the transmitting node would like		The X-Hub-Needed header indicates whether the transmitting node would like
	(and allow) the receiver to be a hub. A hub which sees no need for additional hubs in		(and allow) the receiver to be a hub. A hub which sees no need for additional hubs in
	its area of the network, will send "X-~~Ultrapeer~~-Needed: False", indicating to the		its area of the network, will send "X-Hub-Needed: False", indicating to the
	connecting node that it must operate in leaf mode if it wishes to connect. A hub		connecting node that it must operate in leaf mode if it wishes to connect. A hub
	which sees a need for additional hubs, will send "X-~~Ultrapeer~~-Needed: True",		which sees a need for additional hubs, will send "X-Hub-Needed: True",
	indicating that the receiving node should become a hub, if it is capable of doing so. A		indicating that the receiving node should become a hub, if it is capable of doing so. A
	leaf may send "X-~~Ultrapeer~~-Needed: True" to indicate that it is seeking a connection		leaf may send "X-Hub-Needed: True" to indicate that it is seeking a connection
	to a hub.		to a hub.

	The X-~~Ultrapeer~~ header should be sent on all three of the header blocks to indicate		The X-Hub header should be sent on all three of the header blocks to indicate
	the current intended state of the node, while the X-~~Ultrapeer~~-Needed header should		the current intended state of the node, while the X-Hub-Needed header should
	be sent in the first two header blocks only, to indicate the desired status of the		be sent in the first two header blocks only, to indicate the desired status of the
	receiver. If the nodes cannot agree on a satisfactory arrangement, the connection		receiver. If the nodes cannot agree on a satisfactory arrangement, the connection
Line 172:		Line 178:
	</nowiki>		</nowiki>
	</pre>		</pre>

			- NOTE: because X-Ultrapeer and X-Ultrapeer-Needed has been used on Gnutella2 for longtime, there should be some backword compatibility code to comunicate with older nodes until they disapper.

	=== Hub Address Exchange ===		=== Hub Address Exchange ===

Daisuke: /* Hub Address Exchange */

2007-01-10T14:16:50Z

Hub Address Exchange

← Older revision		Revision as of 14:16, 10 January 2007
Line 181:		Line 181:
	helpful.		helpful.

	The X-Try-~~Ultrapeers~~ header was developed for this purpose~~, and like the rest of~~		The X-Try-Hubs header was developed for this purpose. It contains a comma
	~~the handshake is also semi-compatible with Gnutella1~~. It contains a comma
	separated list of hub node addresses and ports, along with a timestamp recording		separated list of hub node addresses and ports, along with a timestamp recording
	the time the hub was last seen. For example:		the time the hub was last seen. For example:
Line 188:		Line 187:
	<pre>		<pre>
	<nowiki>		<nowiki>
	X-Try-~~Ultrapeers~~: 1.2.3.4:6346 ~~2003~~-03-~~25T23~~:59Z, [..more..]		X-Try-Hubs: 1.2.3.4:6346 2007-01-10T23:59Z, [..more..]
	</nowiki>		</nowiki>
	</pre>		</pre>

	Hub addresses should not be sent unless the transmitter has reasonable knowledge		Hub addresses should not be sent unless the transmitter has reasonable knowledge
	of the hub's existence and the timestamp is not too old~~. The content type negotiation~~		of the hub's existence and the timestamp is not too old.
	~~headers should be used to verify that the listed hub addresses are indeed Gnutella2~~
	~~hubs~~.

	=== Compression Negotiation and Encoding ===		=== Compression Negotiation and Encoding ===

Spooky: Nav element added

2005-04-02T22:21:33Z

Nav element added

← Older revision		Revision as of 22:21, 2 April 2005
Line 1:		Line 1:
			[[UDP_Transceiver\|UDP Transceiver >>]] \| [[Main_Page\|Main Page]]


	== Introduction ==		== Introduction ==

Kath: /* Post Handshake Communication */

2005-03-27T14:44:35Z

Post Handshake Communication

← Older revision		Revision as of 14:44, 27 March 2005
Line 248:		Line 248:
	communication over the TCP stream occurs in the negotiated protocol, with the		communication over the TCP stream occurs in the negotiated protocol, with the
	negotiated encoding. This means that while the handshake sequence was backwards		negotiated encoding. This means that while the handshake sequence was backwards
	compatible with Gnutella1, after Gnutella2 support has been negotiated all		compatible with Gnutella1, after Gnutella2 support has been negotiated, all
	subsequent communication occurs in the Gnutella2 common protocol - an entirely		subsequent communication occurs in the Gnutella2 common protocol - an entirely
	new system not backwards compatible with any other protocol.		new system not backwards compatible with any other protocol.

Kath: /* Compression Negotiation and Encoding */

2005-03-27T14:42:51Z

Compression Negotiation and Encoding

Kath: /* Node State Negotiation */

2005-03-27T14:36:39Z

Node State Negotiation

Kath: /* Content Type (Protocol) */

2005-03-27T14:28:21Z

Content Type (Protocol)

← Older revision		Revision as of 14:28, 27 March 2005
Line 113:		Line 113:
	Accept/Content-Type exchange, consult a HTTP reference.		Accept/Content-Type exchange, consult a HTTP reference.

	Note that the content type negotiation process is designed to be a "one way"		Note that the content type negotiation process is designed to be a "one-way"
	process, i.e. a different content type can be negotiated for sending and receiving.		process, i.e. a different content type can be negotiated for sending and receiving.
	However when the gnutella2 protocol is negotiated, both channels must use the		However, when the gnutella2 protocol is negotiated, both channels must use the
	same content type. This means that a receiving node must not accept Gnutella2 if		same content type. This means that a receiving node must not accept Gnutella2 if
	the initiator did not advertise support for it, and if at the end of the handshake		the initiator did not advertise support for it, and if at the end of the handshake,
	bidirectional Gnutella2 was not negotiated, the connection should be terminated.		bidirectional Gnutella2 was not negotiated, the connection should be terminated.

← Older revision		Revision as of 14:42, 27 March 2005
Line 198:		Line 198:
	The Gnutella2 architecture makes widespread use of "deflate" compression, due to		The Gnutella2 architecture makes widespread use of "deflate" compression, due to
	its high availability and ease of integration. Support of compressed TCP links is not a		its high availability and ease of integration. Support of compressed TCP links is not a
	requirement in the Gnutella2 standard, however it is strongly recommended.		requirement in the Gnutella2 standard, however, it is strongly recommended.

	Deflate compression of a TCP link is negotiated with the pair standard HTTP headers		Deflate compression of a TCP link is negotiated with the pair standard HTTP headers
Line 228:		Line 228:
	</pre>		</pre>

	In this example the initiator advertises support for receiving a deflated connection.		In this example, the initiator advertises support for receiving a deflated connection.
	The receiver then indicates that it too supports receiving a deflated connection, and		The receiver then indicates that it too supports receiving a deflated connection, and
	that it intends to transmit deflated data. Finally, the initiator upon noting that the		that it intends to transmit deflated data. Finally, the initiator upon noting that the
	receiver supports deflate indicates that it too will transmit deflated data.		receiver supports deflate, indicates that it too will transmit deflated data.

	Note that unlike the content-type / protocol negotiation, deflated encoding can be		Note that unlike the content-type / protocol negotiation, deflated encoding can be
	applied on either incoming, outgoing or both channels of a connection.		applied on either incoming, outgoing, or both channels of a connection.

	For performance reasons, nodes should consider whether they can afford to support		For performance reasons, nodes should consider whether they can afford to support
	additional deflated connections before advertising support for them, or agreeing to		additional deflated connections before advertising support for them, or agreeing to
	provide a deflated data stream. In the Gnutella2 network topology, all links benefit		provide a deflated data stream. In the Gnutella2 network topology, all links benefit
	from compression except the leaf to hub channel of the leaf/hub link. Exempting this		from compression, except the leaf to hub channel of the leaf/hub link. Exempting this
	channel from compression saves the leaf and more importantly the hub a		channel from compression, saves the leaf and more importantly, the hub, a
	considerable CPU and RAM investment.		considerable CPU and RAM investment.

← Older revision		Revision as of 14:36, 27 March 2005
Line 122:		Line 122:
	=== Node State Negotiation ===		=== Node State Negotiation ===

	There are two node types in a Gnutella2 peer to peer network, a hub and a leaf as		There are two node types in a Gnutella2 peer to peer network, a hub and a leaf, as
	described in [[Node Types and Responsibilities]]. During the initial handshake		described in [[Node Types and Responsibilities]]. During the initial handshake,
	the two parties must exchange their current node type and advise of their		the two parties must exchange their current node type and advise of their
	capabilities, negotiating the node types they will adopt when the connection		capabilities, negotiating the node types they will adopt when the connection
Line 147:		Line 147:
	The X-Ultrapeer-Needed header indicates whether the transmitting node would like		The X-Ultrapeer-Needed header indicates whether the transmitting node would like
	(and allow) the receiver to be a hub. A hub which sees no need for additional hubs in		(and allow) the receiver to be a hub. A hub which sees no need for additional hubs in
	its area of the network will send "X-Ultrapeer-Needed: False", indicating to the		its area of the network, will send "X-Ultrapeer-Needed: False", indicating to the
	connecting node that it must operate in leaf mode if it wishes to connect. A hub		connecting node that it must operate in leaf mode if it wishes to connect. A hub
	which sees a need for additional hubs will send "X-Ultrapeer-Needed: True",		which sees a need for additional hubs, will send "X-Ultrapeer-Needed: True",
	indicating that the receiving node should become a hub if it is capable of doing so. A		indicating that the receiving node should become a hub, if it is capable of doing so. A
	leaf may send "X-Ultrapeer-Needed: True" to indicate that it is seeking a connection		leaf may send "X-Ultrapeer-Needed: True" to indicate that it is seeking a connection
	to a hub.		to a hub.
Line 156:		Line 156:
	The X-Ultrapeer header should be sent on all three of the header blocks to indicate		The X-Ultrapeer header should be sent on all three of the header blocks to indicate
	the current intended state of the node, while the X-Ultrapeer-Needed header should		the current intended state of the node, while the X-Ultrapeer-Needed header should
	be sent in the first two header blocks only to indicate the desired status of the		be sent in the first two header blocks only, to indicate the desired status of the
	receiver. If the nodes cannot agree on a satisfactory arrangement, the connection		receiver. If the nodes cannot agree on a satisfactory arrangement, the connection
	will be terminated at or prior to the third header block with an appropriate message,		will be terminated at or prior to the third header block with an appropriate message,