AnsweredAssumed Answered

Sockets again.

Question asked by VRFuser on Mar 9, 1997
To:   VRf - Vee Reflector
From: Andy Fuller
Date: 10 March 1997

I think I'm starting to understand your problem:  You have a monitoring
task to perform, along with other functions, and have a concern about
I/O blocking in your VEE based application.

I also have found that the multiprocessing capabilities of VEE are
limited.  For simple applications, the parallel thread capability is
convienient, but it does not provide true multiprocessing.

I have recently completed working on a test, telemetry and control
system that uses VEE and C programs to collect and collate telemetry,
automate test functions, and aid the test operator in analyzing the
collected data.  We use sockets to communicate between processes on the
HP-UX workstation as well as programs running on other computers.  We
found that we could not tolerate I/O blocking and other I/O problems
within our automatic test software, so we implemented a telemetry
collection process (in C) to do it for us.

The implementation looks like this:
---------------             -------------               -------------
|             |             |           |               |           |
|             |             | Telemetry |  (socket)     | System    |
|             | (ethernet)  |           |============== |           |
| Instruments |============ | Collection|  LD Vector   >| Monitor   |
|             | Telemetry  >|           |============== |           |
|             |============ |           |               | Display   |
|             |             |           |               |           |
---------------             -------------               -------------
          ^                        | |                  
         | |                       | |(socket)          
         | |                       | |LD Vector         
         | |                        v                                     
         | |                 -------------                               
         | |  (ethernet)     |           |                               
         | ==================| Automatic |                               
         | Inst. Commands    |           |                              
         ====================| Test      |                              
                             |           |                             
                             | Applications                                  
                             |           |                                   

The LD Vector is a fixed size array that completely describes the state
of the system, all instruments attached, and the unit we are testing.
The socket interfaces to the Telemetry Collection process are
well-behaved and guaranteed not to block, that is, the LD Vector is
ALWAYS ready to be read.  The Telemetry Collection process is written in
C, and is responsible for handling all of the I/O problems with the LAN
based instruments.  The System Monitor Display process is written in
VEE, and all of the Automatic Test Applications are written in VEE.                                                            

The Telemetry Collection process handles all of the high-speed I/O
functions, I/O errors, and other problems associated with inter-computer
communication.  It uses many of the multi-tasking and multiple socket
I/O capabilities available in Unix, and provides a stable interface to
other processes that cannot tolerate messy interfaces.

This leaves our Automatic Test Applications free to perform tests
without I/O blocking concerns.  Any system information needed as part of
the test can be obtained upon request from the Telemetry Collection
process via a socket call.  This socket call always retrieves a
fixed-length fixed-format binary message, which is handled very easily
by VEE.

Similarly, the System Monitor Display function is able to obtain
fixed-length fixed-format binary data from the Telemetry Collection
process, and use all of the fancy display features of VEE to present the
data to the user in a visually useful form.

This implementation is not without it's problems, particularly that we
must manage a whole collection of Unix processes.  However, it does work
well, and it gets the job done.

Where we run into the biggest problem is that when a socket connection
is broken, instead of being shut down in an orderly way, we must wait 60
seconds before attempting to re-connect.  Unix waits 60 seconds for
TCP/IP connections to time-out before releasing the TCP port for a new
connection.  Another problem with our implementation is that we must
start our software in a specific order.  If one part of it crashes, the
other parts must be shut down and everything re-started.  This problem
could be eliminated with some re-work, but it hasn't proved to be worth
the effort.

Finally, we use VEE programs to help the user analyzed the collected
data.  We collect enormous amounts of data (as much as 10^9 bytes/day)
and must be able to visualize it and analyze it.  A VEE program directly
reading our data store is much too slow, so we use a C program to locate
the desired data and provide it (again in fixed-length, fixed-format
binary messages) to the VEE analysis program.  This lets us use the
flexibility and speed of a C program and the easy data handling and
display functions of VEE together.  These two processes communicate
using a Unix Named Pipe.  Again, we could improve the inter-process
communications with some more work, but it hasn't proved to be worth the

I hope that this gives you some ideas.

-- Andy

Andrew C. Fuller          |
Raytheon E-Systems, Inc.  | Box 12248 | St. Petersburg, FL 33733
(813)381-2000 x3194       | Fax:(813)381-3329