Private:pCDN:Systems Issues - Revision history

Mhefeeda at 00:13, 8 August 2008

2008-08-08T00:13:20Z

Mhefeeda at 00:12, 8 August 2008

2008-08-08T00:12:45Z

Mhefeeda at 00:12, 8 August 2008

2008-08-08T00:12:19Z

Mhefeeda at 22:26, 30 March 2008

2008-03-30T22:26:10Z

MediaWiki default: Private:pCDN:System Issue moved to Private:pCDN:Systems Issues

2008-03-26T21:06:52Z

Private:pCDN:System Issue moved to Private:pCDN:Systems Issues

MediaWiki default at 20:49, 26 March 2008

2008-03-26T20:49:05Z

MediaWiki default at 20:44, 26 March 2008

2008-03-26T20:44:20Z

MediaWiki default at 20:43, 26 March 2008

2008-03-26T20:43:39Z

MediaWiki default at 20:41, 26 March 2008

2008-03-26T20:41:17Z

MediaWiki default at 20:36, 26 March 2008

2008-03-26T20:36:10Z

← Older revision		Revision as of 00:13, 8 August 2008
Line 34:		Line 34:
	=== Geo Fencing ===		=== Geo Fencing ===

−	* Details are given in [pCDN:Geo-Fencing\|this page.]	+	* Details are given in [[pCDN:Geo-Fencing\|this page.]]

← Older revision		Revision as of 00:12, 8 August 2008
Line 34:		Line 34:
	=== Geo Fencing ===		=== Geo Fencing ===

−	* Details are given in [pCDN:Geo-Fencing this page.]	+	* Details are given in [pCDN:Geo-Fencing\|this page.]

← Older revision		Revision as of 00:12, 8 August 2008
Line 31:		Line 31:

	State maintenance		State maintenance
		+
		+	=== Geo Fencing ===
		+
		+	* Details are given in [pCDN:Geo-Fencing this page.]

← Older revision		Revision as of 22:26, 30 March 2008
Line 19:		Line 19:

	=== NAT Traversal ===		=== NAT Traversal ===
		+
		+	=== Client Design ===
		+
		+	Transparency, portability, Buffering, disk access,
		+
		+	=== Server Design ===
		+
		+	Architecture
		+
		+	Threading and scalability
		+
		+	State maintenance

@@ Line 14: / Line 14: @@
 ** '''Alternative #1''': We distinguish clients behind and not behind NATs. We set the heartbeat interval <math>t_s</math> to be 30 mins, and maximal retries to be 3 times for clients that are not behind NATs. We use an adaptive heartbeat interval for clients behind NATs. This heartbeat interval <math>t_s</math> is initialized to be 2 mins, and is reduced by 5 secs whenever the server notices an IP/port change. <math>t_s</math> should never go below 5 secs.
 ** '''Alternative #2''': We create two types of heartbeat messages: for maintaining client states at the server and  for maintaining UDP states at the NAT box. We call the these two types of heartbeat messages as: type-S and type-N heartbeat messages, respectively. The type-S heartbeat messages are sent at very low frequency: at 30 mins interval with 3 retries. Unlike Alternative #1, even clients behind NAT send type-S heartbeats at this low rate. Both the server and the client send type-S heartbeat messages. The type-N heartbeat messages are sent only by clients at very high frequency: potentially one per second. This is to refresh the port mapping on NAT boxes. To avoid the message flooding, the type-N heartbeats should have a small ''TTL'' value, say <math>n</math>. Choosing proper <math>n</math> value is not easy, considering there might be several chained NAT boxes between clients and the server. A feasible <math>n</math> value should fall between the hop count to the ''outer-most'' NAT box and the hop count to the server. An optimal  <math>n</math> should be as close to the hop count to the ''outer-most'' NAT box as possible. We set <math> n = 3 </math> as the initial TTL value. We increase <math>n</math> by 1 if the server observes an IP/port change, which indicates our port mapping still gets timed out because the type-N heartbeats did not go far enough. We decrease <math>n</math> by 1 if the server receives a type-N heartbeat, which indicates type-N heartbeats are flooding our server. We set <math>n=0</math> if we observe the <math>n</math> value fluctuates for 3 times. Clients with a zero <math>n</math> do not send type-N heartbeats.
 === Streaming Friendly Scheduling ===
 === NAT Traversal ===

← Older revision	Revision as of 21:06, 26 March 2008
(No difference)

@@ Line 13: / Line 13: @@
 * '''Adaptive HeartBeat Interval''': There are two alternatives to make heartbeat interval adaptive to NAT box implementation.
 ** '''Alternative #1''': We distinguish clients behind and not behind NATs. We set the heartbeat interval <math>t_s</math> to be 30 mins, and maximal retries to be 3 times for clients that are not behind NATs. We use an adaptive heartbeat interval for clients behind NATs. This heartbeat interval <math>t_s</math> is initialized to be 2 mins, and is reduced by 5 secs whenever the server notices an IP/port change. <math>t_s</math> should never go below 5 secs.
-** '''Alternative #2''': We create two types of heartbeat messages: for maintaining client states at the server and  for maintaining UDP states at the NAT box. We call the these two types of heartbeat messages as: type-S and type-N heartbeat messages, respectively. The type-S heartbeat messages are sent at very low frequency: at 30 mins interval with 3 retries. Unlike Alternative #1, even clients behind NAT send type-S heartbeat at this low rate. Both the server and clients send type-S heartbeat messages. The type-N heartbeat messages are sent only be clients at very high frequency: potentially once every second. This is to refresh the port mapping on NAT boxes. To avoid the message flooding, the type-N heartbeats should have a small ''TTL'' value, say <math>n</math>. Choose proper <math>n</math> value is not easy, considering there might be several chained NAT boxes between clients and the server. A feasible <math>n</math> value should fall between the hop count to the ''outer-most'' NAT box and the hop count to the server. An optimal  <math>n</math> should be as close to the hop count to the ''outer-most'' NAT box as possible. We set <math> n = 3 </math> as the initial TTL value. We increase <math>n</math> by 1 if the server observes an IP/port change, which indicates our port mapping still gets timed out because the type-N heartbeats did not go far enough. We decrease <math>n</math> by 1 if the server receives a type-N heartbeat, which indicates type-N heartbeats are flooding our server. We set <math>n=0</math> if we observe the <math>n</math> fluctuates for 3 times. Clients with a zero <math>n</math> do not send type-N heartbeats.
+** '''Alternative #2''': We create two types of heartbeat messages: for maintaining client states at the server and  for maintaining UDP states at the NAT box. We call the these two types of heartbeat messages as: type-S and type-N heartbeat messages, respectively. The type-S heartbeat messages are sent at very low frequency: at 30 mins interval with 3 retries. Unlike Alternative #1, even clients behind NAT send type-S heartbeats at this low rate. Both the server and the client send type-S heartbeat messages. The type-N heartbeat messages are sent only by clients at very high frequency: potentially one per second. This is to refresh the port mapping on NAT boxes. To avoid the message flooding, the type-N heartbeats should have a small ''TTL'' value, say <math>n</math>. Choosing proper <math>n</math> value is not easy, considering there might be several chained NAT boxes between clients and the server. A feasible <math>n</math> value should fall between the hop count to the ''outer-most'' NAT box and the hop count to the server. An optimal  <math>n</math> should be as close to the hop count to the ''outer-most'' NAT box as possible. We set <math> n = 3 </math> as the initial TTL value. We increase <math>n</math> by 1 if the server observes an IP/port change, which indicates our port mapping still gets timed out because the type-N heartbeats did not go far enough. We decrease <math>n</math> by 1 if the server receives a type-N heartbeat, which indicates type-N heartbeats are flooding our server. We set <math>n=0</math> if we observe the <math>n</math> fluctuates for 3 times. Clients with a zero <math>n</math> do not send type-N heartbeats.
 === Streaming Friendly Scheduling ===
 === NAT Traversal ===

@@ Line 10: / Line 10: @@
 To better resolve this, we propose two mechanisms: permanent Id and adaptive heartbeat interval.
-* '''Permanent Id''': Clients should maintain a unique and permanent Id. We achieve the uniqueness using the MD5 hash. We store the Id in the client's configuration file for permanency. We should note that the configuration file of a fresh installed client should contain no Id. This can be implemented by reserving an Id as the ''Initial Id'', such as all 0xFF. When a client starts up, it loads its Id from the configuration file. The client generates a new Id if its configuration file contains the ''Initial Id''. The new Id is created by hashing the first MAC address of that client machine. If this failed, we hash a random number and use it as the new Id. All messages from clients to the server should contain client's Id, which enables the server to determine whether there is an IP/port change. If the server notices an IP/port change, it performs two taks. First, the server should send a JoinAck message to the client, so that the client can update it's public IP address and port number. Second, the server updates its connection and content tables.
+* '''Permanent Id''': Clients should maintain a unique and permanent Id. We achieve the uniqueness using the MD5 hash. We store the Id in the client's configuration file for permanency. We should note that the configuration file of a fresh installed client should contain no Id. This can be implemented by reserving an Id as the ''Initial Id'', such as all 0xFF. When a client starts up, it loads its Id from the configuration file. The client generates a new Id if its configuration file contains the ''Initial Id''. The new Id is created by hashing the first MAC address of that client machine. If this fails, we hash a random number and use it as the new Id. All messages from clients to the server should contain client's Id, which enables the server to determine whether there is an IP/port change. If the server notices an IP/port change, it performs two taks. First, the server should send a JoinAck message to the client, so that the client can update it's public IP address and port number. Second, the server updates its connection and content tables.
 * '''Adaptive HeartBeat Interval''': There are two alternatives to make heartbeat interval adaptive to NAT box implementation.
-** '''Alternative #1''': We distinguish clients behind and not behind NATs. We set the heartbeat interval <math>t_s</math> to be 30 mins, and maximal retries to be 3 times for clients that are not behind NATs. We use an adaptive heartbeat interval for clients behind NATs. This heartbeat interval <math>t_s</math> is initialized to be 2 mins, and is reduced by 5 secs whenever the server notices an IP/port change. <math>t_s</math> should never go below 5 secs, that is <math>t_s \ge 5 </math>.
+** '''Alternative #1''': We distinguish clients behind and not behind NATs. We set the heartbeat interval <math>t_s</math> to be 30 mins, and maximal retries to be 3 times for clients that are not behind NATs. We use an adaptive heartbeat interval for clients behind NATs. This heartbeat interval <math>t_s</math> is initialized to be 2 mins, and is reduced by 5 secs whenever the server notices an IP/port change. <math>t_s</math> should never go below 5 secs.
 ** '''Alternative #2''': We create two types of heartbeat messages: for maintaining client states at the server and  for maintaining UDP states at the NAT box. We call the these two types of heartbeat messages as: type-S and type-N heartbeat messages, respectively. The type-S heartbeat messages are sent at very low frequency: at 30 mins interval with 3 retries. Unlike Alternative #1, even clients behind NAT send type-S heartbeat at this low rate. Both the server and clients send type-S heartbeat messages. The type-N heartbeat messages are sent only be clients at very high frequency: potentially once every second. This is to refresh the port mapping on NAT boxes. To avoid the message flooding, the type-N heartbeats should have a small ''TTL'' value, say <math>n</math>. Choose proper <math>n</math> value is not easy, considering there might be several chained NAT boxes between clients and the server. A feasible <math>n</math> value should fall between the hop count to the ''outer-most'' NAT box and the hop count to the server. An optimal  <math>n</math> should be as close to the hop count to the ''outer-most'' NAT box as possible. We set <math> n = 3 </math> as the initial TTL value. We increase <math>n</math> by 1 if the server observes an IP/port change, which indicates our port mapping still gets timed out because the type-N heartbeats did not go far enough. We decrease <math>n</math> by 1 if the server receives a type-N heartbeat, which indicates type-N heartbeats are flooding our server. We set <math>n=0</math> if we observe the <math>n</math> fluctuates for 3 times. Clients with a zero <math>n</math> do not send type-N heartbeats.