[Spread-users] Monitor on Win32?

[Mike Stagnaro]

Hi Jonathan,

Your questions first....

NDDS stands for Network Data Delivery System, produced by Real-Time
Innovations (www.rti.com).  It's similar to Rendezvous, but includes
features that are very useful in real-time (deterministic) systems.  Used to
be based entirely on UDP unicast, so could be very chatty on the wire in
one-to-many situations.  Version 3 can make use of reliable multicast, and
pricing models are generally better than Rendezvous....so I'm taking another
look in the context of a specific project.

DIS is Distributed Interactive Simulation.  This was a spec and
implementations for coordinating and driving widely distributed federations
of interacting applications, driven primarily by the DoD for interactive
sims and gaming.  HLA stands for High Level Architecture, a follow-on spec.
HLA is a spec only and does not imply specific implementations.  The spec
does call for a Run Time Infrastructure (RTI), which takes care of what DIS
used to do and more.  An RTI includes messaging along with other services
for federates, like time sync.  The DoD still sponsors this via DMSO at
(http://www.dmso.mil/index.php?page=64).

One supporting vendor is Mak at (www.mak.com).... they have an RTI
implementation that implies multicast messaging with no centalized servers.
I have not had a chance to take a first hand look yet.

Another company who started in the HLA world, but has moved more mainstream
is Perceptronics.  They've even changed their name to accelerate the whole
process (I guess...).  Their history and vision seems interesting.  Nothing
to see yet, but I plan to watch for a while at
(http://ic3d.perceptronics.com/index.html).

Another interesting vendor is Quazal at (www.quazal.com).  They target the
massive multiplayer gaming market with a protocol that supports distributed,
replicated objects.  It has parallels to HLA (and some history there), but
actual IP multicast is not used from what I've seen and heard.  Instead, a
hierarchical distribution occurs.  Entry pricing is steep for Net-Z, but it
is an interesting approach and offering.



Follow-on questions from me.....

Do you have any plans to port monitor to Win32?  If not, how difficult would
this be?  Could it be something like spawning a dedicated UI thread with
some form of mutex protected globals?  Monitor (or something like it) seems
like a critical tool to system tuning and admin.  I primarily target systems
based on NT (4, 5, 5.1), so I'd be interesting in having a monitor.  Might
consider building my own (in copius spare time), but I don't know its
internals (and how it communicates to the daemons) well enough to know if
this is even something I could/should do.  Any thoughts or plans?

Also, can you elaborate on the daemon limits in a system.  I've read a few
things about 128 as a limit within a broadcast segement (ring?)...and a
limit of 128 total among all segments.  I'm reading this to mean that the
total number of nodes in spread.conf can be no greater than 128 in a
multi-segment config.....or a single segment config can have no more than
128 nodes.  True?  If so, why?  Is this a limitation imposed by the ring
and/or hop protocol?  Any insight appreciated.

Last one for now...
Is there a practical (or hardwired) limit on the number of groups an
application can join?  Let's say that the app lives on the same box as the
daemon.  With Rendezvous, we have apps with multiple thousands of subject
subscriptions running with no problem....just curious how Spread compares
from what you've seen.

Thanks!
--Mike



----- Original Message -----
From: "Jonathan Stanton" <jonathan at cnds.jhu.edu>
To: "Mike Stagnaro" <mstagnaro at hotmail.com>
Cc: <spread-users at lists.spread.org>
Sent: Wednesday, December 12, 2001 2:03 PM
Subject: Re: [Spread-users] Monitor on Win32?


> Hi,
>
> 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
>
> --
> -------------------------------------------------------
> Jonathan R. Stanton         jonathan at cs.jhu.edu
> Dept. of Computer Science
> Johns Hopkins University
> -------------------------------------------------------
>