Private:pCDN:Peer Matching - Revision history

Aah10 at 01:54, 7 August 2010

2010-08-07T01:54:00Z

Aah10 at 22:53, 18 September 2009

2009-09-18T22:53:12Z

Ahmed at 21:50, 20 May 2009

2009-05-20T21:50:35Z

Ahmed at 13:21, 26 April 2009

2009-04-26T13:21:57Z

Ahmed at 13:06, 26 April 2009

2009-04-26T13:06:48Z

Ahmed at 13:10, 24 April 2009

2009-04-24T13:10:37Z

Ahmed at 13:07, 24 April 2009

2009-04-24T13:07:02Z

Ahmed at 07:23, 21 April 2009

2009-04-21T07:23:38Z

Ahmed at 10:56, 2 April 2009

2009-04-02T10:56:48Z

Ahmed at 21:12, 1 April 2009

2009-04-01T21:12:02Z

@@ Line 93: / Line 93: @@
 * Explanation of some of the funny words used in BitTorrent
 ** http://azureuswiki.com/index.php/This_funny_word
 * C. Tian, X. Liu, H. Jiang, W. Liu, and Y. Wang, “Improving BitTorrent traffic performance by exploiting geographic locality,” in IEEE Global Telecommunications Conference (GLOBECOM 2008), 30 2008-Dec. 4 2008, pp. 1–5.
 * B. Liu, Y. Cui, Y. Lu, and Y. Xue, “Locality-awareness in BitTorrent-like P2P applications,” IEEE Transactions on Multimedia, vol. 11, no. 3, pp. 361–371, April 2009.

@@ Line 89: / Line 89: @@
 * AT & T IP-Range and ASNum mapping
 ** a.	http://www.research.att.com/~jiawang/as_traceroute/
 * C. Tian, X. Liu, H. Jiang, W. Liu, and Y. Wang, “Improving BitTorrent traffic performance by exploiting geographic locality,” in IEEE Global Telecommunications Conference (GLOBECOM 2008), 30 2008-Dec. 4 2008, pp. 1–5.
 * B. Liu, Y. Cui, Y. Lu, and Y. Xue, “Locality-awareness in BitTorrent-like P2P applications,” IEEE Transactions on Multimedia, vol. 11, no. 3, pp. 361–371, April 2009.

← Older revision		Revision as of 21:50, 20 May 2009
Line 96:		Line 96:
	* M. Steiner and E. W. Biersack, “Where is my peer? Evaluation of the Vivaldi network coordinate system in Azureus,” in Work in Progress Proceedings of the 8th International IFIP-TC6 Networking Conference (Networking 2009), Aachen, Germany, May 2009.		* M. Steiner and E. W. Biersack, “Where is my peer? Evaluation of the Vivaldi network coordinate system in Azureus,” in Work in Progress Proceedings of the 8th International IFIP-TC6 Networking Conference (Networking 2009), Aachen, Germany, May 2009.
	* S. L. Blond, A. Legout, and W. Dabbous, “Pushing BitTorrent locality to the limit,” INRIA, Tech. Rep. INRIA-00343822, Dec. 2008.		* S. L. Blond, A. Legout, and W. Dabbous, “Pushing BitTorrent locality to the limit,” INRIA, Tech. Rep. INRIA-00343822, Dec. 2008.
		+	* Z. Chen, H. Yin, C. Lin, F. Wu, and X. Liu, "Towards a Universal Friendly P2P Media Streaming Application: An Evaluation Framework," LNCS 5353, Springer, 2008.
		+	* B. Liu, Y. Lu, Y. Cui, and Y. Xue, "A Measurement Study on AS-aware P2P Streaming Strategies," in Proceedings of the 3rd International Conference on Communications and Networking, China, 2008.

@@ Line 5: / Line 5: @@
 == Brief Description of BitTorrent ==
-In BitTorrent (BT), a content file is split into several pieces (typically 256KB in size). A separate file, called the '''torrent''' file, containing some metadata about the original file is then created by the content provider and uploaded to a central server called the '''tracker'''. The tracker keeps track of all peers participating in distributing the file. The metadata  contained within the torrent file include: the ''address of the tracker'', the chosen ''piece size'', and an ''SHA-1 hash for each piece''.
+In BitTorrent (BT), a content file is split into several '''pieces''' (typically 256KB in size). The pieces are sub-divided further into what are called '''blocks''' - typically 16K. A separate file, called the '''torrent''' file, containing some metadata about the original file is then created by the content provider and uploaded to a central server called the '''tracker'''. The tracker keeps track of all peers participating in distributing the file. The metadata  contained within the torrent file include: the ''address of the tracker'', the chosen ''piece size'', and an ''SHA-1 hash for each piece''.
 Peers wishing to download the file first obtain the torrent file by downloading it from a Web server via the Hyper-Text Transfer Protocol (HTTP). The client running on the peer then contacts the tracker to obtain a list of peers to start downloading the original content file from. The list returned by the tracker returns ''k'' number of peers (default is 50) which are chosen at random to the inquiring peer. After receiving this list, the peer attempts to connect with the majority of them and exchanges '''bitfield''' messages with them during the ''handshaking'' process. These messages advertise the availability information for the pieces that a peer already owns.

← Older revision		Revision as of 13:06, 26 April 2009
Line 16:		Line 16:

	The group of users that are collectively connected for a particular file are called the '''swarm'''. Example, if you start a BitTorrent client and it tells you that you're connected to 5 peers and 1 seeds, then the swarm consists of you and those 6 other people.		The group of users that are collectively connected for a particular file are called the '''swarm'''. Example, if you start a BitTorrent client and it tells you that you're connected to 5 peers and 1 seeds, then the swarm consists of you and those 6 other people.
		+
		+	When a download is almost complete, there's a tendency for the last few blocks to trickle in slowly. To speed this up, the client sends requests for all of its missing blocks to all of its peers. This is called the '''end-game mode'''. To keep this from becoming horribly inefficient, the client also sends a cancel to everyone else every time a block arrives. When to enter end game mode is an area of discussion. Some clients enter end game when all pieces have been requested.
		+
		+	Occasionally a BitTorrent peer will be choked by all peers which it was formerly downloading from. In such cases it will usually continue to get poor download rates until the optimistic unchoke finds better peers. To mitigate this problem, when over a minute goes by without getting any piece data while downloading from a peer, BitTorrent assumes it is "snubbed" by that peer and doesn't upload to it except as an optimistic unchoke. This frequently results in more than one concurrent optimistic unchoke, (an exception to the exactly one optimistic unchoke rule mentioned above), which causes download rates to recover much more quickly when they falter.

← Older revision		Revision as of 13:10, 24 April 2009
Line 14:		Line 14:

	If the client has not received anything after a certain period (default: 60 seconds), it marks a connection as '''snubbed''', in that the peer on the other end has chosen not to send. See the definition of choked for reasons why an uploader might mark a connection as choked. The real function of keeping track of this variable is to improve download speeds. Occasionally the client will find itself in a state where even though it is connected to many peers, it is choked by all of them. The client uses the snubbed flag in an attempt to prevent this situation. It notes that a peer with whom it would like to trade pieces with has not sent anything in a while, and rather than leaving it up to the optimistic choking to eventually select that peer, it instead reserves one of its upload slots for sending to that peer.		If the client has not received anything after a certain period (default: 60 seconds), it marks a connection as '''snubbed''', in that the peer on the other end has chosen not to send. See the definition of choked for reasons why an uploader might mark a connection as choked. The real function of keeping track of this variable is to improve download speeds. Occasionally the client will find itself in a state where even though it is connected to many peers, it is choked by all of them. The client uses the snubbed flag in an attempt to prevent this situation. It notes that a peer with whom it would like to trade pieces with has not sent anything in a while, and rather than leaving it up to the optimistic choking to eventually select that peer, it instead reserves one of its upload slots for sending to that peer.
		+
		+	The group of users that are collectively connected for a particular file are called the '''swarm'''. Example, if you start a BitTorrent client and it tells you that you're connected to 5 peers and 1 seeds, then the swarm consists of you and those 6 other people.
		+

	== Previous (2008) Simulation==		== Previous (2008) Simulation==

← Older revision		Revision as of 13:07, 24 April 2009
Line 13:		Line 13:
	When a peer gets unchoked, it has to decide which of the pieces that are available at the unchoking neighbor (and that it does not currently have) to request. This decision is based on an '''interest array''' that the peer creates and maintains after receiving the bitfield messages of its neighbors. This contains the number of neighboring peers owning each of the pieces of the file and is updated whenever the peer receives a have message from one of its neighbors announcing the availability of a new piece that the neighbor has just downloaded. A peer uses a '''local rarest-first''' policy in which it requests the piece that is least replicated. This policy enables fast replication of rarest pieces and ensures that torrent file will not become extinct in case a peer having these pieces leaves.		When a peer gets unchoked, it has to decide which of the pieces that are available at the unchoking neighbor (and that it does not currently have) to request. This decision is based on an '''interest array''' that the peer creates and maintains after receiving the bitfield messages of its neighbors. This contains the number of neighboring peers owning each of the pieces of the file and is updated whenever the peer receives a have message from one of its neighbors announcing the availability of a new piece that the neighbor has just downloaded. A peer uses a '''local rarest-first''' policy in which it requests the piece that is least replicated. This policy enables fast replication of rarest pieces and ensures that torrent file will not become extinct in case a peer having these pieces leaves.

		+	If the client has not received anything after a certain period (default: 60 seconds), it marks a connection as '''snubbed''', in that the peer on the other end has chosen not to send. See the definition of choked for reasons why an uploader might mark a connection as choked. The real function of keeping track of this variable is to improve download speeds. Occasionally the client will find itself in a state where even though it is connected to many peers, it is choked by all of them. The client uses the snubbed flag in an attempt to prevent this situation. It notes that a peer with whom it would like to trade pieces with has not sent anything in a while, and rather than leaving it up to the optimistic choking to eventually select that peer, it instead reserves one of its upload slots for sending to that peer.

	== Previous (2008) Simulation==		== Previous (2008) Simulation==

@@ Line 5: / Line 5: @@
 == Brief Description of BitTorrent ==
-In BitTorrent (BT), a content file is split into several pieces (typically 256KB in size). A separate file, called the torrent file, containing some metadata about the original file is then created by the content provider and uploaded to a central server called the tracker. The tracker keeps track of all peers participating in distributing the file. The metadata  contained within the torrent file include: the address of the tracker, the chosen piece size, and an SHA-1 hash for
+In BitTorrent (BT), a content file is split into several pieces (typically 256KB in size). A separate file, called the '''torrent''' file, containing some metadata about the original file is then created by the content provider and uploaded to a central server called the '''tracker'''. The tracker keeps track of all peers participating in distributing the file. The metadata  contained within the torrent file include: the ''address of the tracker'', the chosen ''piece size'', and an ''SHA-1 hash for each piece''.
-Peers wishing to download the file first obtain the torrent file by downloading it from a Web server via the Hyper-Text Transfer Protocol (HTTP). The client running on the peer then contacts the tracker to obtain a list of peers to start downloading the original content file from. The list returned by the tracker returns k number of peers (default is 50) which are chosen at random to the inquiring peer. After reveiving this list, the peer attempts to connect with the majority of them and exchanges bitfield messages with them during the handshaking process. These messages advertise the availability information for the pieces that a peer already owns.
+Peers wishing to download the file first obtain the torrent file by downloading it from a Web server via the Hyper-Text Transfer Protocol (HTTP). The client running on the peer then contacts the tracker to obtain a list of peers to start downloading the original content file from. The list returned by the tracker returns ''k'' number of peers (default is 50) which are chosen at random to the inquiring peer. After receiving this list, the peer attempts to connect with the majority of them and exchanges '''bitfield''' messages with them during the ''handshaking'' process. These messages advertise the availability information for the pieces that a peer already owns.
-If a neighbor has a piece that the peer needs, the peer informs the neighbor with an interested message. However, the neighbor is not obliged to send the piece to the requesting peer immediately. A peer decides which of its interested neighbors it should send data to based on a so called choking/unchoking mechanism which executes every 10 seconds. When a neighbor is choked, the peer will refuse to send pieces to it. An unchoke message is sent to a small number of neighbors (default is 4) to inform them of the willingness of the peer to send the pieces that they are interested in. The decision of which neighbors to unchoke is based on a tit-for-tat policy in which the peer unchokes those neighbors which have given data to it at a high rate. This policy enables BT to deter free riding (i.e. selfish peers choosing only to download without contributing). In addition, a fifth neighbor is randomly unchoked every 30 seconds (i.e. every three cycles of the chocking/unchoking process), this is called optimistic unchoking. Optimistic unchoking is important in order to allow brand new peers (that do not have anything to contribute) to bootstrap.
+If a neighbor has a piece that the peer needs, the peer informs the neighbor with an '''interested''' message. However, the neighbor is not obliged to send the piece to the requesting peer immediately. A peer decides which of its interested neighbors it should send data to based on a so called '''choking/unchoking''' mechanism which executes every 10 seconds. When a neighbor is choked, the peer will refuse to send pieces to it. An '''unchoke''' message is sent to a small number of neighbors (default is 4) to inform them of the willingness of the peer to send the pieces that they are interested in. The decision of which neighbors to unchoke is based on a '''tit-for-tat policy''' in which the peer unchokes those neighbors which have given data to it at a high rate. This policy enables BT to deter free riding (i.e. selfish peers choosing only to download without contributing). In addition, a fifth neighbor is randomly unchoked every 30 seconds (i.e. every three cycles of the chocking/unchoking process), this is called '''optimistic unchoking'''. Optimistic unchoking is important in order to allow brand new peers (that do not have anything to contribute) to bootstrap.
-When a peer gets unchoked, it has to decide which of the pieces that are available at the unchoking neighbor (and that it does not currently have) to request. This decision is based on an interest array that the peer creates and maintains after receiving the bitfield messages of its neighbors. This contains the number of neighboring peers owning each of the pieces of the file and is updated whenever the peer receives a have message from one of its neighbors announcing the availability of a new piece that the neighbor has just downloaded. A peer uses a local rarest-first policy in which it requests the piece that is least replicated. This policy enables fast replication of rarest pieces and ensures that torrent file will not become extinct in case a peer having these pieces leaves.
+When a peer gets unchoked, it has to decide which of the pieces that are available at the unchoking neighbor (and that it does not currently have) to request. This decision is based on an '''interest array''' that the peer creates and maintains after receiving the bitfield messages of its neighbors. This contains the number of neighboring peers owning each of the pieces of the file and is updated whenever the peer receives a have message from one of its neighbors announcing the availability of a new piece that the neighbor has just downloaded. A peer uses a '''local rarest-first''' policy in which it requests the piece that is least replicated. This policy enables fast replication of rarest pieces and ensures that torrent file will not become extinct in case a peer having these pieces leaves.

@@ Line 86: / Line 86: @@
 * W. Li, S. Chen, and T. Yu, “UTAPS: An underlying topology-aware peer selection algorithm in BitTorrent,” in Proceedings of the 22nd International Conference on Advanced Information Networking and Applications (AINA 2008), March 2008, pp. 539–545.
 * J. Ledlie, P. Gardner, and M. I. Seltzer, “Network coordinates in the wild,” in Proceedings of the 4th USENIX Symposium on Networked Systems Design and Implementation, 2007, pp. 299–311.
-* M. Steiner and E. W. Biersack, “Where is my peer? evaluation of the vivaldi network coordinate system in azureus,” in Work in Progress Proceedings of the 8th International IFIP-TC6 Networking Conference (Networking 2009), Aachen, Germany, May 2009.
+* Y. Chen, Y. Xiong, X. Shi, B. Deng, and X. Li, "Pharos: A Decentralized and Hierarchical Network Coordinate System for Internet Distance Prediction," in Proceedings of the IEEE Global Telecommunications Conference, Nov. 2007, pp. 421-426.
 * S. L. Blond, A. Legout, and W. Dabbous, “Pushing BitTorrent locality to the limit,” INRIA, Tech. Rep. INRIA-00343822, Dec. 2008.

@@ Line 2: / Line 2: @@
 * ACM MM: April 17, 2009
 * ACM MM (short): May 8, 2009
 == Previous (2008) Simulation==