Source: SPITFIRE.DOCEdition: searchable Web reading editionPresentation: historical wording retained
20.0 - OPERATING A MULTI-NODE SPITFIRE
--------------------------------------
The SPITFIRE Bulletin Board System is fully capable of operating in
a multi-node BBS environment. A multi-node BBS system is one that
allows multiple copies of SPITFIRE to run, having two or more nodes
that share a significant number of the files used during system
operation. When configured for multi-node operation, all nodes of a
SPITFIRE BBS share files contained in the WORK, MESSAGE and DISPLAY
file paths. The SYSTEM and EXTERNAL protocol file paths must be set up
individually for each node.
20.1 - MULTI-NODE BBS REQUIREMENTS
----------------------------------
In order to operate SPITFIRE in a multi-node environment, the Sysop
must either be using a multi-tasking software or have multiple computer
systems networked together. Under most circumstances, each node the
Sysop wishes to install will require its own telephone line and modem.
The exception to this being, if in either the multi-tasking or network
environment, the Sysop configures a copy of SPITFIRE BBS with a
maximum baud rate of 0 (making that node only accessible by local
log on).
20.2 - CONFIGURING SPITFIRE FOR MULTI-NODE OPERATION
----------------------------------------------------
In general, SPITFIRE is configured much the same for multi-node as
it is for a single node system. (Refer to the SPITFIRE CONFIGURATION
section of this manual for more detailed information.) However, there
are several configuration options the Sysop must be sure to set
correctly when installing or expanding to a multi-node system.
To begin, press ALT+Z to open SPITFIRE's configuration window.
Modifications must be made so that a node number is assigned for the
individual node being configured and the total number of available
nodes entered. Also, it is possible to configure one or more of the
available nodes as a private BBS. If this is done, be sure to use the
ALT+Z option to set the security required for accessing the private
node being configured. For any node not configured as a private BBS,
simply have the security required set to zero. These settings need to
be appropriately configured for each node on the system.
In addition, when operating SPITFIRE in a multi-node environment,
the DOS SHARE program is normally required to be used. This can be
accomplished by placing SHARE in the AUTOEXEC.BAT so SHARE is loaded
each time that the computer is booted.
20.3 - FEATURES UNIQUE TO MULTI-NODE OPERATION
----------------------------------------------
When operating a multi-node SPITFIRE BBS system, one of the options
available from the Main Menu is <W>...Who On. If a caller selects this
option, information is displayed to the screen telling the caller of
anyone else who is currently logged on to any of the other available
nodes. The information of who is on the various system nodes is stored
in SFWHOSON.DAT, which resides in SPITFIRE's Work File Path.
Several features unique to the multi-node SPITFIRE environment
relate to packing the message base or caller's file. It is extremely
important that there is no other BBS activity during the packing of
these files. Therefore, certain safeguards are included in SPITFIRE
which monitor activity on all nodes to prevent system access when
packing of these files is in progress. Similarly, SPITFIRE will not
allow these files to be packed if there is activity on any of the
available nodes.
SPITFIRE does not allow a Sysop to use the internal SPITFIRE
commands for packing the caller file or packing the message base while
a caller is logged on one of the other nodes. If the Sysop attempts
this, the following message will be displayed: "Sysop, you are not
allowed to pack the caller's file/message base while other nodes are
busy." Depending upon which activity is trying to be performed, either
the text of caller's file or message base will display in the above
message.
If a caller attempts to log onto the system when SPITFIRE is
packing the message base or caller's file, SPITFIRE displays the
following message, "A maintenance operation is presently being
performed! Please call back in a few minutes." Upon logging on
the caller is shown the SFPRELOG.BBS and the WELCOME1.[BCR] but after
entering their name and password the above message will be displayed.
Sysops may create their own screen for displaying the maintenance
message if preferred. This screen, SFMAINT.[BCR] displays
immediately after the caller enters their name, replacing SPITFIRE's
default message mentioned above.
If configured as a multi-node system, when booted, SPITFIRE checks
to determine whether maintenance is being performed (packing the
callers file and packing the message base). In the event SPITFIRE
discovers that maintenance is being performed, the following message
is displayed:
Report - Maintenance Being Performed.
Pausing Until Maintenance Is Complete.
Press Any Key To Return To DOS.
SPITFIRE then goes into a loop and continues to check the
maintenance status indefinitely until the maintenance has been
completed. When the maintenance is completed, SPITFIRE continues
initialization and waits for a caller. During the time while SPITFIRE
is doing the continuous maintenance check loop, if a key is pressed
SPITFIRE terminates and returns to DOS. In other words, when booting
SPITFIRE, if it is discovered that maintenance is being performed by
another node, SPITFIRE loops until the maintenance status changes or
until the Sysop presses a key to return to DOS.
20.4 - NODE CHAT
----------------
On a multi-node SPITFIRE BBS, a caller is able to chat with
callers on another node via the Node Chat feature. This feature is
accessed by selecting the "<W>ho's On The Other Node?" Menu Selection
which is available from the Main Menu.
Configuring Node Chat
---------------------
To set up Node Chat, the Sysop will need to configure the
Node Chat Drive from SPITFIRE's ALT+Z configuration window. This
field should be configured to the drive letter where the node chat
file will be stored. The Node Chat Drive should be a common drive
shared by all nodes. Due to the constant reading of the node chat
file, it is highly recommended that a RAM drive be used for storing
the node chat file. DOS comes with the necessary software needed
for creating a RAM drive and the DOS manual contains instructions
on how to set up a RAM drive.
After configuring the Node Chat Drive, the Sysop may need to
edit DAILYLMT.DAT. Node chat parameters are specific to each
security level. The default values allow for five Node Chats of five
minutes each per day. To set specific values for a given security
level, the following parameters (preceded by ONE comma) may be
appended to any security level's entry in DAILYLMT.DAT:
#OCA=(Number Of Node Chats Allowed Each Day)
TPNC=(Time In Minutes Permitted For Each Node Chat)
An example DAILYLMT.DAT might look like this:
4,MPC=0,MPD=0,DLPD=0,#OCA=0,TPNC=0 (Zero Permitted, Zero Minutes)
5,MPC=30,MPD=30,DLPD=10,KB=2000 (Default Number And Time)
10,MPC=60,MPD=60,DLPD=15,KB=5000,#OCA=10,TPNC=20
(10 Chats Daily, 20 Minutes Each)
20,MPC=60,MPD=60,DLPD=15,KB=5000,TPNC=30
(Default Number, 30 Minutes Each)
30,MPC=60,MPD=60,DLPD=15,KB=5000,#OCA=20
(20 Chats Daily, Default Time)
To use default values for both Number Of Chats Daily and Time Per Chat
for ALL security levels, no changes need to be made to DAILYLMT.DAT.
***NOTE*** It is REQUIRED that ALL nodes on a multi-node SPITFIRE BBS
have a common Node Chat Drive in order to be available for Node Chat!
Initiating Node Chat
--------------------
When a caller selects "<W>ho's On...", they are presented with a
summary of activities on the other nodes. Callers on the other nodes
are NOT available for Node Chat under the following circumstances:
* when they are chatting with the Sysop (Local Chat)
* when they are using a Door
* when they are already in another Node Chat
* when they are entering messages
* when they are involved in the transmission of files
* when those with Sysop-Level Security are using Sysop Utilities
The caller desiring the Node Chat sees something like this:
"This BBS supports 3 nodes.
--------------------------
Node 1 - (1st Caller) ................... Available for chat!
Node 2 - (2nd Caller) ................... Available for chat!
Node 3 - Busy Caller ................... Transmitting file!
(1st Caller), would you like to initiate a Node Chat? <y/n> "
A <y>es response then prompts the caller:
" Chat with which node # "
If the caller who desires a node chat enters a valid node number,
the caller on the desired node is notified that a Node Chat with them
is requested and by whom. They then see something like this:
" (2nd Caller) would like to chat!
Would you like to chat with (1st Caller)? <Y/n> "
" Awaiting other node response...Press ESC to abort! "
If the chatted caller agrees to chat, Node Chat begins with the
following message:
There are <xx> minutes allowed for this chat.
Press ESC when ready to terminate chat.
If the chatted caller does not want to chat, the caller who
requested the chat is returned to the BBS after a short period of time.
They are free to request another Node Chat later or attempt to chat
with another node.
Terminating Node Chat
---------------------
The chat conversation will proceed in the same fashion as the
Sysop chat, with each caller alternating their exchange until one
of the callers terminates the chat by pressing the ESC key or the
chat is terminated as a result of exhausting all the time allowed
for the node chat. When the chat is terminated by one of the chat
participants, the message:
<Caller> aborted chat.
displays and the callers are returned to the section of the BBS that
they were in before the Node Chat began.
Prior to the chat being terminated as a result of using all of the
allowable time for the node chat, SPITFIRE will display a message
notifying the participants that 2 minute (or less) remain in the chat.
In the event the chat is terminated due to the amount of time allowed
for the node chat being exhausted, both callers in the node chat are
notified of this and returned to the BBS.
Also, if either caller drops carrier for any reason, the Node Chat is
terminated and the other caller is returned to the BBS.