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

On 8/18/20 9:58 AM, Marc Lewis wrote:

Hello All.

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.

Would you mind elaborating on what you mean by "space" or "virtual machine"? I'm specifically wondering if you mean something like
VMware / VirtualBox / KVM / etc. Or if they are just separate
running processes, each in their own window on something like
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.

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

But it sounds like data would be something like mail transfer and
human is an interactive caller who will surf the board / play door
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.

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

No. See my prior paragraph.

Note: I'm purposefully eliding complicating factors like multiple 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.

*nod*

I take it that the purpose of the front end is to identify if it's
an interactive human seeking the BBS itself vs an automated
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

Are you doing inter-node communications? If so, please elaborate
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.

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

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

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

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


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: FidoNet (3:633/280.2@fidonet)

On 4/3/24 20:47, Marc Lewis wrote:

Hello All.

Hi Marc,

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

Thank you for the reply. You did send something in late '20, but I
think it's better to be sure and it looks like this might be more
detailed response.

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.

Are those three (sub)directories for the current connected user on a
given node? Or are they actual user directories; e.g. Mark & Grant? --
I'm going to assume the former unless / until you correct me.

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.

I'm getting the impression that each instance of the BBS is sort of run
in isolation but can look in specific locations / directories to see if
there is status from other instances that should be integrated into what
the local instance is doing.

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

What I'm not yet clear on is how users on separate nodes would chat with
each other. Do the nodes literally store the typed message into a file
that the other node sees and presents to it's user in a relatively real
time fashion?

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.

ACK

No. See my prior paragraph.

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.

ACK

Precisely.

:-)

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.

I think what I'm mentally struggling with is that chat, or (near) real
time communications, that I'm used to is more than just two users
appending statements to different files. Though I can see how \Maximux\0\chat-with-1.txt and \Maximux\1\chat-with-0.txt having lines (appended?) of text could work.

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.

Seems like the crux was that each node could access and update the same
set of directories, probably independent of the underlying
communications mechanism.

I suspect that extends to running multiple nodes at the same time via
DesqView / OS/2 / Windows NT, etc.

See my prior explanation.

Let me re-phrase. Was there any communications between the nodes that
wasn't based on files / directories in a common directory structure?

Did nodes initiate a network protocol based connection to each other w/o
using file / directory structure? E.g. did they open a network socket
to each other?

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.

You're perfectly fine.

Thank you for the reply.

Best regards,

Likewise,



--
Grant. . . .

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: TNet Consulting (3:633/280.2@fidonet)

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

<On 11Apr2024 22:19 Grant Taylor (1:396/4) wrote a message to All regarding Re: How did multi-node boards work? >

On 4/3/24 20:47, Marc Lewis wrote:

Hello All.

Hi Marc,

Greetings, Grant.

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

Thank you for the reply. You did send something in late '20, but I
think it's better to be sure and it looks like this might be more detailed response.

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; each 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 \Maximus
\0
\1
\2
Where the user information is stored for who is on, and the "door" information files for the various games and functions.

Are those three (sub)directories for the current connected user on
a given node? Or are they actual user directories; e.g. Mark &
Grant? -- I'm going to assume the former unless / until you
correct me.

When someone logs into the system via Telnet (or my local node) it's assigned to a specific sub-directory in the \MAX directory relative to the order the call was received in. E.g., if I log into the system locally (not telnet) it's automagically Node 0 and my user info appears in that subdirectory. The next person that logs in via telnet will end up in either \1, \4, or \5. \2 is dial-up. \3 is a special purpose one that is seldom used, though if I had another available node in VModem, it would be used for that, but the license is for 3 nodes. Of course VModem isn't utilised for dial-up.

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.

I'm getting the impression that each instance of the BBS is sort of
run in isolation but can look in specific locations / directories
to see if there is status from other instances that should be
integrated into what the local instance is doing.

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

What I'm not yet clear on is how users on separate nodes would chat
with each other. Do the nodes literally store the typed message
into a file that the other node sees and presents to it's user in
a relatively real time fashion?

It's all part of the Maximus program, where it can "see" the other users and whether or not they are available for chat (not in an external program like a game or editing a message.) On the Main Menu there is a Who command that shows (W)ho is on [one presses 'W' to get to that.] And yes, inter-node chat is in real-time. I am sure that other BBS systems can do something similar.

[snip]

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 certain group of indicator files,
making this type of chat system possible.

I think what I'm mentally struggling with is that chat, or (near)
real time communications, that I'm used to is more than just two
users appending statements to different files. Though I can see
how \Maximus\0\chat-with-1.txt and \Maximus\1\chat-with-0.txt
having lines (appended?) of text could work.

I've not given too much thought to precisely how the system does real-time, but with a system like OS/2 (and probably certain versions of Windows that are genuine multi-tasking/multi-threaded it would be possible.)

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.

Seems like the crux was that each node could access and update the
same set of directories, probably independent of the underlying communications mechanism.

I suspect that extends to running multiple nodes at the same time
via DesqView / OS/2 / Windows NT, etc.

See my prior explanation.

Let me re-phrase. Was there any communications between the nodes
that wasn't based on files / directories in a common directory
structure?

Did nodes initiate a network protocol based connection to each
other w/o using file / directory structure? E.g. did they open a
network socket to each other?

On Maximus, everything is internal to the BBS program. It know precisely what is available to whatever. There probably *are* some internal intra-node "protocols", but, not being a programmer, I don't actually know how it is accomplished... It just works. <grin>

Hopefully that sheds a tiny bit more light on my somewhat antiquated but still operating BBS system.

Best regards,
Marc

... To boldly go where no sane man has any business...
--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ 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


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: FidoNet (3:633/280.2@fidonet)

On 4/17/24 17:18, Marc Lewis wrote:

Greetings, Grant.

Hi Marc,

When someone logs into the system via Telnet (or my local node) it's assigned to a specific sub-directory in the \MAX directory relative
to the order the call was received in. E.g., if I log into the system locally (not telnet) it's automagically Node 0 and my user info appears
in that subdirectory. The next person that logs in via telnet will end
up in either \1, \4, or \5. \2 is dial-up. \3 is a special purpose one
that is seldom used, though if I had another available node in VModem,
it would be used for that, but the license is for 3 nodes. Of course
VModem isn't utilised for dial-up.

Okay. Thank you. I think I get that it's literally a directory named
"0", "1", "2", "3", "4", or "5" and that it's sort of (roughly) akin to
phone line number (for an analogy) and not specific to a user.

It's all part of the Maximus program, where it can "see" the other
users and whether or not they are available for chat (not in an
external program like a game or editing a message.) On the Main
Menu there is a Who command that shows (W)ho is on [one presses 'W'
to get to that.] And yes, inter-node chat is in real-time. I am sure
that other BBS systems can do something similar.

ACK

I've not given too much thought to precisely how the system does
real-time, but with a system like OS/2 (and probably certain versions
of Windows that are genuine multi-tasking/multi-threaded it would
be possible.)

:-)

On Maximus, everything is internal to the BBS program. It know
precisely what is available to whatever. There probably *are* some
internal intra-node "protocols", but, not being a programmer, I don't actually know how it is accomplished... It just works. <grin>

ACK

Hopefully that sheds a tiny bit more light on my somewhat antiquated
but still operating BBS system.

Yes, it does. Thank you.

Being an OS / systems person I find early multi-user / multi-system communications systems like BBSs interesting and I enjoy learning about
them and how they worked.

Thank you for indulging my curiosity Marc. :-)



--
Grant. . . .

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: TNet Consulting (3:633/280.2@fidonet)