From Newsgroup: alt.bbs.general
Followups to: alt.bbs.general
Hi,
How did multi-node boards work?
Did they require support from the board software?
Or did each node (machine) only know about the drive letters and serial ports that it had access to?
Basically it required support from the BBS software. Usually it ran
under a multitasking OS such as Desqview or OS/2. Now days Windows
and Linux are quite capable of running multinode BBS packages.
How did multi-node boards work?
Did they require support from the board software?
Or did each node (machine) only know about the drive letters and
serial ports that it had access to?
Hello All.
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.
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.
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?
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?
Note: I'm purposefully eliding complicating factors like multiple instances trying to edit / update a given file / echo / etc.
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.
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.
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.
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.)
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.
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.
Hello All.
Grant, I may have replied to this in the past, but somehow I have
lost track of that response, if it actually existed...
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
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.
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.
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.
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.
See my prior explanation.
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,
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; 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.
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?
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.
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?
Greetings, Grant.
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.
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.
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>
Hopefully that sheds a tiny bit more light on my somewhat antiquated
but still operating BBS system.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 910 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 113:23:23 |
| Calls: | 12,126 |
| Files: | 186,512 |
| Messages: | 2,230,024 |