ChunkCast: An Anycast Service for Large Content Distribution - Revision history

Dzikowsk: /* Message formats in ChunkCast */

2007-07-19T15:23:28Z

Message formats in ChunkCast

← Older revision		Revision as of 15:23, 19 July 2007
Line 130:		Line 130:

	ChunkCast responds with the IP addresses of the peers, that posess any of the needed chunks. These peers passed the evaluation by two ranking functions. One of the functions optimizes the bit overlap, meaning that it compares the bit vector in the lookup message with the bit vectors from the publish messages for this paritcular object. The more bits correspond here, the better the ranking is. An information on how many relevant chunks a given peer holds is then included in the response message in the field ''overlap''.		ChunkCast responds with the IP addresses of the peers, that posess any of the needed chunks. These peers passed the evaluation by two ranking functions. One of the functions optimizes the bit overlap, meaning that it compares the bit vector in the lookup message with the bit vectors from the publish messages for this paritcular object. The more bits correspond here, the better the ranking is. An information on how many relevant chunks a given peer holds is then included in the response message in the field ''overlap''.

	The second function rates the distance between the peers. A feedback about this is encoded in the Network Coordinate field.		The second function rates the distance between the peers. A feedback about this is encoded in the Network Coordinate field.

Dzikowsk: /* Message formats in ChunkCast */

2007-07-19T15:22:04Z

Message formats in ChunkCast

← Older revision		Revision as of 15:22, 19 July 2007
Line 103:		Line 103:

	As for the implementation of the object level query, the concept of a bit vector is used. The bit vector as a whole represents the object, while each bit in this vector stands for a particular chunk of the object. In a publish message, the set bits in the vector represent the owned chunks. But the publish message itself has to bear more information than just the chunks the peer owns. It also contains an object identifier, which is the SHA-1 hash of the object name. The locality information is represented by so called Network coordinates, which provide a possibility to estimate the distance betwenn two peers without having to use pings. A third information, the publish message has to conain is of course the IP address of the publishing peer.		As for the implementation of the object level query, the concept of a bit vector is used. The bit vector as a whole represents the object, while each bit in this vector stands for a particular chunk of the object. In a publish message, the set bits in the vector represent the owned chunks. But the publish message itself has to bear more information than just the chunks the peer owns. It also contains an object identifier, which is the SHA-1 hash of the object name. The locality information is represented by so called Network coordinates, which provide a possibility to estimate the distance betwenn two peers without having to use pings. A third information, the publish message has to conain is of course the IP address of the publishing peer.

	The publish message format is shown in the figure below.		The publish message format is shown in the figure below.

Line 113:		Line 112:

	To search for data, a client peer has to issue a lookup message. The format of this message looks similar to the one of the publish message. It is shown in the following figure:		To search for data, a client peer has to issue a lookup message. The format of this message looks similar to the one of the publish message. It is shown in the following figure:


	{\|width="100%" border="0"		{\|width="100%" border="0"
Line 122:		Line 120:

	The start index, is used to allow a compact representaiton of the message. An object can potentially be partitioned into many chunks, resulting in a long bit vector. If an object consists of <math>n</math> chunks, and the peer does only need the last three chunks, the start index can be set to <math>n-3</math>, resulting in a bit vector of the length 3 (as opposed to <math>n</math>).		The start index, is used to allow a compact representaiton of the message. An object can potentially be partitioned into many chunks, resulting in a long bit vector. If an object consists of <math>n</math> chunks, and the peer does only need the last three chunks, the start index can be set to <math>n-3</math>, resulting in a bit vector of the length 3 (as opposed to <math>n</math>).

	The last field <math>p</math>, indicates the number of parallel connections, that the client peer can accept, determining an upper bound for the size of the response list.		The last field <math>p</math>, indicates the number of parallel connections, that the client peer can accept, determining an upper bound for the size of the response list.

	The last message format sketched here is the response message format. It is shown in the following figure:		The last message format sketched here is the response message format. It is shown in the following figure:


	{\|width="100%" border="0"		{\|width="100%" border="0"
Line 133:		Line 128:
	\|-		\|-
	\|}		\|}

			ChunkCast responds with the IP addresses of the peers, that posess any of the needed chunks. These peers passed the evaluation by two ranking functions. One of the functions optimizes the bit overlap, meaning that it compares the bit vector in the lookup message with the bit vectors from the publish messages for this paritcular object. The more bits correspond here, the better the ranking is. An information on how many relevant chunks a given peer holds is then included in the response message in the field ''overlap''.
			The second function rates the distance between the peers. A feedback about this is encoded in the Network Coordinate field.

	=References=		=References=

Dzikowsk: /* Problems of the existing approaches */ Corrected the inter-paragraph spacing

2007-07-19T10:30:18Z

Problems of the existing approaches: Corrected the inter-paragraph spacing

← Older revision		Revision as of 10:30, 19 July 2007
Line 31:		Line 31:

	Identifiing the main problems and bottlenecks of the existing implementations, is a second crucial step on the way to designing an improved CDN. The challenges are:		Identifiing the main problems and bottlenecks of the existing implementations, is a second crucial step on the way to designing an improved CDN. The challenges are:


	* The number of queries can be huge, so performance problems are going to be an issue		* The number of queries can be huge, so performance problems are going to be an issue
Line 42:		Line 41:
	* the structure ignores the effects of locality		* the structure ignores the effects of locality
	* because all queries are directed towards a central directory, and each query relates to only one chunk, the approach is not scalable		* because all queries are directed towards a central directory, and each query relates to only one chunk, the approach is not scalable


	The following secitons concentrate on these drawbacks. There will be suggestions on how to tackle them. These suggestions will be presented using the example of ChunkCast.		The following secitons concentrate on these drawbacks. There will be suggestions on how to tackle them. These suggestions will be presented using the example of ChunkCast.


	=Efficient queries=		=Efficient queries=

Dzikowsk: Fixed the table of contents (hierarchy)

2007-07-19T10:20:31Z

Fixed the table of contents (hierarchy)

← Older revision		Revision as of 10:20, 19 July 2007
Line 137:		Line 137:
	\|}		\|}

	==References==		=References=

	* [http://p2p.cs.berkeley.edu/chunkcast/chunkcast-iptps06.pdf B. Chun, P. Wu, H. Weatherspoon, J. Kubiatowicz: ChunkCast: An Anycast Service for Large Content Distribution]		* [http://p2p.cs.berkeley.edu/chunkcast/chunkcast-iptps06.pdf B. Chun, P. Wu, H. Weatherspoon, J. Kubiatowicz: ChunkCast: An Anycast Service for Large Content Distribution]

Dzikowsk: /* Message formats in ChunkCast */ Corrected a typo.

2007-07-19T10:13:01Z

Message formats in ChunkCast: Corrected a typo.

← Older revision		Revision as of 10:13, 19 July 2007
Line 115:		Line 115:
	\|}		\|}

	To search for data, a client peer has to issue a lookup message. The format of this message looks similar to the one of the publish message. It is ~~shwn~~ in the following figure:		To search for data, a client peer has to issue a lookup message. The format of this message looks similar to the one of the publish message. It is shown in the following figure:

Dzikowsk: /* Efficient queries */

2007-07-18T22:42:09Z

Efficient queries

← Older revision		Revision as of 22:42, 18 July 2007
Line 58:		Line 58:

	Up to now, the existing implementations of CDNs satisfy only a subset of the desired properties. Very roughly they can be organized into two groups:		Up to now, the existing implementations of CDNs satisfy only a subset of the desired properties. Very roughly they can be organized into two groups:


	* '''Downloading the chunks from a small set of peers''' A lookup query results in a small list of server peers, that own a particular chunk. The problem here is, that this approach potentially wastes bandwidth, if nearby server peers exist, that posses the requested chunk, but were not included in the list.		* '''Downloading the chunks from a small set of peers''' A lookup query results in a small list of server peers, that own a particular chunk. The problem here is, that this approach potentially wastes bandwidth, if nearby server peers exist, that posses the requested chunk, but were not included in the list.
Line 66:		Line 65:

	Obviously what is needed here is a solution that:		Obviously what is needed here is a solution that:


	* Integrates locality information to improve the results of lookup queries		* Integrates locality information to improve the results of lookup queries
Line 76:		Line 74:

	The lookup query used in ChunkCast--which will be described next--has these properties, because it results in a list of server peers that satisfy the following conditions:		The lookup query used in ChunkCast--which will be described next--has these properties, because it results in a list of server peers that satisfy the following conditions:


	* they are the closest possible peers		* they are the closest possible peers

Dzikowsk: /* ChunkCast */

2007-07-18T22:41:38Z

ChunkCast

← Older revision		Revision as of 22:41, 18 July 2007
Line 86:		Line 86:

	The general idea is, that peers, in a peer-to-peer network use the ChunkCast service for two purposes:		The general idea is, that peers, in a peer-to-peer network use the ChunkCast service for two purposes:


	* The chunk lookup		* The chunk lookup

Dzikowsk at 22:40, 18 July 2007

2007-07-18T22:40:52Z

Show changes

Dzikowsk at 17:55, 9 July 2007

2007-07-09T17:55:38Z

← Older revision		Revision as of 17:55, 9 July 2007
Line 1:		Line 1:
			(This article is a stub. Details will be added soon.)

	==References==		==References==

Dzikowsk at 17:21, 9 July 2007

2007-07-09T17:21:59Z

← Older revision		Revision as of 17:21, 9 July 2007
Line 1:		Line 1:
	==References==		==References==

	[http://p2p.cs.berkeley.edu/chunkcast/chunkcast-iptps06.pdf B. Chun, P. Wu, H. Weatherspoon, J. Kubiatowicz: ChunkCast: An Anycast Service for Large Content Distribution]		* [http://p2p.cs.berkeley.edu/chunkcast/chunkcast-iptps06.pdf B. Chun, P. Wu, H. Weatherspoon, J. Kubiatowicz: ChunkCast: An Anycast Service for Large Content Distribution]