RE: How did multi-node boards work?

+ User FidoNet address: 1:396/45
Hello All.

<On 12Jun2020 09:53 Grant Taylor wrote a message to All regarding How did
multi-node boards work? >

 GT> How did multi-node boards work?

 GT> Did they require support from the board software?

 GT> Or did each node (machine) only know about the drive letters and
 GT> serial  ports that it had access to?

Grant, I can give you a quick picture of how my traditional system works. It's
capable of both answering a phone line as well as answer a telnet connection.
Note that there are a multitude of methods of handling multiple nodes on a
single BBS "package". Normally all nodes are on one physical machine and are
called into play as required; each one in its own "space" or virtual machine so
to speak.

My system, that runs under OS/2, utilizes a "front end" that determines if the
incoming is a data call or a human caller. There is a "front end" for each
node.  It's the same program that's running in its own space (or instance as it
were) - isolated from the other nodes with its own comm port (either real or
virtual), depending on if it's a phone line or a telnet line coming in)  If
it's a data call, the incoming data is received and stored for later
operations. If it's a human caller, the front end has determined the incoming
speed of the connection and a few other pertinent options; it then "spawns" an
instance of the BBS program, passing to it the important connection data.  The
BBS program then starts an instance of itself using that connection data. At
the close of the call, either human or data, there is a "clean-up" routine that
runs and prepares the system for another connection.

This system can in fact run without a front end, with each node of the BBS
fully up and ready in its own space or "window" (not to be confused with the
Windows operating system)... it's own virtual machine that has been set up to
look at a specific comm port (again, either real or virtual).  This type of
system does not take data calls normally.  The BBS initiates and asks the usual
log-on questions and then starts its actual session with the caller.  The nodes
are isolated from one another, but inter-node commication between callers (and
certain data links) can be done

Newer, more "modern" systems running under Windows or Linux (like, for example,
Synchronet) generally don't run a separate front-end, and have multiple nodes
up and running concurrently in their own instance, window or virtual machine. 
They are generally capable or taking a data as well as a human caller.  Again,
each node it isolated from the others, and inter-node "chat" communication can
be done between callers.

DOS systems, though now few and far between, are either single-node or, if
they're running a DOS based "multitasker" like DesqView (which I ran for many
years before switching to OS/2) they can have a few nodes up (usually not more
than 4 due to memory limitations.) With careful system set-up and a lot of
config.sys and autoexec.bat manipulations and a good memory manager like QEMM
(tricky to fine-tune). (Side note here: DesqView came BEFORE Windows 3.0 and
was more stable, but since it could only run programs in Real mode, it had
drawbacks. It could however run Windows 3 in it's own window. A decent review
of DesqView can be found on Wikipedia.) DesqView could access files on other
machines, but the networking drivers and software had to be loaded before
DesqView started. It's was tricky but effective. Artisoft LANtastic was a
favorite, but had NO TCP/IP capability, which was a severe limitation.

Hopefully, this will give you at least an inview of how these BBSes can run
multiple nodes concurrently.

Best regards,
Marc
--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ The FidoNet News Gate (Huntsville, AL - USA)        +
+ The views of this user are strictly his or her own. +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus