Purpose:
Use port hunting to test the Stream VFD
Description:
The stream driver is tested by streaming data
between two different processes on the local
machine on a given default port.
If this port is already is use, port hunting
should find the next available port to use.
The hostname/port information which is actually
used by the sender is written to a temporary
file which is then read by the receiver process
to connect to the sender's port.
For the purpose of testing I switched back
the default port to use from 10007 to 5678
which is at least already used by another
service on modi4.
Platforms tested:
x86 Linux, Irix 32/64 bit (modi4), Dec Alpha,
Unicos on T3E, Hitachi SR8000, AIX on SP2
Update
Description:
Changed includes of the form:
#include <hdf5_file.h>
to
#include "hdf5_file.h"
so that gcc can pick them up easier without including the system
header files since we don't care about them.
Platforms tested:
Linux
"Bug fix"
Description:
It could not create the stream file in modi4 because port 5678 is used by
a recently installed application in modi4. But the reading side just
waited there and the two test processes have to be killed by hand.
Solution:
Changed to use port 10007 instead, hoping less chance of conflict
with other applications. Just a short-term solution.
Platforms tested:
modi4.
Code cleanup.
Description:
Fixed _lots_ (I mean _tons_) of warnings spit out by the gcc with the
extra warnings. Including a few show-stoppers for compression on IRIX
machines.
Solution:
Changed lots of variables' types to more sensible and consistent types,
more range-checking, more variable typecasts, etc.
Platforms tested:
FreeBSD 4.2 (hawkwind), IRIX64-64 (modi4)
Purpose:
Bugfix
Description:
Undo my last bugfix
Solution:
Although changing 'return()' into '_exit()' for forked processes
fixed core dumping of stream_test under Linux SMP it wasn't really
a bugfix. In fact it still crashed on a T3E.
Now it turned out that the bug was in some cleanup routine in H5FD.c.
Since this has been fixed by Robb I can undo my (unneccessary) changes.
Platforms tested:
Linux SMP (eirene)
IRIX64 (modi4), IRIX32 (origin)
T3E
Purpose:
Bugfix
Description:
The stream_test program reported an error under Linux SMP
for testing the Stream VFD although everything seemed to be fine.
Solution:
The sender and receiver process which are forked by main()
called return(retcode) at exit which implies closing open file descriptors.
Since these are shared this caused a SEGFAULT in either the sender
or the receiver when exiting.
Replacing return() by _exit() is the right way to terminate the forked
processes in this case.
Platforms tested:
Linux SMP (eirene)
Purpose:
Port to Windows.
Description:
The stream_test program now also compiles and can be run under Windows.
Solution:
The problem was that fork(2) and waitpid(2) aren't available
under Windows when using the MS compilers.
So I test for both H5_HAVE_FORK and H5_HAVE_WAITPID.
These are already checked fortunately during configuration.
If they are not there the code just says
printf ("Test skipped because this architecture doesn't provide "
"fork(2) and waitpid(2)\n");
Platforms tested:
Windows NT, both with MS Visual C++ and GNU cc
Now you can build and run the Stream VFD testsuite under Windows
when using GNU cc !!
Added test program to verify the Stream Virtual File Driver.
Description:
This program tests the functionality of the Stream Virtual File Driver.
1. It spawns two new processes, a sender and a receiver.
2. The sender opens an HDF5 file for writing and writes
a sample dataset to it.
On closing the file the Stream VFD would send the file
contents to any connected client.
3. The receiver serves as a client attempting to open an
HDF5 file for reading. On opening the file the Stream VFD
would establish a socket connection to the sender process,
identified by its hostname (which is localhost in this example)
and a port number, and read the file contents via this socket.
Aftwerwards the dataset is read from the file into memory
and verified.
4. The main program waits for termination of its two child
processes and returns their exit code.
Platforms:
Tested so far under Linux, Irix 32/64bit, OSF1, Solaris, Cray Unicos,
Hitachi SR8000, IBM AIX.
Not tested under Windows yet.
