Re: How did multi-node boards work?

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

<On 06Sep2020 09:54 Grant Taylor wrote a message to All regarding Re: How did
multi-node boards work? >

Grant, I may have replied to this in the past, but somehow I have lost track of
that response, if it actually existed...

 GT> On 8/18/20 9:58 AM, Marc Lewis wrote:
> Hello All.

 GT> Hi,

> 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.

 GT> Would you mind elaborating on what you mean by "space" or "virtual 
 GT> machine"?  I'm specifically wondering if you mean something like
 GT> VMware  / VirtualBox / KVM / etc.  Or if they are just separate
 GT> running  processes, each in their own window on something like
 GT> Windows / OS/2 /  Linux / DESQview / etc.

I can only refer to how my system under OS/2 does it. Each node of the BBS (mu
setup had 4 running simultaneously) is in it's own memory space. I run a
software called Maximus (the version specifically for OS/2). The closest
equivalent I can think of was when I was running the DOS version under
DesqView; ieach node ran independently, but could actually "see" a user under
the other node so a "Chat" could take place between them.  I suppose to make it
 a little more clear, there is ONE Maximus directory with each "node" having
it's own user "directory" e.g \Maximux
                                             \0
                                             \1                                
                                             \2
Where the user information is stored for who is on, and the "door" infomation
files fo rthe various games and functions.

The command file (BBS.CMD) that runs the whole thing is driven by the front
end. It's a lengthy file; if you'd like to see a copy just ask and I'll post it
in a reply message. It's been over 2 decades since I wrote that .cmd file.
It came into being with the graduation from DesqView to OS/2' it was done
rather differently back then.

Inasmuch as each node is on the same machine; each node can "see" the other and
who is on      

> 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.

 GT> Okay.  You're using data and human a little big differently than
 GT> I'm  used to.  I'm thinking "data" as in "modem" and "human" as in
 GT> "voice".  Sort of like the voice / fax / modem(data) switch boxes
 GT> of yore. 

 GT> But it sounds like data would be something like mail transfer and
 GT> human  is an interactive caller who will surf the board / play door
 GT> games /  etc.  Correct?

Yes. A data call immdiately identifies itself to the front end by certain group
of data commands that it carries sends when it "hears" an answer by the system.
 On my system a human caller, not sending that data, is prompted to and then
presses the escape key to initiate a session of the BBS; then he/she logs into
the BBS or sets up an account if he/she is a first-time caller. A caller can
also log in as a Guest and not set up an account; they're limited to what BBS
functions are available, i.e. they cannot send certain kinds of messages and
can only download a certain byte count of files from the files directories.

> 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.

 GT> So, are these instances of your board aware of each other?  Or does
 GT> each  largely run independently of each other and only focus on the
 GT> port that  it's connected to?

No. See my prior paragraph.

 GT> Note:  I'm purposefully eliding complicating factors like multiple 
 GT> instances trying to edit / update a given file / echo / etc. 

Not possible; if a file is in use, the operating system is aware and doesn't
permit it.  However a two or more different persons (one on each node) could
concievably be reading the same message in the same message group (Echo as it's
termed in FidoNet); the possibility of them both finishing their response to
that particular message at the very same instance would be improbable; they
system would intervene with a delayed write.

> 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.

 GT> *nod*

 GT> I take it that the purpose of the front end is to identify if it's
 GT> an  interactive human seeking the BBS itself vs an automated
 GT> process  exchanging data, e.g. email.

Precisely.

> 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

 GT> Are you doing inter-node communications?  If so, please elaborate
 GT> on how  you are doing that.

I think I mentioned that the BBS program is in ONE directory with a
subdirectory for each "node" or caller. The program can "see" that other
"nodes" are in use by a cerain group of indicator files, maing this type of
chat system possible.
 
> 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.

[snip]

> 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.

 GT> Please elaborate on this type of networking.  I assume this is
 GT> where  NetWare Lite / Personal NetWare comes into play along side
 GT> of LANtastic.    Or could likely be done with other peer-to-peer
 GT> networking  technologies today.  (I suppose more traditional
 GT> client-server could be  used too, but that requires the dedicated
 GT> server.)

LanTastic was strictly peer-to-peer. More than likely, NetWare Lite / Personal
I believe was also strictly peer-to-peer.  Full-blown Netware was somewhat
different.

 GT> Did each board intuitively know that the other boards existed?  Or
 GT> was  each board somewhat in a vacuum and saw files in a path. 
 GT> Sometimes  those files changed in between when any given instance
 GT> looked at them  last.  This seems to make sense for things like
 GT> messages (~email) and  echos (~news(groups)).  But I'm not sure how
 GT> user to user chat would work. 

See my prior explanation.

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

 GT> Yes, it tells me a more than what I knew.

 GT> I can't find a picture that I'm thinking of, but it was something
 GT> like  20 / 40 / 44 old IBM PC/XT/AT style systems that were
 GT> networked via  something like NetWare / LANtastic / etc.  I'm
 GT> wondering how those types  of -- what I think are called --
 GT> multi-node boards worked.  I naively  assume that it was something
 GT> akin to multiple instances you mention,  just with one computer per
 GT> instance given the hardware at the time. 

There were various methods of doing things; one particular system I can think
of many years ago, LONG before the internet, had multiple computers doing just
what you were talking about - it was a medical bbs; how he accomplished it I
have no clue. I can tell you it was quite complex. I am sure he had some sort
of software or systems engineer on staff to help organise it.

Hopefully this reply isn't too tardy reaching you. And hopefully others may
gain some useful info from it.

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