Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
How did multi-node boards work?
5 views
Skip to first unread message
Grant Taylor
Jun 12, 2019, 11:53:50 PM6/12/19
to
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?
--
Grant. . . .
unix || die
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?
--
Grant. . . .
unix || die
DaiTengu
Jun 13, 2019, 6:55:24 PM6/13/19
to
To: Grant Taylor
Re: How did multi-node boards work?
By: Grant Taylor to alt.bbs,alt.bbs.allsysop,alt.bbs.general on Wed Jun 12 2019 09:53 pm
GT> From Newsgroup: alt.bbs.general
GT> Followups to: alt.bbs.general
GT> Hi,
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 serial
GT> 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.
DaiTengu
... He who laughs last probably didn't get the joke.
--- Synchronet 3.17c-Linux NewsLink 1.110
* War Ensemble BBS - Appleton, WI - telnet://warensemble.com
Re: How did multi-node boards work?
By: Grant Taylor to alt.bbs,alt.bbs.allsysop,alt.bbs.general on Wed Jun 12 2019 09:53 pm
GT> From Newsgroup: alt.bbs.general
GT> Followups to: alt.bbs.general
GT> Hi,
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 serial
GT> 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.
DaiTengu
... He who laughs last probably didn't get the joke.
--- Synchronet 3.17c-Linux NewsLink 1.110
* War Ensemble BBS - Appleton, WI - telnet://warensemble.com
Grant Taylor
Jun 14, 2019, 10:12:00 PM6/14/19
to
On 6/13/19 4:51 PM, DaiTengu wrote:
> 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.
Thank you for the reply DaiTengu.
> 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.
Marc Lewis
Aug 18, 2020, 12:08:05 PM8/18/20
to
+ 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
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
Grant Taylor
Sep 6, 2020, 11:54:05 PM9/6/20
to
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.
Synchronet means two very different things to me. Chronologically first
/was/ the Synchronet of the '80s & '90s that was a more traditional BBS.
Chronologically second /is/ the package that is more a collection of
various components that make up a turn key web / message exchange / file
transfer system using contemporary components.
> 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.
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.
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.
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.
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.
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
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.
/was/ the Synchronet of the '80s & '90s that was a more traditional BBS.
Chronologically second /is/ the package that is more a collection of
various components that make up a turn key web / message exchange / file
transfer system using contemporary components.
> 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.
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.
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.
0 new messages