[Spread-users] Monitor on Win32?

Jonathan Stanton jonathan at cnds.jhu.edu
Wed Dec 12 16:03:55 EST 2001


Out of curiousity, could you tell me what NDDS, HLA and DIS are? I'm
somewhat familiar with Rendezvous, but havn't heard of those.

On Wed, Dec 12, 2001 at 11:38:48AM -0700, Mike Stagnaro wrote:
> I'm new to Spread and this list.  Currently using Rendezvous extensively
on one project, and planning to assess (again) NDDS....also have a very
primitive knowledge of HLA & DIS.  Spread looks very interesting as a
potential alternative to other messaging frameworks (no central servers,
reliable multicast, etc.) that I've used for distributed/replicated object
collaberation...so I've been taking a look....
> On to my question....
> Does the monitor work on Win32 (NT/2K)?  I've been able to build it from
3.6.1 source -- had to insert a call to "WSAStartup()" within an ifdef
block.  When I try to run locally, it appears to free run within
"E_handle_events()" -- nothing appears to block when I step through it, and
"User_command()" never appears to be called.  When running without breaks,
it saturates the processor.

The monitor does not work on windows. The problem is that the way we
handle user input at the console, stdin bound to a file descriptor, with
output to standard out does not work on windows. The sptuser client works
because we wrote a threaded version, but we never wrote a windows version
of the monitor. The spuser (non-threaded version of sptuser) also doesn't
work on windows for the same reason. 

> I'm running on Win2K, SP2 using Visual Studio 6, SP 5.  I have built and
run the spread daemon successfully.  The binary versions (3.6 distribution)
of spflooder and sptuser also seem to work as expected with default
arguments (have not tried to build these yet from 3.6.1, but seems very
do-able now).

We will be releasing binary distribution later today of 3.16.1 with new
windows binaries. But the source is not too difficult to build in Visual
Studio. The only tricks I remember is making sure to add ARCH_PC_WIN95 to
the defines and make sure wsock32 library is included in the build of the
daemon and clients. 

> Another side question....
> I don't see any calls to "WSACleanup()" in the source distribution.  
Does this lead to any strange behaviour on Win32 platforms, or does socket
closure and/or process death do enough to release resources from Winsock (I
usually call it to insure the ref counter stays consistent)?

I'm not sure. We do not know of any leaks specific to windows that would be
caused by this, and the model of closing sockets should clean them up is
pretty standard, but it is possible that there are some bugs in the windows
specific code and we know of several improvements that could help the
windows version.


Jonathan R. Stanton         jonathan at cs.jhu.edu
Dept. of Computer Science   
Johns Hopkins University    

More information about the Spread-users mailing list