Hello Joel!

Sunday February 11 1996 10:58, Joel Downer wrote to Doug Nazar:

JD> I see.  This is helpful information.  The way that my routines work at
JD> this point is that each node creates its own pipe, *but* all pipes are
JD> assumed to be created in the same directory.  (Thus, I assumed that in a
JD> networked environment, they'd all create the pipes on a common server.)

Except pipes are a part of OS/2, not the network .

JD> It sounds as if in a peer environment, I could have each node create
JD> its pipe locally, and allow the sysop to specify *all the machine names*
JD> that may run Ox on the LAN so that the door can check each of them for
JD> node pipes.  On the other hand, that would only work if all of the
JD> machines running BBS nodes were configured to act as servers rather than
JD> just clients, right?

Right. This is IMHO, one of the worst ways of solving this. 

JD> The alternative, I suppose, would be to write a fairly simple message
JD> coordinator program that would run on a central server machine and route
JD> messages back and forth between all the nodes.  I've avoided things like
JD> this thus far because they seem to complicate the setup for the door,
JD> but it sounds as if this may be my only alternative.

This is what Maximus does with it's MCP.EXE program. From my point of view,
this will actually simplify your configuration.

The server program simply gets the max number of clients (let's call it X)
from it's config file or the command-line. Creates the named pipe on the
server specifying X connections. You then create X number of threads which
each do a DosConnectNPipe and then what for a client. You then route msgs
between clients, maybe support for broadcast msgs & toss in a few msgs
that the server replies to say about the number of nodes connected or
something.

The client's all have the same named pipe "\\Server\Pipe\oxpipe".
You don't need to tack on a node number.

A few days work to get up and running and then you're home free 

Doug

--- GoldED/2 2.50+