NDT-DEV email list created

Revision: 475
Author:   

Date:     Tue Aug  9 03:04:02 2011
Log:      Feedback based fixes in the first 5 sections
http://code.google.com/p/ndt/source/detail?r=475

Modified:
 /wiki/NDTProtocol.wiki

=======================================
--- /wiki/NDTProtocol.wiki      Mon Aug  8 06:30:49 2011
+++ /wiki/NDTProtocol.wiki      Tue Aug  9 03:04:02 2011
@@ -56,7 +56,7 @@

 As described above, the NDTP consists of a two inter-related sets of  
protocols: NDTP-Control and NDTP-Tests. Both of them are layered over TCP.  
The former is used to initiate and control the test sessions and to fetch  
their results. The latter set of protocols is used to perform the specific  
tests.

-The initiator of the test session establishes a TCP connection to a  
well-known port, 3001, on the target point and this connection remains open  
for the duration of the NDTP-Tests sessions. The NDT server SHOULD listen  
to this well-known port, but it MAY also choose to listen on a different  
port, because both the Client and the Server SHOULD be configurable to  
allow this.
+The initiator of the test session establishes a TCP connection to a  
well-known port, 3001, on the target point and this connection remains open  
for the duration of the NDTP-Tests sessions. The NDT server SHOULD listen  
to this well-known port.

 The NDTP-Control messages are transmitted before the NDTP-Tests sessions  
are actually started, after they are completed and between particular tests  
from the performed test suite. Moreover, a specific tests also use the  
NDTP-Control messages to synchronise the test sessions, exchange a  
configuration data and additional information.

@@ -66,7 +66,7 @@

 The type of each NDTP-Control message can be found after reading the first  
octet. The length of each NDTP-Control message can be computed upon reading  
its fixed-size part. No message is shorter than 3 octets.

-An implementation SHOULD expunge unused state to prevent denial-of-service  
attacks, or unbounded memory usage, on the server.  For example, if the  
full control message is not received within some number of seconds after it  
is expected, the TCP connection associated with the NDTP-Control session  
SHOULD be dropped. The NDTP does not define any timeout limit.
+An implementation SHOULD expunge unused state to prevent denial-of-service  
attacks, or unbounded memory usage, on the server.  For example, if the  
full control message is not received within some number of seconds after it  
is expected, the TCP connection associated with the NDTP-Control session  
SHOULD be dropped. A value of no more than 60 seconds is RECOMMENDED.

 === Message structure ===

@@ -79,7 +79,7 @@
 The NDTP-Control currently defines the following types of messages:

 || *Symbolic name* || *Bit value* || *Description* ||
-|| COMM_FAILURE || 0 || Notification about communication link failure.  
*Not used explicitly* ||
+|| COMM_FAILURE || 0 || Notification about communication link failure. ||
 || SRV_QUEUE || 1 || Message used to the Clients' queue management ||
 || MSG_LOGIN || 2 || Used during initialization to negotiate the NDT  
version and the test suite ||
 || TEST_PREPARE || 3 || Used to send all information needed for a  
particular test (i.e. port numbers, test time, etc.) ||
@@ -103,11 +103,11 @@

 Where TESTS is a bitwise OR of the tests' ids that should be run in a  
requested test-suite. The Tests' ids are defined in the  
[NDTProtocol#NDTP-Tests NDTP-Tests] section.

-All new Clients MUST always request the TEST_STATUS (16 (1L << 4)) test in  
order to notify the Server that they support the MSG_WAITING messages  
introduced in the NDT v3.5.5.
+All Clients MUST always request the TEST_STATUS (16 (1L << 4)) test in  
order to notify the Server that they support the MSG_WAITING messages  
introduced in the NDT v3.5.5.

 ==== Kick off message to disconnect old clients ====

-In the same time the Server sends the specially crafted 13 octets long  
data that kicks off the old Clients ("123456 654321"):
+In the same time the Server sends the specially crafted 13 octets long  
data that kicks off the old Clients ("123456 654321" - the old Clients  
tried to treat these string encoded numbers as the port numbers and failed  
to do this):

  
http://www.soldevelo.com/images/ndt/5.%2013%20octets%20long%20data%20that%20kicks%20off%20the%20old%20Clients%20%28%22123456%20654321%22%29.png

@@ -115,20 +115,21 @@

 ==== Queuing clients ====

-The NDT Server MUST respond with a one or more SRV_QUEUE messages to  
inform the Client whether or not it needs to wait, or can start performing  
tests. These messages MUST contain one of the following string values:
+Next, the NDT Server MUST send a one or more SRV_QUEUE messages to inform  
the Client whether or not it needs to wait, or can start performing tests.  
These messages MUST contain one of the following string values:

 || *SRV_QUEUE value* || *Description* ||
 || "0" || The test session will start now ||
-|| "9977" || Server Fault: test session will be terminated for unknown  
reason. Client MUST drop the connection after receiving this message. *Not  
used currently by the Server* ||
+|| "9977" || Server Fault: test session will be terminated for unknown  
reason. Client MUST drop the connection after receiving this message. ||
 || "9988" || If this is a first message from the Server, then it means  
that the Server is busy. In other cases it means the Server Fault. the  
Client MUST drop the connection after receiving this message. ||
-|| "9999" || Server Busy: Please wait 60 seconds for the current test to  
finish. The Client MUST drop the connection after receiving this message.  
*Deprecated/Not used by the Server* ||
-|| "9990" || This is a check from the Server to verify if the Client is  
alive. Available from v3.5.5. The Client MUST respond to this message by  
sending an empty 'MSG_WAITING' message. The Server will only send these  
messages when the Client requested TEST_STATUS test. ||
+|| "9990" || This is a check from the Server to verify if the queued  
Client is alive. Available from v3.5.5. The Client MUST respond to this  
message by sending an empty 'MSG_WAITING' message. The Server will only  
send these messages to the queued Clients that requested TEST_STATUS test. | 
|
 || "N" || Where N is any other value. It means the estimated number of  
minutes that the Client will wait for its test to begin. ||

 When the NDT Server decides that the Client can start its test session, it  
sends the SRV_QUEUE message with value *'0'*:

  
http://www.soldevelo.com/images/ndt/6.%20sends%20SRV_QUEUE%20message%20with%20value%20%270%27.png

+The SRV_QUEUE messages are only sent to the queued Clients.
+
 ==== Verifying version compatibility ====

 At the beginning of the test session the Server and the Client MUST verify  
their version compatibility.
@@ -143,7 +144,7 @@

 ==== Negotiating test suite ====

-In the next step the NDT Server MUST send a MSG_LOGIN message containing a  
list of tests' ids, encoded as ascii string, that will be performed:
+In the next step the NDT Server MUST send a MSG_LOGIN message containing a  
list of tests' ids, encoded as ascii string, that will be performed. This  
list of tests's ids MUST NOT contain any tests that were not requested by  
the Client in the first MSG_LOGIN message. The Server's MSG_LOGIN message  
looks as following:

  
http://www.soldevelo.com/images/ndt/8.%20encoded%20as%20ascii%20string,%20that%20will%20be%20performed.png