| An Introduction to Data Servers |
Now, let's look at the steps in the
conversation between the server and the client.
The server runs two loops.
In the outer loop, the following is taken care of:
The measurement system is
initialized. In the GPIB system that means you reset the instruments.
That is handled in the sub-vi discussed above. There is a TCP/IP
listener. That listener waits for a message from a remote computer
indicating that the remote computer wants data. In essence, the program
is "hung" until that request arrives, and the second loop doesn't start
operating until a request message arrives. What actually happens is
that the outer loop keeps running (as quickly as possible) checking to
see if a request has arrived. When a request arrives:
The request from the
client must be directed to the correct IP address of the server (the
"phone number") and the correct port (the "extension at that phone
number"). The request must
contain the IP address of the client so that the server can send the
data to the correct IP address.
When a request has been
received and a connection established, then - and only then - does the inner
loop begin to operate. To service the request, the
server must take a measurement - in the inner loop - and send the results.
The inner loop operates repeatedly at a specified time interval.
Since measurement string
length might be variable, the first thing that the server has to do is
examine the string length and transmit a value for the string length.
If the string could be 9, 10, 11 or 12 characters long, it would be wise
to send two bytes for the string length, i.e. "09", "10", "11", etc.
In the diagram above,
after doing the string length computation - which results in an
integer number (the blue line) - the number is converted to a
string, and the string is padded (with a space, if necessary) to a
length of two. If the actual data
string had 100 or more characters, then this would cause an error at
the client because the conversion to an integer would expand to
whatever length necessary, and the client would be expecting only
two characters and would assume that the extra character was part of
the data string - sent after the length is sent.
After sending the string
length - so that the client knows how much data to expect - the server
needs to send the data string.
The data manipulation for the
above implies that the following happens in the server.
The measurement yields a
string. The length of the
measurement string is computed - as a number. The length of the
measurement string is changed to a string, padded as necessary, and sent
as a two byte string to the client so that the client knows how much
data to expect. The measurement string is
sent by the server.
The data manipulation for the
above implies that the following happens in the client.
The client - after
initiating a "conversation" waits to receive two bytes (using a TCP/IP
Read) that will tell the client how long the data string will be. The client gets a
two-byte string and converts that to an integer. The integer is used to
set a TCP/IP Read that will receive the number of bytes specified as a
string. The data string received
is converted to whatever format is appropriate. For example, it might
be converted to a numerical format to display on a thermometer gage.
The Data Client
In the section above we
considered what the data client would have to do. The next question is how that
might be implemented in LabVIEW. The diagram below is a very simple client for
the temperature data server.
Here is what happens in the data
client.
In the first TCP block a
connection is opened.
Once the connection is open,
inside the loop a TCIP Read block waits for data.
The data received - the
number of bytes in the data string - is converted to an integer and forms an
input to the next TCIP Read block. That particular input is the number of
bytes that the second TCIP Read block should wait for in the data string.
|
