• How did multi-node boards work?

    From DaiTengu@21:1/5 to All on Thu Jun 13 17:51:04 2019
    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

    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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to DaiTengu on Fri Jun 14 20:12:01 2019
    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.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Lewis@21:1/5 to All on Tue Aug 18 09:58:57 2020
    + 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? >

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Marc Lewis on Sun Sep 6 21:54:04 2020
    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.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Lewis@21:1/5 to All on Wed Apr 3 20:47:31 2024
    + 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Marc Lewis on Fri Apr 12 09:19:05 2024
    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. . . .

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Marc Lewis on Wed Apr 17 20:34:23 2024
    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. . . .

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)