Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.bbs.general > #688 > unrolled thread

How did multi-node boards work?

Back to article view | Back to alt.bbs.general

Contents

  How did multi-node boards work? Grant Taylor <gtaylor@tnetconsulting.net> - 2019-06-12 21:53 -0600
    How did multi-node boards work? "DaiTengu" <daitengu@warensemble.com.remove-68v-this> - 2019-06-13 17:51 -0500
      Re: How did multi-node boards work? Grant Taylor <gtaylor@tnetconsulting.net> - 2019-06-14 20:12 -0600
    RE: How did multi-node boards work? "Marc Lewis" <@p0.f45.n396.z1[ASC46]fidonet[.]org> - 2020-08-18 09:58 +0000
      Re: How did multi-node boards work? Grant Taylor <gtaylor@tnetconsulting.net> - 2020-09-06 21:54 -0600
        Re: How did multi-node boards work? "Marc Lewis" <user@net396.fidonet.org> - 2024-04-03 20:47 +0000
          Re: How did multi-node boards work? Grant Taylor <gtaylor@tnetconsulting.net> - 2024-04-12 09:19 -0500
            Re: How did multi-node boards work? "Marc Lewis" <user@net396.fidonet.org> - 2024-04-17 17:18 +0000
              Re: How did multi-node boards work? Grant Taylor <gtaylor@tnetconsulting.net> - 2024-04-17 20:34 -0500

#688 — How did multi-node boards work?

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

[toc] | [next] | [standalone]

#689

  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

[toc] | [prev] | [next] | [standalone]

#690

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

[toc] | [prev] | [next] | [standalone]

#706

+ 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

[toc] | [prev] | [next] | [standalone]

#712

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

[toc] | [prev] | [next] | [standalone]

#757

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

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

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

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

 GT> Hi,

> Grant, I can give you a quick picture of how my traditional system 
> works. It's capable of both answering a phone line as well as answer 
> a telnet connection.  Note that there are a multitude of methods of 
> handling multiple nodes on a single BBS "package". Normally all nodes 
> are on one physical machine and are called into play as required; 
> each one in its own "space" or virtual machine so to speak.

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

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

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

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

> My system, that runs under OS/2, utilizes a "front end" that determines 
> if the incoming is a data call or a human caller. There is a "front 
> end" for each node.  It's the same program that's running in its 
> own space (or instance as it were) - isolated from the other nodes 
> with its own comm port (either real or virtual), depending on if 
> it's a phone line or a telnet line coming in)  If it's a data call, 
> the incoming data is received and stored for later operations. If 
> it's a human caller, the front end has determined the incoming 
> speed of the connection and a few other pertinent options; it then 
> "spawns" an instance of the BBS program, passing to it the important 
> connection data.

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

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

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

> The BBS program then starts an instance of itself using that 
> connection data. At the close of the call, either human or data, 
> there is a "clean-up" routine that runs and prepares the system for 
> another connection.

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

No. See my prior paragraph.

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

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

> This system can in fact run without a front end, with each node of the 
> BBS fully up and ready in its own space or "window" (not to be confused 
> with the Windows operating system)... it's own virtual machine that 
> has been set up to look at a specific comm port (again, either real 
> or virtual).  This type of system does not take data calls normally.

 GT> *nod*

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

Precisely.

> The BBS initiates and asks the usual log-on questions and then starts 
> its actual session with the caller.  The nodes are isolated from one 
> another, but inter-node commication between callers (and certain data 
> links) can be done

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

I think I mentioned that the BBS program is in ONE directory with a
subdirectory for each "node" or caller. The program can "see" that other
"nodes" are in use by a cerain group of indicator files, maing this type of
chat system possible.
 
> Newer, more "modern" systems running under Windows or Linux (like, 
> for example, Synchronet) generally don't run a separate front-end, 
> and have multiple nodes up and running concurrently in their own 
> instance, window or virtual machine.  They are generally capable 
> or taking a data as well as a human caller.  Again, each node it 
> isolated from the others, and inter-node "chat" communication can be 
> done between callers.

[snip]

> DOS systems, though now few and far between, are either single-node or, 
> if they're running a DOS based "multitasker" like DesqView (which I 
> ran for many years before switching to OS/2) they can have a few nodes 
> up (usually not more than 4 due to memory limitations.) With careful 
> system set-up and a lot of config.sys and autoexec.bat manipulations 
> and a good memory manager like QEMM (tricky to fine-tune). (Side note 
> here: DesqView came BEFORE Windows 3.0 and was more stable, but since 
> it could only run programs in Real mode, it had drawbacks. It could 
> however run Windows 3 in it's own window. A decent review of DesqView 
> can be found on Wikipedia.) DesqView could access files on other 
> machines, but the networking drivers and software had to be loaded 
> before DesqView started. It's was tricky but effective. Artisoft 
> LANtastic was a favorite, but had NO TCP/IP capability, which was a 
> severe limitation.

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

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

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

See my prior explanation.

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

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

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

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

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

Best regards,
Marc
--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ The FidoNet News Gate (Huntsville, AL - USA)        +
+ The views of this user are strictly his or her own. +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[toc] | [prev] | [next] | [standalone]

#761

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

[toc] | [prev] | [next] | [standalone]

#762

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


 GT> On 4/3/24 20:47, Marc Lewis wrote:
> Hello All.

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

 GT> Thank you for the reply.  You did send something in late '20, but I
 GT> think it's better to be sure and it looks like this might be more 
 GT> 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.

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

 GT> I'm getting the impression that each instance of the BBS is sort of
 GT> run  in isolation but can look in specific locations / directories
 GT> to see if  there is status from other instances that should be
 GT> 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

 GT> What I'm not yet clear on is how users on separate nodes would chat
 GT> with  each other.  Do the nodes literally store the typed message
 GT> into a file  that the other node sees and presents to it's user in
 GT> 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.

 GT> I think what I'm mentally struggling with is that chat, or (near)
 GT> real  time communications, that I'm used to is more than just two
 GT> users  appending statements to different files.  Though I can see
 GT> how  \Maximus\0\chat-with-1.txt and \Maximus\1\chat-with-0.txt
 GT> 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.

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

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

> See my prior explanation.

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

 GT> Did nodes initiate a network protocol based connection to each
 GT> other w/o  using file / directory structure?  E.g. did they open a
 GT> 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

[toc] | [prev] | [next] | [standalone]

#763

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

[toc] | [prev] | [standalone]

Back to top | Article view | alt.bbs.general

csiph-web