home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Monster Media 1994 #1
/
monster.zip
/
monster
/
RA
/
CONDR15B.ZIP
/
CONNDOOR.DOC
< prev
next >
Wrap
Text File
|
1994-02-13
|
52KB
|
1,138 lines
CONNDOOR Version 1.5 BETA, February 13, 1994
- Written by -
Garry W. Elmer
K-9 BBS
FIDONET 1:320/105
1-203-536-1300
***********
If you are already using CONNDOOR, READ the CONNDOOR.FIX
and CHANGE.TXT file before attempting to use this
revision!!!!!
* The "|" at the end of some of the lines of this document
indicate text that has been changed or added since the last
version of CONNDOOR was released.
***********
THIS IS NOT PUBLIC DOMAIN SOFTWARE!
WARRANTY
Every effort was taken to ensure a quality program. However,
because of the there's no way to anticipate all the different
ways this program can, or will be used, or on what equipment
it may be used, I make no guarantees or warranties of any
kind, nor will I hold responsibility for any type of damage
caused by this program.
As always: BACK UP!
* The CONNDOOR program makes no modifications to your BBS
related files except the FILES.BBS files. It creates it's own
support files where needed and interfaces with the BBS via the
EXITINFO.BBS or DORINFO1.DEF file. Removing the program is a
simple matter of deleting all the associated files.
OVERVIEW
It's a file transfer door.... it's a breath mint.... It's a
FILE TRANSFER DOOR!!!
Unlike earlier versions of CONNDOOR, 1.5 has NO protection|
scheme installed and all the features and capabilities are|
fully functional. |
This door was written to fill the gap left by many other
file transfer doors. CONNDOOR has been tested with SUPERBBS
and QUICKBBS. It should be compatible with any BBS that uses
a QBBS/SBBS style of EXITINFO.BBS or DORINFO1.DEF and a text
FILES.BBS text file to keep track of directories.
Features:
Can be configured to use either EXITINFO.BBS or DORINFO1.DEF
files. Can be used from any BBS that uses either one of these
files and a FILES.BBS text file.
Supports up to 16 protocols including full duplex protocols |
such as HSLINK and BIMODEM. |
Complete carrier monitoring and "inactivity" monitoring.
"Dup" upload detection and prevention.
Variable time "payback". (2:1) (QUICKBBS/RA/SUPERBBS only) |
"Reward" system awards points to the uploader of a file when
it's downloaded by another user.
Full log keeping capabilities.
Batch up/download capabilities.
Built in TAPE DRIVE capability. |
CDROM Capability |
"DON'T WANT" file to keep unwanted files from being uploaded.
Interface with file tagging capability in SUPERBBS |
CONNDOOR Files:
CONNDOOR.EXE
Actual door program.
CONNFIG.EXE
CONNDOOR configuration program.
CTPOINT.EXE
Adds [000] to all file area descriptions if that function is
desired.
CONNMOVE.EXE
Utility to keep CONNDOOR support files up to date whenever a
change has been made to the file areas.
CONNSET.EXE
Used to create CONNDOOR file area support files on the initial
installation and to "pickup" new files into the system when
they have been manually added.
CONNUSER.EXE
Creates CONNDOOR user data base from USERS.BBS file.
CONNEDIT.EXE
File listing and User database editor.
TEST.EXE
Dummy protocol simulator for setup testing. Consult
TESTING.DOC for more info.
Misc sample configurations
ASSUMPTIONS
CONNDOOR now accepts "blind" uploads (uploads not identified |
prior to the start of the transfer). This is sysop definable.|
The door is set up to take uploads in ONE directory per
configuration. If your system is set up to allow the user to
upload into whatever directory they are in, CONNDOOR may not
suit your needs. Multiple configurations can be used to meet|
a variety of requirements. |
If you use the download counter "[000]" configuration, the
counter text must be 3 digits. CONNDOOR will ignore "[0]" or
"[00]" type configurations. There is a program included to
change and/or add the 3 digit counters to all the file listing
lines on your system. This program will also convert the
counts from the 1 or 2 digit configurations.
CONNDOOR does not care about the "K" totals uploaded or
downloaded. Points are awarded per successful upload
regardless of file size. For downloads, CONNDOOR only cares
whether the user has enough points and has enough time left.
The equation I used for determining transfer time is not based
on 100% efficiency and usually favors the user.
INSTALLATION
A test program is included (TEST.EXE) to simulate a |
protocol to facilitate testing once the system is set up. |
This program will return an Errorlevel 0 telling CONNDOOR |
that the transfer was successful. Consult the TESTING.DOC |
for more info on it's use. |
For the sake of speed, all the examples and samples reference
the default or BBS directory as D:\QUICK. That is where all
of my BBS files are. In your configurations, just change the
D:\QUICK to whatever directory you keep your main BBS files.
MUST do/have prior to operation:
The following things HAVE TO BE DONE before the door can be
properly used. Place all the files from the main compressed
file in your main BBS file directory.
The protocol programs you are planning to use should also be
in the main BBS directory.
***** VERY IMPORTANT *****
Create a text file called "DF.CTL". This is the default CTL|
file name and a list of directories that CONNDOOR will be |
able to access. |
This file is a listing of all of your file directory paths.
No tabs or spaces should be left in the beginning of each
entry, and even though the door programs will ignore extra
entries, it's best not to tempt fate.
It should look something like this:
C:\TRASH
D:\GAMES
C:\MODEM
C:\WORD
and so on, listing all the file areas you want your users to
be able to access.
MUST HAVE !!! MUST HAVE!!!! MUST HAVE !!!!!
The FIRST entry in the DF.CTL file must be a TRASH directory
of some kind. If you don't use a trash directory to keep a
FILES.BBS listing of files that you DON'T want on your system,
you must create one and it MUST be the first directory listed
in the DF.CTL. If this is not done, CONNDOOR will make a real
mess of it's support files.
TRASH DIRECTORY
This is the first directory in the DF.CTL. CONNDOOR always
looks in this directory first (the first directory in the
DF.CTL listing) and assumes that these are the files you DO
NOT want uploaded.
In this directory, a CONNDOOR support file will be created and
checked like all the other directories when a user attempts to
upload a file. If the file is found, during an upload
sequence, as in any of the directory support files, it will be
rejected. If you do not have one with a FILES.BBS file in it,
I suggest you create a dummy directory for this purpose and add a
FILES.BBS text file to it with a blank line (Carriage Return).
Make sure it's the FIRST path listed in the DF.CTL. More on
this in the FILE AREA MAINTENANCE paragraph.
After the above things have been done, follow the steps listed
below to install.
STEP 1.
******************CONNDOOR CONFIGURATION*********************
(The line editor used in the entry of various things in the
CONNFIG and CONNMOVE programs is nothing extravagant. After
making changes, re-run the program to make sure the system took
what you wanted to write.)
Execute the CONNFIG.EXE file within the BBS directory. The
utility creates the two CONNDOOR configuration files,
CONNDOOR.CFG and CONNDOOR.PRO. The first page of the program is
the basic configuration. Most of it is self-explanatory.
CONNDOOR.CFG - Created by CONNFIG.EXE and contains CONNDOOR's
operating parameters. Multiple CFG files can be used.
CONNDOOR.PRO - Created by CONNFIG.EXE and contains the
commandlines for the various file transfer protocols used with
CONNDOOR.
CONFIGURATION PAGE
BBS EXIT FILE TYPE -
This is an EXTREMELY IMPORTANT function!!! This is the file
that CONNDOOR will look for when it starts up. If you are
using SUPERBBS, QUICKBBS, RA, or any other clone of these
programs, use the EXITINFO.BBS selection!!!!!! This allows
the most data to be passed between CONNDOOR and the BBS
program.
If your BBS program can create a DORINFO1.DEF text file but
cannot create an EXITINFO.BBS file, use the DORINFO1.DEF
selection.
!! WARNING !!
The EXITINFO.BBS mode and DORINFO1.DEF mode cause CONNDOOR to
use different sizes of records for the USERS.DIL file (user
records). If you set your system in one mode, then change
it later, your USERS.DIL database will NOT WORK and will be
corrupted and unusable. CONNFIG.EXE will prompt you if you
try to change it.
UPLOAD DIRECTORY -
The UPLOAD Directory is the path to where newly uploaded
files will go.
UPLOAD & DOWNLOAD LOG(s) -
The UPLOAD and DOWNLOAD LOG lines are the path and file names
where CONNDOOR will report on what files have been successfully
uploaded and downloaded.
SYSTEM LOG -
The SYSTEM Log is usually the path and file name of the BBS
system log.
DSZ LOG -
This is the complete path to where your system has it's
DSZ.LOG file. The DSZLOG is created by the DSZ protocol
program and several other popular protocols. CONNDOOR can use
this file to verify successful downloads and "blind" uploads. |
COM PORT -
Enter a ,1 2, 3, or 4.
MIN "K" -
The MIN "K" Entry is the minimum amount of bytes open in the
upload partition before CONNDOOR will prohibit uploads. The
sample configuration is set to 500K or 1/2 Meg. If there's
less than that available, no uploading will be allowed.
NEW USER POINTS -
The number of points given to a new user. When a new user
goes into the CONNDOOR for the first time, the door program
will give him this to start. If you use CONNUSER
(EXITINFO.BBS style BBSs only) to set up the CONNDOOR user
database, it will give everyone 10 points to start and count
their uploads and downloads from there to determine how many
points they have. New users will automatically be given
accounts when they enter the door for the first time.
POINTS GIVEN FOR UPLOAD -
The points given to a user for each file they successfully upload.
UPLOAD POINTS -
The points assigned to a file when it is uploaded. This could
be considered the "cost" of the program for others to
download.
PAY POINTS -
The points awarded to the uploader of a file every time
someone downloads it.
EXAMPLE: (Using the sample config)
John Doe has 10 points. He uploads ABCD.ZIP to the system.
He is awarded 6 points for the upload. 5 users like the
ABCD.ZIP file and download it. John Doe is awarded 1 point
for each of these downloads and winds up with a total of 21
points.
EXEMPT SECURITY LEVEL -
This function allows you identify users that have no
downloading restrictions. If you set it at 70, everyone with
a Security Level of 70 or above is considered "EXEMPT".
CONNDOOR will not let their point total go below 10 in effect
giving them unlimited download capability except for time. If
you do not want this capability enabled, enter 0.
ADD COUNTER -
This function will include the "[000]" download counter in
the file descriptions of uploaded files and update them when
the files are downloaded. YES to enable. (Executing
CTPOINT.EXE will add these to your file descriptions. (See
Step 6 in the SETUP Section)
ADD +++++ -
This function will put "+++++" in the beginning of the file
description. This will be replaced by the files actual date
when processed by MidNightMover 2.3D (MNM) and newer versions.
The docs for MNM explain how to use the MNM. If in doubt
answer NO here. (MNM can be obtained from my BBS)
********
The next two lines have to do with TAPE DRIVE utilization. |
(See the Section on TAPE) |
********
ALLOW BLIND UPLOADS - |
I define a "blind" uploading as starting the protocol before|
the upload has been identified by the user. The file must |
be processed after the upload. Some protocols, such as |
Z-modem, allow operation in this mode. If you answer"YES", |
the user will be able to start the protocol and the file will|
be checked against the file libraries and DON'T WANT lists |
after the upload. The user will also be prompted for a |
description after the upload. Duplicate uploads with be |
rejected and deleted. Files not wanted will be retained, |
but the user will not get credit for these files. |
UPLOAD TIME PAYBACK -
This selection allows you to identify how much time, if any,|
is given back to the user for the time they spent |
successfully uploading a file. The selections: |
0 = User does not get any time added to their session for a |
successful upload. |
1 = User will get the time they spent uploading, added to |
their online time. |
2 = User will get twice the time they used on a successful |
upload. |
Once you have completed the first page, press F2 to call the
protocol page.
PROTOCOL PAGE
You will see two columns of selections. |
These are the available "slots" for protocols. Select the
number of the "slot" that you want to update.
The changeable selections will appear below:
ENABLE KEY - The key the user will press to select that
protocol. Entering a "-" will effectively clear the entry.
CONNDOOR will ignore it.
LINE NAME - The protocol's name
DESCRIPTION - Any amplifying info you want to add.
When the user is online, they will see
ENABLE KEY. LINE NAME DESCRIPTION
for each protocol.
Example:
"Z. ZMODEM Fast!!!!"
UPLOAD COMMANDLINE - The commandline for that protocol for
files to be RECEIVED by the BBS.
DOWNLOAD COMMANDLINE - The commandline for that protocol to
SEND files to the user.
(When making changes to the commandlines, CONNFIG will
automatically take out extra spaces left from the editing
since an insert and delete function are not included in the
line editor)
PROTOCOL COMMANDLINE VARIABLES
%1 BAUD Rate of the Connection
%2 COM Port to communicate with
%3 STRING, a list of selected uploads or downloads
%4 LIST, a file created with a list of download files.
(Used with Zmodem like protocols)
%5 UPLOAD PATH, Complete path to your upload directory
%6 TIME LEFT, How much time the user has left online
All of these variables do not have to be used in every
commandline. Look at the sample configurations and if in
doubt, consult the docs for the protocol you are trying to
install.
BATCH TOTAL - If the protocol can handle batch transmissions
(more than one file in a single session), this is total files
that CONNDOOR will let the user select at one time. (10 is the
maximum)
LOG TYPE - There are 3 selections, DSZLOG, BIMODEM, NONE.
- TYPES -
BIMODEM - When the user selects this log type, the protocol is
executed immediately. This should only be used with BIMODEM.
I have not considered any other uses for it. (See the BIMODEM
Paragraph for details)
DSZLOG - This tells CONNDOOR to check for the DSZLOG after a
download. If the downloaded file is listed in the DSZLOG,
credit is taken from the user. Only successfully downloaded
files will be subtracted from the user's account. Only
protocols set up to create a DSZLOG should have this function
enabled (Zmodem, PUMA, etc). CONNDOOR will look for the
DSZLOG in the path designated in the CONNDOOR Configuration.
If you select this log type and CONNDOOR can not find the
DSZLOG, CONNDOOR will consider the download successful and
points taken from the user for the file whether the transfer
was successful or not.
FULL DUPLEX - This selection is used for full duplex (upload |
and download at the same time) protocols such as HSLINK. The|
only thing required is that the user identify downloads prior|
to downloading and that the protocol be capable of making |
DSZ.LOG style entries. CONNDOOR will determine if files were|
uploaded from this log and prompt the user for descriptions |
accordingly. DO NOT use this selection with BIMODEM as a |
more extensive interface is already built in for BIMODEM. |
NONE - CONNDOOR has no way of determining if a requested
download was completed. If the download was started, CONNDOOR
counts all the downloads against the user's account whether
they got the files or not. The "BLIND" upload function |
should NOT be enabled with this selection. |
F2 will return you to the first page. F1 will cause the
configuration to be saved and program terminated, ESC will
cause the program to terminate without updating the CONNDOOR
configuration files. This configuration can be changed at
any time.
STEP 2.
After DF.CTL has been created and the CONNDOOR configuration
created, the file areas have to be "Initialized".
Execute "CONNSET /A". This will cause the CONNSET program to
read all the FILES.BBS files in all the directories listed in
the DF.CTL file creating a "FILES.DIL" file in each directory.
This file has the file name, uploader's name, and point cost
of each file. When run with the "/A" switch, the point cost
is set to 1 and no uploader is listed. NEVER use the "/A"
switch again! The "/A" switch causes all the FILES.DIL files
(CONNDOOR directory support files) to be created from scratch
and all files will have no uploader listed and cost 1 point,
basically resetting the entire CONNDOOR file system.
STEP 3.
Execute CONNMOVE.EXE. A short configuration file will appear.
SCAN DIRECTORY is the directory your uploads go into, TRASH
directory is just that. (should be the same as the first entry
in DF.CTL). FILE LISTING is the DF.CTL file. This will
compare the FILES.BBS, FILES.DIL and actual files in the
directory. If the file is not found in the directory, CONNMOVE
will search all the other directories for the file. If the
file is not found, the FILES.DIL entry is moved to the
FILES.DIL in the TRASH directory. If the file is found in
another directory, the entry is moved to the FILES.DIL file in
that directory. This effectively "syncs" the FILES.DIL files,
with the FILES.BBS files and actual files in each directory.
Step 4.
The CONNDOOR in the BBS BATCH FILE
CONNDOOR must be activated from your BBS batch file with a Type
15 menu command. The basic commandline "switches" are:
CONNDOOR -U (for upload)
CONNDOOR -D (for download)
**** HINT ****
Adding a "-X" to the commandline will enable the DEBUG
mode. Whenever a protocol is enabled, the protocol
command string will be sent to a file C_D_BUG.LOG in the
upload directory. This will help you configure your
protocols. This switch will also cause the TAPE COMMANDLINE
to be saved when CONNDOOR is in the TAPE mode.
EXAMPLE:
CONNDOOR -D -X (for download & DEBUG)
There are 3 other commandline switches to be discussed later.
This is all you need to use CONNDOOR in it's simplest mode.
Step 5.
When CONNDOOR is executed from the BBS, CONNDOOR will search
for EXITINFO.BBS or DORINFO1.DEF, DF.CTL, CONNDOOR.CFG,
CONNDOOR.PRO, DONTWANT.DIL and USERS.DIL. All these files are
created either by the BBS or by you during the setup except
for USERS.DIL. USERS.DIL is the file that keeps track of a
user's points for CONNDOOR. USERS.DIL can be created one of
two ways. If there is no USERS.DIL, CONNDOOR will create one
as if the user is new, give them whatever points you have
identified for new users and allow them to go on their merry
way. The only users that will be listed in USERS.DIL are the
ones that use the door. This is by far the easiest way to
start up, but all of your users will be starting "fresh"
regardless of their previous file ratios, good or bad. This
is the ONLY way you can create a USERS.DIL file when
DORINFO1.DEF has been selected in the CONNFIG.EXE program.
(QUICKBBS/RA/SUPERBBS systems only)
(BBS EXIT FILE TYPE = EXITINFO.BBS)
The other way is to execute CONNUSER.EXE. CONNUSER.EXE will
take your BBS's USERS.BBS file, read it, compute how many
points the users would've earned with their current
upload/download count and make a USERS.DIL database from this
info. CONNUSER will delete itself after execution since it
only needs to be executed once. If a user winds up with a
negative point count, CONNUSER will set their point total to
zero. CONNUSER can only read and interpret a
QUICKBBS/SUPERBBS/RA style of USERS.BBS file.
Step 6. (Optional)
CTPOINT.EXE is a utility program to modify your existing
FILES.BBS text files. CONNDOOR has the ability to update the
"[000]" 3 digit style of download counters in the FILES.BBS
files. CONNDOOR, however, will NOT update the 2 or 1 digit
format, "[00]" or "[0]". Executing CTPOINT.EXE will add or
change all of these entries in all of the FILES.BBS files in
the directories listed in the DF.CTL. It will keep and/or
transpose the counts if they already exist in any format
closed by the "[]" brackets.
******************************
DONTWANT.DIL
This is an optional ASCII text file containing the names or
portions of names of files that you DO NOT want uploaded to
your system. One entry per line and no extra spaces or
characters should be added. If CONNDOOR finds a match between
any line in this file, and ANY portion of an upload file's
name, the file will be rejected. If you do not desire to use
this function, delete the sample DONTWANT.DIL file included |
with the program. Multiple "DONTWANT" type files can be |
used with the "-W" commandline switch. (EX. -WREJECT.LST) |
EXAMPLE:
If you put "GIF" in the DONTWANT.DIL file, CONNDOOR will reject
A.GIF, ABCD.GIF, and GIFVUE.ZIP uploads.
IF you only wanted to reject attempted upload files with the
extension "GIF" you would have to put ".GIF" in the
DONTWANT.DIL file. The first two GIF files would be rejected
and GIFVUE.ZIP could be uploaded.
BIMODEM
BIMODEM is a popular "full duplex" protocol allowing files to
be uploaded and downloaded at the same time. BIMODEM
commandline examples are set in the CONNDOOR.PRO configuration
file. CONNDOOR looks for a file BI.DIL to be created by the
BIMODEM transfer. The name of this file must be identified in
the BIMODEM commandline along with the type of log BIMODEM is
to create. The "/I" BIMODEM commandline switch makes sure
that the BI.DIL file is created and is in a format that
CONNDOOR can read. In the example in the CONNDOOR config, The
time variable %6 is used to prevent BIMODEM from running over
the user's allotted time. BIMODEM is a difficult protocol to
get configured, but worth it when it works!
For downloads, BIMODEM will still search the directories
pointed to by the file area list identified in it's own
configuration.
The commandline to use BIMODEM with CONNDOOR is:
"BIMODEM /B%1 /L%2 /T%6 /IBI.DIL"
FILE AREA MAINTENANCE
ADDING & DELETING FILES
- ADDING
When a file description is added to a FILES.BBS file and the
file added to it's associated directory, it is still not
accessible to CONNDOOR. CONNDOOR uses the FILES.DIL file as
it's index of what is available in a directory. To add a
file, it must be added to the FILES.DIL file and the
FILES.BBS file. After the file description has been added to
the FILES.BBS file, running CONNSET will add the file to the
FILES.DIL file making it accessible to CONNDOOR.
- DELETING
To remove a file from the BBS, delete the description line
from the FILES.BBS and delete the file from the directory.
When the CONNMOVE.EXE program is executed, it will find the
file entry in the FILES.DIL file, but not find the entry in
the FILES.BBS or find the file in the directory. CONNMOVE
will assume that you moved the file and search all the other
directories (listed in the DF.CTL) for the file. If it does
not find the file, it assumes you deleted it and places it's
FILES.DIL entry in the first directory listed in the DF.CTL,
the TRASH directory. Since you deleted the file, CONNDOOR
assumes you don't want it uploaded again and it's entry into
the TRASH directory's FILES.DIL will prevent that. To remove
all reference to the file from the system, the FILES.DIL
entry can only be removed with the CONNEDIT program.
Moving files:
When an upload or download is identified during a file
transfer session, CONNDOOR goes out and searches the
FILES.DIL in each directory you have listed in the DF.CTL.
When you move files and descriptions from one directory to
another, the FILES.DIL file still reflects the files that
were there before you moved any files. When uploading, if
CONNDOOR finds the name in ANY FILES.DIL file, the upload
will be rejected. For downloading, the file must be listed
in the FILES.DIL ** AND ** be present in the directory. If
not, CONNDOOR reports the file as NOT FOUND.
The CONNMOVE program will search all the directories in the
DF.CTL list and compare the files in the FILES.DIL file with
what is actually in the directory. If it finds an entry in
the FILES.DIL that is not in the directory, it will search the
other directories for it. If it finds it (because you moved
it), it will move the FILES.DIL entry to the appropriate
directory keeping the file areas in "sync". If it doesn't
find the file, it assumes you deleted the file and moves the
FILES.DIL entry to the first directory listed in the DF.CTL
file (The TRASH directory) to prevent it from being uploaded
again.
The command to run CONNMOVE.EXE from a batch file (without
prompting for setup) is:
CONNMOVE -R
MANUALLY ENTERED FILES
If you manually enter a file and description into a FILES.BBS
file, it must also be "picked up" into the FILES.DIL file in
the appropriate directory. Just run the CONNSET.EXE program
as:
CONNSET
This will compare all the FILES.BBS files in the DF.CTL
directory list, with the FILES.DIL files and add any that are
not already there, picking up any new files you have entered
into the FILES.DIL file. The file must be in the directory!
(Except for TAPE and CDROM directories)
CDROM/TAPE - If CONNSET encounters a directory designated
as CDROM or TAPE (See TAPE or CDROM), if will update the
FILES.DIL file regardless of whether the file is actually in
the directory as long as the entry has been added to the
FILES.BBS.
CONNEDIT
CONNEDIT allows the user database, USERS.DIL, and the file
area support files, FILES.DIL files, to be edited. This
program is fairly self-explanatory. If you set a file's
"cost" point to 0, the file will be "FREE" and the downloading
of this file will not count against the user except for the
time the user took to download it.
The PURGE/DUP function will purge the FILES.DIL files of any
entries that have been deleted with CONNEDIT, and delete any
DUP entries in FILES.DIL file. If the program encounters two
entries for the same file and one entry contains the
uploader's name and the other does not, the program will keep
the entry with the uploader's data. This should be executed
periodically to prevent duplicate FILES.DIL entries and purge
deleted file entries.
"ORPHAN" FILES
Orphan files are files that appear in your upload directory
without any descriptions or entry into the system. Normally
this won't happen with the "blind" upload function enabled.
If you are running without this function and the user enters
that they are going to upload one thing, then upload a
different file, these files will be "orphaned" in your
upload directory. A log entry will notify you that this has
taken place. If a file is "blind" uploaded and it is a
duplicate, it will be automatically deleted. If a file is
"blind" uploaded and it is on the "DON'T WANT" list, CONNDOOR
will keep it but not credit the user with th upload.
In my BBS batch file, during the middle of the night
"housekeeping" routines I run the following:
--------------
CONNSET ;Picks up any files I've entered manually
MNM ;(OPTIONAL)
;The MidNightMover program, unpacks compressed
;files, scans for virus, repacks, logo stamps,
;dates and moves file to user upload directory.
CONNMOVE -R ;Moves FILES.DIL entries to keep file areas in
;"sync" after MNM has moved the files from my
;temporary upload directory to my user-available
;upload directory.
--------------
Gee, wasn't that EASY????
MULTIPLE CONFIGURATIONS
CONNDOOR and CONNFIG have the capability to identify the config
(default CONNDOOR.CFG) file and directory listing (default
DF.CTL) file in the commandline. This can allow you to run
various configurations, access plans, even different point
schemes by using different CFG and CTL files. It also
increases the confusion factor a BUNCH! The possibilities are
endless.
To use another CONNDOOR config file, -C is used.
To use another CONNDOOR directory listing -F is used.
Example:
To use a different config file called "ANOTHER.CFG", and a
different directory listing called "ANOTHER.CTL", you would
use-
CONNDOOR -U -FANOTHER.CTL -CANOTHER.CFG (for upload)
CONNDOOR -D -FANOTHER.CTL -CANOTHER.CFG (for download)
CONNFIG -CANOTHER.CFG (to edit ANOTHER.CFG)
****************
TAPE DRIVE UTILIZATION - |
On the first page of the CONNFIG display is the TAPE FETCH
ENABLE and TAPE COMMANDLINE entries.
The TAPE FETCH ENABLE has 3 different selections:
NOT USED -
Tape Drive not used.
ENABLE AFTER EACH REQUEST -
After the user has requested a file from the tape, the TAPE
COMMANDLINE will be executed to retrieve the file. This is
done for each selection. This is by far the easiest method to
use. The files can be in different storage areas on the tape
also. EXAMPLE: You can use a different volume on the tape
for each directory you have stored on the tape since each tape
access is separate.
ENABLE PRIOR TO TRANSFER - When a file is requested from the
tape, it's name is placed in a file called TAPE.DIL
(COMMANDLINE Variable %5) and the user is prompted for the
next file or action. When the user is done selecting his
files and elects to start the transfer, the tape drive
COMMANDLINE is executed ONE TIME. The files are restored to
the UPLOAD Directory and DOS calls are used to move the
files from the UPLOAD directory to their respective download
directories then deleted from the UPLOAD directory prior to
the transfer commencing. The directory you identify to
restore the files into MUST BE the UPLOAD directory. This
is sloppy, but was done to keep the code small. Multiple
volumes/areas of a tape CAN NOT be addressed with this mode.
All the "|" text lines in the DF.CTL must point to the same
area on the tape.
After each tape retrieval 2 minutes will be added to the
users time to compensate them for their patience while the
tape is accessing.
SETUP
Pick the directory you want to carry on tape and backup all
the files in the directory to the tape, including the
FILES.BBS and FILES.DIL (in case you ever want to restore the
directory to the hard drive). After the files have been
backed up to tape, delete all the program files, leaving
FILES.BBS and FILES.DIL in the directory. Use the info
provisions in the tape drive software to find out the volume
number of files you just stored. When converting over to
tape, take the section of your ALLFILES listing for that
directory and copy it over the FILES.BBS file in the
directory, AFTER you have copied the files up to tape.
CONNDOOR looks for the file size text after the file name in a
tape directory.
If no FILES.DIL existed before creation of the area, a
FILES.BBS text file must be created INCLUDING in the
description the size of the files. (See Example). After
creating the FILES.BBS and identifying the directory as a
TAPE directory, execute CONNSET and a FILES.DIL will be
created.
This is a normal file listing from the FILES.BBS.
K9FILES.ARJ [052] Files listing for the BBS
If the file is going to be on tape, the SIZE of the file must
be included in the text line after the file's name. (See
below)
K9FILES.ARJ 41791 [052] Files listing for the BBS
* For the sake of ease, we'll assume you are using the C:\MODEM
directory and it's Volume 1 on a COLORADO tape system.
The DF.CTL now must be modified to tell CONNDOOR to go to the
tape drive for the C:\MODEM directory. The "|" symbol
followed by a text string, one space after the directory
path tells CONNDOOR to go to tape. The text string should be
the identifier for the tape. In the case of the COLORADO tape
system, it's the volume number. For the IRWIN drives, it
might be the backup group's name. (EXAMPLE "BACK_UP.001")
This is converted to the commandline variable "%1".
************
The "|" symbol is what enables the TAPE interface in CONNDOOR.
************
EXAMPLE:
C:\TRASH
D:\GAMES
C:\MODEM |1
C:\WORD
When files are requested from that directory, CONNDOOR
identifies it as a tape directory, goes out to the tape and
restores the file to the original directory, then gets the
file's info and allows it to be downloaded. When the transfer
is complete, deletes the file. If the user ABORTS the
CONNDOOR program before the transfer, the file will remain
restored in the directory assuming the user will come back to
get it. These should occasionally be cleaned out if they
become a problem.
Since CONNDOOR checks the directory for the file FIRST and only
goes to the tape if it can't find the file, you can mix hard
drive available and tape available files in the same
directory.
In the tape mode, CONNDOOR also looks for a commandline switch
"-T". Only use this switch if you are using BIMODEM as one of
your protocols. The user must identify the files for download
before the download takes place. The "-T" switch causes a
message to be displayed to the user when they select BIMODEM
as a protocol informing them of that and giving them the
opportunity to do so instead of going right to BIMODEM. This
will allow any files stored on tape, to be retrieved from the
tape prior to starting the BIMODEM transfer.
The commandline for the COLORADO Tape backup software would
be:
"C:\TAPE\TAPE RESTORE %4 %2 /V=%1"
"C:\TAPE\TAPE" is the path and name of the tape drive software.
TAPE DRIVE COMMANDLINE VARIABLES
%1 String after the "|"
Whatever text is placed after the "|" in the DF.CTL file.
This string can be the volume number, name of the storage
group identifier like "BACKUP.001" or whatever your tape
software requires.
%2 File name selected by user. (just the name)
%3 Restore path (path to the directory to restore the file
into).
%4 Filename and path of file selected by user. (Combination
of %3 and %2)
%5 "TAPE.DIL" A text file list created of all the files
requested from the tape drive. (Should only be used with
the ENABLE PRIOR TO TRANSFER function).
WARNING!
When using the TAPE feature and CONNMOVE, the execution time on
CONNMOVE is very long! It could take several minutes to run. I
am working on it!
HINT:
I set the CONNMOVE program to point to a CTL file other than
DF.CTL. This file only contains the paths to the trash
directory, directory where my unscanned uploads go, and the
directory where user-available uploads go (NEW UPLOADS)
since these are the only directories affected during the
normal operation of my system. I use CONNMOVE in the manual
mode after I have moved a lot of files around and use the
DF.CTL.
I have used the TAPE mode extensively with the COLORADO JUMBO
tape system. I have also found that some of the tape drive
software will not run properly in a multitasking environment.
I have yet to find a way around it.
CDROM UTILIZATION:
The CDROM interface is very similar to the TAPE interface.
When a file has been requested from a directory on the Hard
Drive that is designated as a CDROM directory, CONNDOOR will
first search the Hard Drive directory for the file, and if
the file is not found, CONNDOOR will access the designated
CDROM partition for the file. When the file is located, it is
moved over to the Hard Drive directory and the user will be
able to download it. Upon completion of the transfer, CONNDOOR
will delete the file. Operation in this manner allows the
mixing of Hard Drive available and CDROM available files in one
directory. The FILES.BBS and FILES.DIL files reside in the
designated directory on the hard drive and are updated like a
normal file area. The "down side" of this strategy is that |
each file area you want the users to be able to access on the
CDROM must have it's own counterpart on your hard drive. |
There are many possibilities but I have not explored them |
since I do not have a CDROM. |
SETUP:
A CDROM directory is designated by a "?" after the Hard Drive
file directory followed by the path to the CDROM area where
the desired files are stored.
If the CDROM partition is E:\ and you wanted to list files from
the CDROM in the C:\MODEM directory, the example below shows
how it should appear in the DF.CTL.
EXAMPLE:
C:\TRASH
D:\GAMES
C:\MODEM ?E:\
C:\WORD
The FILES.BBS and FILES.DIL files are placed in the C:\MODEM
directory. The FILES.BBS and FILES.DIL files are prepared in a
similar fashion to the TAPE area FILES.BBS and FILES.DIL.
This is a normal file listing from the FILES.BBS.
K9FILES.ARJ [052] 12/92 Files listing for the BBS
If the file is going to be on CDROM, the SIZE of the file must
be included in the text line after the file's name. (See
below)
K9FILES.ARJ 41791 [052] 12/92 Files listing for the BBS
If you are using a CDROM and BIMODEM is offered for your users
to use, the "-T" switch should be used in the COMMANDLINE for
CONNDOOR so that the user is prompted to identify all of their
downloads prior to enabling BIMODEM so that the files may be
retrieved prior to the start of the BIMODEM transfer.
ONLINE OPERATION
When enabled from the BBS, CONNDOOR will display a rather run-
of-the-mill display screen with the standard sysop info at the
bottom and what the user sees at the top. The user will be
able to select their protocol then move on to select files.
The sysop can "key in" commands from the keyboard to help the
users and entering ESC will terminate CONNDOOR and return
the user to the BBS. No other "special" functions are
included.
FILE SEARCHING
I could write several pages on the inner-workings of CONNDOOR
and file searching but I will try to touch upon the important.
CONNDOOR ignore file extensions TOTALLY. This is one of the
ways CONNDOOR avoids duplication of files uploaded with
different compression styles. If "ABCD.ZIP" is listed for
upload, and "ABCD.ARJ" is already on the system, it will be
rejected (BIMODEM will allow it though). If you have already
have "dup" files on your system like the above example,
CONNDOOR will stop it's search at the first "ABCD" it
encounters.
DOWNLOADING
The prompting for downloading is pretty much self-explanatory.
WILDCARDS are a bit different under CONNDOOR. The WILDCARDing
methods used are not true WILDCARDs in a DOS sense. The
inclusion of a "*" into a file name causes CONNDOOR to find
any file with the selected text in the name.
Example:
Entering "AB*.ZIP" for download will return a "found" for -
ABCD.ZIP (Remember, CONNDOOR ignores file EXTENSIONS)
ABCD.GIF
DABC.ARJ
Searching for "*AB.ZIP" will return the same group as
"AB*.ZIP".
Searching for "AB.*" will only return a "found" for an EXACT
match of "AB". ("AB.ZIP" or AB.ARJ") Once again, file EXTENSIONS
are ignored.
CLOSING
Some of the CONNDOOR's features, or lack of features, are
radically different than with some other file transfer door
programs out there. I attempted to provide a door that would:
Require a MINIMUM of maintenance.
Take greater steps towards the prevention of the uploading
of undesirable or "dup" files or types of files, either by
"mystery" batch uploads or different file extensions.
Provide a way to use a Tape Drive to supplement online storage
Promote the use of BIMODEM
Provide more incentive to upload and reward the uploaders of
popular software for their efforts.
******
ACKNOWLEDGEMENTS
To the authors of the other fine programs mentioned in this
documentation, I apologize for not giving you each the
recognition you obviously deserve.
REGISTERING CONNDOOR
To register CONNDOOR, please see the CONNDOOR.REG doc for
details.
SPECIAL THANKS TO:
My wife for putting up with the all the hours of code
crunching.
(Brave Souls)
Dave Hallford of the CASA DE CRICKET BBS in Modesto, CA
Bill Winterholer of the GEMSTONE BBS in Groton, CT
John Skobrak of the THREE MILE ISLAND BBS in Charleston, SC
Mike Myers of the GENESIS BBS in San Jose, CA
As with all projects, this one started out small and turned
into a monster. The CONNDOOR system is quite complex and with
each increase in capability, the complexity and difficulty in
debugging goes up tremendously. If you encounter problems
with CONNDOOR please feel free to contact my BBS at 203-536-
1300 or NETMAIL 1:320/105. Your efforts will be recognized
and GREATLY appreciated.
CONNDOOR is FREQable from my BBS, 1:320/105 under "CONNDOOR".
---------------------
OTHER Software available (FREQable from 1:320/105):
MidNightMover (MNM) - Utility designed to handle compressed
files. Virus scanning, moving, converting, dating, logo
stamping etc. Designed to move FILES.BBS listings and
interface with CONNDOOR. Will also fill dates in for CONNDOOR
generated file descriptions.
MOVEIT!! (MOVEIT) - File are utility designed to allow batch
moving, deletion, and "orphan file pickup" for BBS systems
using the FILES.BBS format. Many features.
ENFORCER (ENFORC) - Multi-level BBS security level program
designed to allow a user to change between up to 5 different
security levels based on their file transfer ratio and posting
ratio. Fully configurable.
CONNSORT (CONNSORT) - Places FILES.BBS text files in
alphabetical order. Allows unlimited file directories and
FILES.BBS text files up to 1000 lines long with description
lines up to 300 characters long.