bbs/deb-mbse
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Initial revision

Browse Source
This commit is contained in:
Ken Bowley
2001-08-17 05:46:24 +00:00
commit 40420d900a
750 changed files with 177485 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

117
html/misc/dropfile.html Normal file
View File

@@ -0,0 +1,117 @@
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=ISO 8859-1">
<META http-equiv="Content-Style-Type" content="text/css">
<META name="author" lang="en" "content="Michiel Broek">
<META name="copyright" lang="en" content="Copyright Michiel Broek">
<META name="description" lang="en" content="MBSE BBS Manual">
<META name="keywords" lang="en" content="MBSE BBS, MBSE, BBS, manual, fido, fidonet, gateway, tosser, mail, tic, mailer">
<TITLE>BBS doors dropfiles.</TITLE>
<LINK rel=stylesheet HREF="../manual.css">
</HEAD>
<BODY>
<BLOCKQUOTE>
<h5>Last update 02-Feb-2001</h5>
<P>&nbsp;<P>
<H1>BBS doors dropfiles.</H1>
<P>
<h3>Dropfiles for Unix BBS systems.</h3>
<p>
Not all options that are available under DOS or OS/2 can be used with Unix
BBS systems and must be faked.
<p>&nbsp;<P>
<h3>DOOR.SYS format.</h3>
<P>
The door.sys format is a 52 lines ascii textfile, each line is terminated with
a cr/lf pair. In the setup it is possible to force the creation of MM-DD-YYYY
dates instead of the MM-DD-YY style. Newer doors sometimes need that.
<pre>
Line Description
----- -----------------------------------------------------------------
1 Port, 2 characters in DOS format, p.e. COM1
2 Effective Baudrate
3 Databits
4 Nodenumber, 1..9999
5 Locked baudrate
6 Screen display, Y=snoop on, N=snoop off. On Linux allways N.
7 Printer Y=on N=off
8 Page Bell Y=on N=off
9 Caller alarm Y=on N=off
10 Users first name and lastname
11 Users location
12 Voice/Home phone
13 Work/Dataphone
14 Password, empty if not available (stored coded).
15 Security level, 0..32768
16 Users number of calls
17 Users last call date MM-DD-YY
18 Seconds remaining this call
19 Time left in minutes
20 ANSI, "GR" is yes, otherwise ?
21 Screen length
22 User mode, always N
23 Always blank
24 Always blank
25 Subscription expire date MM-DD-YY
26 Users record number
27 Default protocol
28 Users total number of uploads
29 Users total number of downloads
30 Users daily download kilobytes total
31 Daily download kilobyte limit
32 Users date of birth MM-DD-YY
33 Path to users database files Cannot be used on Linux.
34 Path to message database files
35 Sysop first and last name
36 Users handle
37 Next event starting time or "none"
38 Error-free connection Y=Yes or N=No
39 Always set to N
40 Always set to Y
41 Text color as defined in setup 7 = gray.
42 Always 0
43 Last new files scan date MM-DD-YY
44 Time of this call HH:MM
45 Time of last call HH:MM
46 Always set to 32768
47 Number of files downloaded today
48 Total kilobytes uploaded
49 Total kilobytes downloaded
50 Comment stored in users record
51 Always set to 0
52 Total number of messages posted
</pre>
<P>&nbsp;<P>
<h3>DORINFOn.DEF dropfile.</H3>
<P>
The DORINFOn.DEF file is a 12 lines ascii textfile, each line terminated with
a cr/lf pair. All characters in the file are uppercase. The n in the filename
represents the current line number and will be between 1 and 9. Using number
1 seems always fine.
<pre>
Line Description
------ ------------------------------------------------------------------
1 System name
2 Sysop's first name
3 Sysop's last name
4 Port name, like COM1, COM2 etc. COM0 = local
5 Baudrate format: "19200 BAUD-R,N,8,1"
6 Always 0
7 Users firstname
8 Users lastname
9 Users location
10 Graphics mode: 0=no, 1=ANSI, 2=Avatar, 3=ANSI+Avatar
11 Security level, 0..32767
12 Time left in minutes
</pre>
<p>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BLOCKQUOTE>
</BODY>
</HTML>

331
html/misc/filefind.html Normal file
View File

@@ -0,0 +1,331 @@
<HTML>
<HEAD>
<TITLE>Implementation and Usage of FileFind Utilities.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: fsc-00xx
Version: 0.6
Date Aug 30, 1995
Title: Implementation and Usage of FileFind Utilities
Authors: Robert Williamson FidoNet#1:167/104.0 robert@ecs.mtlnet.org
Intro
A portion of the document is derived from information in
AllFix.DOC by Harald Harms @ 2:281/910
with additional sections from
FQuery.DOC by Robert Williamson @ 1:167/104
The MSdos program ALLFIX by Harald Harms first introduced the idea
of searching for files via echomail. The term applied to this function
is 'FileFind'. A FileFind system allows sysops, points and BBS users
to search for files by placing a message to 'ALLFIX' in an echo
designated for the purpose of finding files. All FTN sites running a
FileFind processor which is configured to scan that echo will reply to
that user if there any files matching his query. This system provides
a method for searching many FTN sites throughout the world, with a
single message.
FileFind programs work by either scanning through defined message
bases or scanning packets for defined AREA tagnames for messages to the
default name ALLFIX. All FileFind programs MUST respond to the name
ALLFIX, but may also respond to the name FILEFIND and the name of the
particular FileFind program in use or defined for the echo. The
FileFind program will process these messages, examining the Subject
field for search queries. If any valid query is found, the FileFind
program will search the sites files database for files matching the
users's query.
If the FileFind program finds any matches, it will generate a reply
containing a list of the files found, and some basic information ABOUT
the system posting the reply. When the user who initially wrote the
request reads the reply, he will then be able to decide if any of the
reported files meet his needs, and from the ABOUT included in the
reply, learn where and how he may get those files.
FileFind Query Message Structure
To: name_of_FileFind program
The message must be addressed to ALLFIX so that all FileFind programs
can respond. To use features specific to a particular FileFind
program, or to limit the responses to a particular platform, the
message should be addressed to that program's name. Some FileFind
programs will respond to more than two names.
Subject:
A space-separated list of file specifications, keywords or quoted
strings.
keyword - single word preceeded by a '/' with no intervening spaces,
must be at least 3 characters, not including the '/'.
a keyword search is in actually a substring search of the
site's filelist.
description - string enclosed in double-quotes,
if a single word, must be more than 3 characters.
filespec - single word, no spaces, no double-quotes or preceding /,
must be at least 3 characters, not including any wildcard
or pattern matching charcaters, such as '*'.
Messages addressed to ALLFIX must not have any embedded
pattern matching characters.
The minimum number of characters for description, keyword and
filespec queries is an implementation detail of the FileFind program.
These values should be configurable, but should never be settable to
values of less than 3.
Each implementation should allow the operator the ability to
configure a list of disallowed keywords.
NetMail Queries
Some FileFind programs may also have the ability to process file
search queries received as netmail and addressed to the name of the
particular FileFInd program with this capability. In this case, all
replies are via netmail also.
NetMail Commands
FileFind Netmail commands are identifed by a leading '%'.
Implementation of netmail commands is optional. If implemented,
compliant FileFind utilities should be able to process the following
minimum NetMail command set.
%HELP - netmail only, returns an extended help text for the
FileFind program, the ABOUT of the the site and a list
of MAGIC freqable names.
%ABOUT - netmail only, returns the ABOUT of the site and a full
or %MAGIC list of MAGIC names.
%NEWFILES - netmail only, returns the NEWFILES list of the site
or %NEW via netmail.
Extended NetMail Commands:
Implementation of the following netmail commands is optional and
not required for compliance with the FileFind NetMail Command set.
%REPORT <tagname>
- sends a configuration report for echo <tagname>
this allows an echo moderator to check if a site running
a FileFind utility is compliant with the rules of the
filefind echo.
%REQUEST <filename>
- if found, will place requested file on hold for remote
site
%UUREQUEST <filename>
- if found, and the filesize after uuencoding is less
than 60K, it will be sent as multiple netmail messages
The Site ABOUT
Obviously, a system that neither accepts file requests nor allows
users to download on their first call should not be responding to
FileFind messages. If there are any limitations for the caller to
acquire any of the files that the site has advertised as being
available in it's FileFind response, these limitations MUST be listed
in the reply. This information should be included in the ABOUT file
that the FileFind program user creates.
The site ABOUT should contain the following information. The
FileFind program implementor should instruct his users on these
requirements.
- sitename
- site operator's name
- complete phonenumber
- baud rate
- hours during which filerequests are accepted, if at all
- hours during which users can download
- conditions for file requests and user downloads
NOTE: the above information should be within the first 14 lines.
optional:
- a list a MAGIC names
- an indication if magic names are also available to terminal users.
Searching for Files and Creating Replies
The method used by the FileFind program to search for requests is
up to the implementor. However, if searching a list, the FileFind
program should confirm the actual existance of all files that match the
query specification.
The FileFind program should only process description strings,
filespecs or keywords that contain more than 3 valid characters and
should have configuration options to define greater minimum lengths on
a per-echo basis.
For filespecs, the wildcard character '*' IS considered a valid
specification as well as the '?' wildcard, but only the '?' is to be
counted as a character when determining the length of query. File
extensions are not necessary and any characters AFTER a '*' are to be
ignored. The FileFind program should be configurable so as to allow
replacement all of the file extensions with '.*' or '#?' dependant on
platform. This results in queries being independant of the various
archivers in use.
Replies
Replies created by FileFind utilities are expected to be in
compliance with the following FTN specifications:
FTS-0001 - packed message format
FTS-0009 - MSGID/REPLY
FSC-0046 - PID and tear line
In addition, a FileFind utility may use the FID: control line for
any information needed that cannot be put in a PID: without violating
that specification.
^AFID: ascii text CR
Must be less than 80 characters including ^A and terminating CR.
There are three ways in which the FileFind program can create replies:
- write the replies in the echo in which the query appeared.
- write the replies in an echo that has been specifically
designated for that purpose in the particular FTN or for
a gorup of echos in that FTN.
- reply via routed netmail.
Since each FTN site connected to a particular FileFind program area
is capable of creating an information reply, there is much concern as
to the amount of traffic that can be generated, FileFind program
developers must be sensitive to these concerns by providing the means
to their users to limit the traffic on a per-echo basis. For example,
various FileFind echos have rules limiting the size or number of
replies, or the length of the system information that may be included
in a reply.
Limiting replies
It is strongly suggested that some default limitations be built-in.
Limiting Site Header (ABOUT):
If the site's ABOUT, (the text that has been configured in order to
add the system's information and Magic names list to the reply), is
greater than 14 lines, the remainder should NOT be posted. A line
should be added to the response indicated this, and the user may be
invited to either Freq or download the MAGIC name's ABOUT or MAGIC, for
a full list of magic names. The FileFind program may optionally send
the full system information and magic name list via routed netmail.
Limiting Match List due to ambiguity of query:
If the list of matches (note: not the size of the message itself)
is greater than 32K, the FileFind program should post a message to the
user to indicate that his query may have been too ambiguous and perhaps
invite him to freq or download the MAGIC name FILES for a full list.
Splitting Match List into Multiple Messages:
If the list of matches is greater than 10K, it should be split into
multiple messages of no more than 8K. Although the backbone permits
messages up to 16K in length, 8K is a more readable size. Only the
first split message may contain the ABOUT information of the site.
Each message must be given both a unique Subject field (eg: prepended
by "Part n/n") and a unique MSGID:. This because some tossers may use
either or both for dupe detection.
Limiting Number of Split Messages:
If the number of messages is greater than the preset limit of the
echo, and the FileFind Program does not have an option to forward the
replies via netmail, the replies should be discarded and the user
informed that his request may have been too amibiguous.
NetMail Reply:
The FileFind program may have an option to forward all replies via
routed netmail, or to do so under certain conditions as outlined above.
Obviously, if the FileFind program can process netmail queries, it MUST
respond via netmail.
User NetMail Reply Request:
Alternativly the user can request a netmail reply for his echomail
query by preceeding the query with either "%" or "!".
eg;
Subject: % /fsc /fts
If the FileFind program does not support this feature, it must
ignore any echomail query message that has a "%" or "!" as the first
WORD of the Subject field.
Second Reply or Extended Response Request:
The FileFind site indicates availablility of Second Reply by
placing the string 'program_name 4d_address' in the From: field of the
message.
eg: FROM: FQUERY 1:167/104.0
When a user replies to a FileFind reply, the message will be to the
FileFind program @ {network address}. When processing the FileFind
conferences, the FileFind program will treat any message to itself that
includes the site address as a Second Reply Request.
If this feature is available, the FileFind program will include up
to a maximum of 15 files (maximum 12K match list) in it's replies. If
the user wants a more detailed listing, he simply replies to the
FileFind program's reply. Only the system that posted the original
reply will respond to that new request. This second, specific reply,
will contain up to 50 files (32K of matchlist) either including or
SKIPPING the first 15. These numbers may be replaced by byte limits in
some implementations.
No Second Reply in Designated Reply Echo:
The Designated Reply Echo method does not allow replies to be made,
because the FileFind program may not be permitted to scan a Designated
Reply Echo. The FileFind program should automatically report up to 50
files for any requests. Therefore, the traffic limitaion features may
be disabled for networks that require the FileFind program to reply in
a Designated Reply Echo, and disallow Second Reply in that echo.
Disable Local Messages:
The FileFind program must be able to to disable the processing of
local messages. What this means is that the FileFind program will not
process any messages generated on that FTN site, including messages by
the sysop using an offline reader, or by a site's BBS or off-line
reader users. This should NOT exclude messages from a site's points.
Limit by Age:
The FileFind program must be configurable so that the operator can
limit the age of an query message that is acceptable for processing.
This should be in number of days. The FileFind program may be
configured to process all the FileFind requests regardless of how old
they are. Age should never be greater than 365 days.
LinkMGR Support:
Implmentors may choose to support the LinkMGR proposal for netmail
queries and commands. In this proposal, the queries and commands do
not appear in the subject field but rather, in the the BODY of the
message. The subject field wil contain the LinkMGR password.
Use of the LinkMGR method allows the user to send multiple commands
to the fIleFind program.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

386
html/misc/fileid.html Normal file
View File

@@ -0,0 +1,386 @@
<HTML>
<HEAD>
<TITLE>FILE_ID.DIZ Information.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
FILEID.TXT v1.8 by Richard Holler [CIS 73567,1547]
Last Revision 05/05/94
This text file was prepared at the request of the ASP (Association of
Shareware Professionals), but the information contained in it may be of
value to any shareware author.
FILE_ID.DIZ INFORMATION
-----------------------
Basically, the FILE_ID.DIZ file is a straight ASCII text file, distributed
inside your distribution archive file along with your program files, which
contains a description of your program. This file will be used by most BBS
(Bulletin Board System) softwares for the online file description of your
file. We recommend that the FILE_ID.DIZ file be used in all of your
distribution archives.
This text file contains a description of the FILE_ID.DIZ file, as well as a
description of the recommended distribution archive format.
WHY SHOULD YOU USE FILE_ID.DIZ?
-------------------------------
The use of this file will insure that the online description of your
program will be in your own words (and who better to describe your program
than yourself?), and that it will remain the same no matter how many
different people upload your file to various BBS systems.
As more and more BBS software makes use of this file, you can be assured
that your own description will replace such online descriptions as "Cool
Program" or "OK utility, but needs better ..."
Please note that the ASP Hub Network, the Author Direct FDN (File
Distribution Network), and the majority of other electronic distribution
services *REQUIRE* that a valid FILE_ID.DIZ file be contained in your
submitted distribution archive. If your file doesn't contain a valid
FILE_ID.DIZ file, then it simply won't be distributed by these services.
Furthermore, most BBS sysops will not accept uploads of files which do not
contain a valid FILE_ID.DIZ file, so you automatically lose out on that
distribution as well.
DESCRIPTION:
------------
FILE_ID.DIZ was created by Clark Development for use with their PCBDescribe
utility, as a means for BBS callers to upload a file without having to
manually type in a file description. It also ensures that the online
description is always the same regardless of the number of different BBS
systems the file is posted on. It has since been accepted by the BBS
industry more-or-less as the "standard" file description source. (The
extension of "DIZ" actually stands for "Description In Zip").
NOTE: The FILE_ID.DIZ file *MUST* be named exactly that, and *NOT*
something like <filename>.DIZ. It will *ONLY* be used if it is named
FILE_ID.DIZ!
The FILE_ID.DIZ file is nothing more than a straight ASCII text file which
contains the full description of the archived file containing it. It is
used by most popular BBS software to describe your program, rather than
using the description supplied by the person that uploaded your file. It
should be placed *INSIDE* your distribution archive file.
The BBS software will "look" inside the archive file. If a FILE_ID.DIZ file
is found, it will replace any existing online file description with the
text contained in FILE_ID.DIZ. It is an excellent method for making sure
that your program files are described the way that "you" want them
described. Even sysops who's software can't automatically make use of the
FILE_ID.DIZ file have found it to be an excellent source for their manually
added file descriptions.
STRUCTURE:
----------
The file consists of straight ASCII text, up to 10 lines of text, each line
being no more than 45 characters long. It should *NOT* contain any blank
lines, any form of centering or formatting, or any Hi-ASCII or ANSI
characters. (i.e. it should ONLY contain alpha & numeric characters).
We recommended that it consist of 5 basic parts:
1. the proper name of your program
2. the version number
3. the "ASP" identifier (optional, for ASP members)
4. the description separator
4. the description
All of the above parts should be separated by a single "space".
PROGRAM NAME: To set it apart from the rest, it is recommended that you use
ALL CAPS for the program name.
VERSION NUMBER: The version number should be in the form of "v12.34".
ASP IDENTIFIER: If you are an ASP author, we recommend that an "<ASP>"
identifying mark be added after the version number, to identify your
product as an ASP-authored product.
DESCRIPTION SEPARATOR: To separate the actual description text, insert a
simple "-" (dash/minus) character after the ASP identifier (or version
number, if not using the ASP identifier), and in front of the description
text.
DESCRIPTION: You should attempt to FULLY describe your product, including
its most important functions and features. Be sure to include anything
which will separate your program from it's competition, and make the BBS
user want to download your file. Also try to include any hardware or
software requirements that your product may have.
You should try to use the first 2 lines of the text to give a basic
description of your program. This is helpful for sysops who's BBS software
limits them to less than 10 lines, 45 characters. Sysops who are limited to
using shorter descriptions can simply use the 1st two lines and truncate
the rest. Thus, you can basically still supply your own description for BBS
software which does not actually utilize the FILE_ID.DIZ feature.
The remaining lines of text can be used to elaborate on the programs
features, enhancements from the prior version, information concerning
multi-file sets. Please note that older versions of some BBS software can
only use 8 lines of text. It is advisable that you create your FILE_ID.DIZ
file so that the file can be truncated to various line lengths without
destroying it's usefulness.
EXAMPLE
-------
MY PROGRAM v1.23 <ASP> - A program which will
do anything for anybody. Will run in only 2k
of memory. Can be run from the command line,
or installed as a TSR. Completely menu-
driven. Version 1.23 reduces the previous 4k
memory requirements, and adds an enhanced
graphical user interface. Also, MY PROGRAM
now contains Windows and DESQview support.
Coming soon - an OS/2 version.
From Do-It-All Software, Inc. $15.00
MULTIPLE DISK INFO
------------------
Please note that if your distribution archive requires multiple archive
files, you should create a separate, specific FILE_ID.DIZ file for each
archive. This can be utilized to describe the various contents of each
archive, and to identify each disk in the set. For example, the FILE_ID.DIZ
file for disk #1 could contain:
"MY PROGRAM v1.23 <ASP> Program Executable
Files - Disk 1 of 2"
[followed by detailed description text]
while the FILE_ID.DIZ file for disk #2 could contain:
"MY PROGRAM v1.23 <ASP> Documentation Files -
Disk 2 of 2"
[followed by more detailed description text]
Optionally, you could also create a "complete" FILE_ID.DIZ file for the
first disk, which would fully describe the program in detail, and identify
it as Disk 1 of x. Then, for each remaining file in the set, simply include
the Program Name, version number, ASP identifier, and the disk number (i.e.
"MY PROGRAM v1.23 <ASP> Disk 2 of x").
ADDITIONAL INFO
---------------
Please don't be tempted to use fancy graphic or ANSI sequences in the
FILE_ID.DIZ file, as most BBS software will not allow this, and will render
your FILE_ID.DIZ file useless. Also, don't be tempted to simply copy your
program description file to FILE_ID.DIZ. Attempting to "format" your
FILE_ID.DIZ file (i.e line centering, right & left justification, etc) will
also cause unexpected results, especially for BBS software which re-formats
descriptions to other than 10line/45char.
Fred Hill <ASP> has written a freeware utility which interactively creates
a valid FILE_ID.DIZ file. The file is called DIZGEN.ZIP and can be found on
CompuServe (GO IBMBBS, Library 2) as well as on many fine BBS systems. I
highly recommend that you download a copy of this wonderful utility for
creating your FILE_ID.DIZ files.
<*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*>
The following is a recommendation for the structure and contents of
distribution archives prepared for use on BBS systems.
DISTRIBUTION DISK RECOMMENDATIONS
---------------------------------
The following are recommendations for preparing your program files for
distribution to Bulletin Board Systems (BBSs) via the ASP's distribution
services, as well as other methods.
Two varieties of program files are defined here:
1) Program files which utilize an "install" utility and self-extracting
program archives (later referred to as "Author-Installed Programs").
2) Programs files which do not use install utilities or self-extracting
archives (later referred to as "User-Installed Programs").
AUTHOR-INSTALLED PROGRAMS:
--------------------------
These programs require a bit more work from the author, but will eliminate
many user mistakes, especially in programs which require complicated
setups.
Most "installation" utility programs will make use of program files which
have been "archived" into Self-Extracting (SFX) archives. We will attempt
to define which files should be contained in the Self-Extracting archives,
and which files should not.
1. Files which should be contained in the self-extracting program file
archive:
a. All program-specific executable files.
b. Any required configuration and/or data files required by the
program.
c. Program documentation files. Optionally, these may be left
outside of the self-extracting archive, in order to allow
them to be viewed/read by the various archive viewing utlities.
d. Any other program-specific files that are required for the
operation of the program.
2. The files described above should be compiled into a self-extracting
archive file, which will then be extracted by the install utility.
NOTE: the author is required to abide by any distribution requirements
specified by the archive utility author, and to obtain any required
distribution rights necessary. Please check to see if distribution rights
are required for your archive utility choice.
3. Files which should NOT be contained in the self-extracting program file
archive:
a. The install utility itself (obviously).
b. The FILE_ID.DIZ file. (described in detail in the section
preceding this one)
c. Any distribution/information files, such as VENDOR.TXT,
SYSOP.TXT, etc.
d. Any description or information file, such as DESCRIBE.TXT.
e. A user file (such as README.1ST), which should explain how
to use the install utility, what the user should expect
during the installation, and any preparation that the user
should make prior to the installation. This file might also
contain a brief description of your program, in case the user
is able to read the documentation files in the distribution
archive prior to downloading (many BBS systems offer this
ability to the user).
4. The actual distribution archive file (described below) should then
contain the install utility, the self-extracting program archive, and the
files described in #3 above.
USER-INSTALLED PROGRAMS:
------------------------
This type of distribution archive is much simpler than the Author-Installed
variety. It should simply be an archive file, containing all of the files
for the program described above.
Since this type of program requires the user to do all of the installation
manually, it should contain very specific and detailed information
regarding the installation requirements (such as INSTALL.TXT).
THE DISTRIBUTION ARCHIVE FILE:
------------------------------
The actual distribution archive file should merely be an archive file
containing the files described above. For BBS distribution, this archive
should be of the standard archive format, and -NOT- a self-extracting
archive. Many sysops will not allow self-extracting archives, and most BBS
software will not allow self-extracting archives to be uploaded.
There are many popular archive utilities available, such as PKZIP, LHA,
LHARC, ARJ, etc. Most BBS systems are capable of handling archives in
virtually any format. However, you should be aware that most BBS systems
will convert your archive format to the format of choice by the sysop. By
following the methods described above, this conversion process should not
affect your program, or any self-extracting files which are contained
within your distribution archive file.
You should also retain the default archive file extension defined by the
archive utility. For example, PKZIP uses a ".ZIP", LHARC uses "LZH", etc.
Changing the file extension may cause the BBS software to delete your file
because it doesn't recognize the format.
For the actual filename for your distribution archive, it is recommended
that the program filename be limited to 6 characters to represent the
program's name (i.e. MYPROG could represent "My Program"). This should be
followed by 2 numeric digits which will represent the version number of
your release. Even if this is your initial release it should include the
version number in the filename (i.e. MYPROG10.ZIP would indicate the
program called "My Program" version 1.0).
Please note that CompuServe limits filenames to only 6 characters. By
limiting the file "name" to 6 characters, you will easily be able to rename
the archive for CompuServe uploading by simply removing the 2-digit version
identifier, to make the file compatible with CompuServe libraries.
By including the 2-digit version number in the archive filename, it will be
very easy for both the user and the sysop (and yourself) to identify older
versions of your program.
MULTIPLE DISTRIBUTION ARCHIVES
------------------------------
At one time, it was recommended that your final distribution archive not be
larger than 350k, so that it would fit on a single 360k floppy disk and
still leave room for any distribution files necessary for Disk Vendors.
(i.e. Disk Vendors will often include their own GO.BAT file, or other
various small files to help their customers install the software). This
limitation is slowly falling by the wayside as more and more computer
systems have 3.5" floppy disk drives as standard.
If your program is large enough to require more than one distribution
archive, it is recommended that your filename be limited to 5 characters
rather than 6 as described above. Following the 5-character name should be
the same 2-digit version number. Then, append a single "letter" to identify
the disk (i.e. MYPGM10A.ZIP, MYPGM10B.ZIP, etc.). For uploading to
CompuServe, these filenames may then be shortened to 6 characters by
removing the version identifiers (i.e. MYPGMA.ZIP, MYPGMB.ZIP). However,
for CompuServe it is recommended that you simply create a single
distibution file, and eliminate the multi-part file set.
If your program requires multiple distribution archives, -BE SURE- to
create separate FILE_ID.DIZ files for each distribution archive. Also, each
FILE_ID.DIZ file should contain disk number information pertaining to each
individual archive (i.e. Disk 1 of 3, Disk 2 of 3, etc.).
THE DISTRIBUTION DISK
---------------------
It is recommended that your distribution disk simply contain a ZIPd version
of your product. However, If you choose to supply "unarchived" files on a
distribution disk for Disk Vendor use, it is _VERY_ important that you
specify in your documentation a suggested archive filename, so that BBS
sysops can create archived files with the proper author-specified
filenames. This information should be contained in your SYSOP.TXT (or
VENDOR.TXT) file. If you don't supply a suggested archive file name, the
sysops will be forced to create the name themselves, thus you may end up
with thousands of versions of your products on BBS systems all over the
world, but all with different filenames.
Please note that the ASP Hub Network, and nearly every other electronic
distribution service *REQUIRE* that your files be submitted as an archived
file, using the ZIP format. Also note that many BBS sysops will not go to
the trouble of ZIPing your unarchived files for you. If you don't supply
them with an archived distribution version of your product, it might not
get distributed by BBSs.
If you supply your own disk labels, it is recommended that the ASP logo, or
at least the initials "ASP" be included on the label, so that anyone can
immediately identify your disk as an ASP member's software.
SUMMARY
-------
Your distribution disk should now be ready to submit to the various BBSs,
distribution services, and Disk Vendors.
You may choose to create a separate distribution disk for use by BBSs and
Disk Vendors. However, if you follow the above steps in preparing your
distribution archive file, a separate "Disk Vendor" disk is probably not
necessary. The majority of disk vendors will be able to accept your
distribution file/disk if it is prepared in the above described format.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

98
html/misc/ftpserver.html Normal file
View File

@@ -0,0 +1,98 @@
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=ISO 8859-1">
<META http-equiv="Content-Style-Type" content="text/css">
<META name="author" lang="en" "content="Michiel Broek">
<META name="copyright" lang="en" content="Copyright Michiel Broek">
<META name="description" lang="en" content="MBSE BBS Manual">
<META name="keywords" lang="en" content="MBSE BBS, MBSE, BBS, manual, fido, fidonet, gateway, tosser, mail, tic, mailer">
<TITLE>Howto setup an FTP server to work with MBSE BBS.</TITLE>
<LINK rel=stylesheet HREF="../manual.css">
</HEAD>
<BODY>
<BLOCKQUOTE>
<h5>Last update 06-Jun-2001</h5>
<P>&nbsp;<P>
<H1>How to setup an FTP server to work with MBSE BBS.</H1>
<P>
In order to let MBSE BBS and your FTP server to both function together you must
organize a special file structure. Note that even if you don't setup an FTP
server you must still create a structure like this for the fidonet mailer,
if you don't, <strong>mail and files will get lost!</strong>
Note that this description is written for wu-ftpd, on your distribution there
may be another ftpd installed. <font color=red><u>Don't use mbftpd yet!</u></font>
<P>
<H4>The filestructure I used is as follows:</H4>
<PRE>
/var/spool/mbse/ftp/pub/dos_util/dos_4dos - Public download areas
| | | /dos_disk
| | | /dos_file
| | /virnet/mcafee
| | /win16
| | /win32
| /bin - FTP bin directory
| /etc - FTP etc directory
| /incoming - FTP public upload.
/mail/out - Your default outbound
| /out.009 - Outbound Zone 9
| /inbound - Inbound directory
/raonly/upload - Non-public download areas
| /sysop
| /logfiles
/tic_queue - Queue for .tic files.
</PRE>
In order to give DOS style names for fidonet sessions you must set the
DOS path and Unix path in <strong>mbsetup</strong> (1.3.11 and 1.3.12) to
<strong>"m:"</strong> and <strong>"/var/spool/mbse"</strong>. Note that to get
forwarding of .tic files to work the <strong>tic_queue</strong> must be a
subdirectory of "/var/spool/mbse" too. You could actually use any drive letter for
the DOS path.
<P>
This means that a fidonet file attach from the dos_4dos public download
directory shall get the subject "M:\FTP\PUB\DOS_UTIL\DOS_4DOS\COMMAND.ZIP".
<P>
As you can see, anonymous ftp users can't get to the mail, non-public
downloads etc. Normally, your BBS users have unix accounts and will be able
to do a ftp login and access any directory on your system. Because the bbs
users have <b>mbsebbs</b> as their shell and this shell is not in the file
<b>/etc/shells</b> the ftp daemon will not let the bbs users in. So even
your own bbs users must login as anonymous to get files from the ftp server.
<P>
Note the following directory permissions MUST BE SET!!!!::: See also
the man pages for the DARPA ftpd server.
<P>
<PRE>
Directory owner group mode perms
------------------------------- ----- ----- ---- ----------
/var/spool/mbse mbse bbs 0755 drwxr-xr-x
/var/spool/mbse/ftp root wheel 0555 dr-xr-xr-x
/var/spool/mbse/ftp/bin root wheel 0555 dr-xr-xr-x
/var/spool/mbse/ftp/bin/ls root bin 0111 ---x--x--x
/var/spool/mbse/ftp/etc root root 0555 dr-xr-xr-x
/var/spool/mbse/ftp/etc/passwd root root 0444 -r--r--r--
/var/spool/mbse/ftp/etc/group root root 0444 -r--r--r--
/var/spool/mbse/ftp/pub mbse bbs 0775 drwxrwxr-x
/var/spool/mbse/ftp/incoming ftp users 0755 drwxr-xr-x
</PRE>
Note that all subdirectories under ../pub also must be owned by <strong>mbse
</strong> and group <strong>bbs</strong> and have at least mode 775 as long
as it are real bbs subdirectories. The bbs will maintain these directories
automatic and must have the rights to do so.
<P>
In the /var/spool/mbse/ftp/etc/group file, add the group bbs so that your directory
listings give the proper groupname instead of a number.
<P>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BLOCKQUOTE>
</BODY>
</HTML>

46
html/misc/index.htm Normal file
View File

@@ -0,0 +1,46 @@
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=ISO 8859-1">
<META http-equiv="Content-Style-Type" content="text/css">
<META name="author" lang="en" "content="Michiel Broek">
<META name="copyright" lang="en" content="Copyright Michiel Broek">
<META name="description" lang="en" content="MBSE BBS Manual">
<META name="keywords" lang="en" content="MBSE BBS, MBSE, BBS, manual, fido, fidonet, gateway, tosser, mail, tic, mailer">
<TITLE>Miscellaneous Documents</TITLE>
<LINK rel=stylesheet HREF="../manual.css">
</HEAD>
<BODY>
<BLOCKQUOTE>
<h5>Last update 02-Feb-2001</h5>
<P>&nbsp;<P>
<h1>Miscellaneous Documents</h1>
<h3>Introduction</h3>
<P>
This is an overview of used unofficial documents for the development of the
MBSE BBS package.
<P>
Michiel Broek.
<P>
<hr>
<h3>Documents</h3>
<ul>
<li><a href="filefind.html">Implementation and Usage of Filefind Utilities, R.Williamson</a>
<li><a href="ipmailer.html">Integration of IP-Nodes in the nodelist, L.Behet</a>
<li><a href="fileid.html">FILE_ID.DIZ Information, R.Moller</a>
<li><a href="ftpserver.html">How to setup an FTP server with MBSE BBS, M.Broek</a>
<li><a href="jam.html">JAM Message Base Proposal, J.Homrighausen</a>
<li><a href="outbound.html">Binkley style mailer outbound for MBSE BBS, M.Broek</a>
<li><a href="semafore.html">Semafore files for MBSE BBS, M.Broek</a>
<li><a href="usleep.html">System load and usleep() code, M.Broek</a>
<li><a href="dropfile.html">BBS doors dropfiles, M. Broek</a>
</ul>
<HR>
<A HREF="../index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Index" Border="0" width="33" height="35">Back to Index</A>
</BLOCKQUOTE>
</BODY>
</HTML>

172
html/misc/ipmailer.html Normal file
View File

@@ -0,0 +1,172 @@
<HTML>
<HEAD>
<TITLE>Integration of IP-Nodes in the nodelist.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Publication: FSP-????
Revision: 1
Title: Integration of IP-Nodes in the nodelist (FTS-0005)
Author: Lothar Behet, 2:2446/301
Revision Date: 25 October 1998
Expiry Date:
----------------------------------------------------------------------
Contents:
1. Required fields according to FTS-0005, basic flags for ip-nodes
2. Optional extensions
3. Addendum
----------------------------------------------------------------------
1. Description of the nodelist format
--------------------------------------
Every node entry contains the following 8 fields:
keyword,node_number,node_name,location,sysop_name,
phone_number,baud_rate,flags
Certain fields have defined values according to FTS-0005.
1.1. Implementation for IP-connectivity
Because of the limited characterset in the phone_field and
to avoid any misinterpretion by conventional dialing, the
ip-specific address-information is entered in another field
and there are additional flags required.
1.1.1. Field #1 (keyword) is PVT for an ip-only node without
conventional phone number related connectivity. In this
case, the phone field contains "-Unpublished-" according
to FTS-0005.
1.1.2. Field #2 (node_number) contains the node number within his
net and zone.
1.1.3. Field #3 (node_name) is used for the FQDN (Fully Qualified
Domain Name) or the ip-address.
1.1.4. Field #4 (location) contains the geographical location of
the node. While some nets/regions cannot supply their
ip-only nodes with a adequate link, these nodes may be
collected in a seperate net or region, until their original
net/region support additional ip-connectivity. This special
net/region is definitely a temporary solution for routing
within a region or zone!
1.1.5. Field #5 (sysop_name) represants the name of the system
operator.
1.1.6. Field #6 (phone_number) contains the phone_number for
conventional connectivity. In case of an ip-only node
it must contain "-Unpublished-".
1.1.7. Field #7 (baud_rate) contains the maximum baud rate for
conventional connectivity or 300 in case of an ip_only node.
1.1.8. Field #8 (flags) represents operational definitions for the
node.
Note that these are user flags.
The ip-flags consist of two parts:
A basic transport and an optional non-standard port,
seperated by a colon.
The default port may be omitted, but is listed as optional
parameter in this document. In some cases, two flag names
are mentioned:
The second one is supported by some software nowadays, but
these values may conflict with other programs, which not
completely decode the length of each individual flag (i.e.
TELN conflicts with the T-flag for online-time)
Additional flags for ip-nodes are:
1.1.8.1. IBN[:24554] (Argus: BND[:24554])
BinkP protocol
1.1.8.2. IFC[:60179]
Raw protocol as used by ifcico
1.1.8.3. ITN[:23] (Argus: TEL[:23])
Telnet protocol. Some variants of ifcico support Telnet
on port 60177, which should be added as additional flag
ITN:60177.
1.1.8.4. IVM[:3141]
Vmodem protocol
1.1.8.5. IP
General flag for special protocol specifications, if the
flags conforming to 1.1.8.1. to 1.1.8.4. are not relevant.
1.1.9. Comments on the proposed nodelist flags
The additional flagnames in () are supported at this moment
by Argus, based on the use in z2r50. But the TEL[NET]-flag
stays in conflict with the generally in all zones and
regions used T-flag (online time according to FSC-0062).
2. Optional extensions for future use
--------------------------------------
While the above mentioned flags (1.1.8.1 to 1.1.8.4) define a
minimum set of operational flags for ip-nodes, several additions
are already foreseeable at this moment.
2.1. Additional sessions_handshake parameters
There is at least one program, which supports several
transport protocols according to chapter 1.1.8. on a
single port. If other programs should imitate this habit,
then the following extension to the flag suite 1.1.8.
(transport[:port[:handshake]])is advised:
2.1.1. FTS-0001 session handshake: 1
2.1.2. Yoohoo session handshake : Y
2.1.3. EMSI sessions handshake : E
2.1.4. BinkP sessions handshake : B
2.2. Non-handshaking protocols
While the definitions until this chapter describe direct
handshaking sessions with optional password authentification,
there are several other methods for the tunneling of fidonet
data via the internet available.
The setup of these connections does not rely on the nodelist
(at this moment of writing), but we can think of standard
setup procedures to use the nodelist for configuration of
this additional transport methods.
Therefore the following flags 2.2.1. to 2.2.4. are advised
for at least informational purpose.
2.2.1. IFT
FTP (File Transfer Protocol)
2.2.2. ITX
TransX, an Email based variant
2.2.3. IUC
Uuencoded packet (one packet per message)
2.2.4. IEM
Email based (generally, without exact specification at
this moment)
3. Addendum
------------
This proposal is based on a maximum compatibility to generally used
definitions and standards within the Fidonet community.
Future developments might make additions necessary, if they can not
be expressed with the existing set of flags as defined by this FSP.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

638
html/misc/jam.html Normal file
View File

@@ -0,0 +1,638 @@
<HTML>
<HEAD>
<TITLE>JAM Message Base Proposal.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Filename....: JAM-001
Rev.........: 001
Dated.......: 93-07-01
Status .....: Released
Subject.....: JAM message base proposal
Author......: Joaquim Homrighausen
Co-Authors..: Andrew Milner, Mats Birch, Mats Wallin
---------------------------------------------------------------------
JAM(mbp)
The Joaquim-Andrew-Mats Message Base Proposal
---------------------------------------------------------------------
Copyright 1993 Joaquim Homrighausen, Andrew Milner,
Mats Birch, Mats Wallin.
ALL RIGHTS RESERVED.
---------------------------------------------------------------------
=====================================================================
Restrictions
---------------------------------------------------------------------
JAM may be used by any developer as long as these specifications are
followed exactly. JAM may be used free-of-charge by any developer
for any purpose, commercially or otherwise.
This document may be freely copied and distributed, but must NEVER be
distributed in a modified form. If you have an enhancement request,
please contact the author of this document; do not change it
yourself.
All applications that support JAM must include one of the following
notices in their documentation and somewhere in the product's credit
section:
"JAM(mbp) - Copyright 1993 Joaquim Homrighausen, Andrew Milner,
Mats Birch, Mats Wallin.
ALL RIGHTS RESERVED."
or
"This product uses the JAM(mbp) API -
Copyright 1993 Joaquim Homrighausen, Andrew Milner, Mats Birch,
Mats Wallin. ALL RIGHTS RESERVED."
No organization, company, person, entity, or other being may impose
any fees for any reason for providing this document or the
accompanying API. This document and the accompanying API may not be
sold or otherwise transferred for personal or company gain under any
circumstances.
=====================================================================
Definitions and general notes
---------------------------------------------------------------------
CURRENTREV 1
JAM The JAM message base format.
CRC Cyclic Redundancy Check. All CRC values
calculated on strings must assume that the
data within the string has been converted
to lowercase (A-Z = a-z).
CRC-32 32-bit CRC (as used in the Zmodem file
transfer protocol) value. The polynom for
a CRC-32 is edb88320H and the CRC-32 seed
is -1L (ffffffffH).
uchar Unsigned 8-bit value
ushort Unsigned 16-bit value
ulong Unsigned 32-bit value
UNIX date An ulong representing the number of seconds
since midnight, January 1, 1970. UNIX-style
dates is the only form of time stamps used
in JAM (1).
Message # The physical record number within the index
file is used as a message number. The
lowest message number is one (1) and the
highest message number is 4294967295
(ffffffffH).
FTN FidoNet Technology Network
FTS FidoNet Technical Standard
(1) All timestamps created locally (i.e. those not imported from
other systems) are stored in local time.
=====================================================================
Files
---------------------------------------------------------------------
Each conference is made up from four files. How and where these files
are stored and named is implementation dependant. The only file with
a fixed minimum size is the .JHR (header data) file. It has a 1024-
byte block used to hold information about a specific message area as
described later.
filename.JHR - Message header data
filename.JDT - Message text data
filename.JDX - Message index
filename.JLR - Lastread information
A future revision of JAM may also include a file that holds the
following three items:
- The highest assigned user number
- The last generated message ID
- A global conference list with the conference name, description,
and physical location of the message base.
=====================================================================
.JHR file header
---------------------------------------------------------------------
Below is the format of the 1024-byte record at the beginning of all
.JHR files. The first actual message header starts at offset 1024 in
the .JHR file.
FixedHeaderInfoStruct:
ulong Signature; // <J><A><M> followed by <NUL>
ulong datecreated; // Creation date
ulong modcounter; // Update counter
ulong activemsgs; // Number of active (not deleted) msgs
ulong passwordcrc; // CRC-32 of password to access
ulong basemsgnum; // Lowest message number in index file
uchar RESERVED[1000]; // Reserved space
end;
MODCOUNTER must be incremented and updated on disk each time an
application modifies the contents of the message base. When it
reaches ffffffffH, it wraps to zero.
---------------------------------------------------------------------
BaseMsgNum Lowest message number in index file
---------------------------------------------------------------------
This field determines the lowest message number in the index file.
The value for this field is one (1) when a message area is first
created. By using this field, a message area can be packed (deleted
messages are removed) without renumbering it. If BaseMsgNum contains
500, the first index record points to message number 500.
BaseMsgNum has to be taken into account when an application
calculates the next available message number (for creating new
messages) as well as the highest and lowest message number in a
message area.
---------------------------------------------------------------------
????????.JHR Message headers
---------------------------------------------------------------------
The .JHR file contains none or more Header records. Each record
define one message and contains information about the message and its
text (if any). The Header record is of variable length. The layout of
the Header record follows.
MessageHeader:
MessageFixedHeader:
ulong Signature; // <J><A><M> followed by <NUL>
ushort Revision; // Revision level of header (1)
ushort ReservedWord; // Reserved for future use
ulong SubfieldLen; // Length of subfields (2)
ulong TimesRead; // Number of times message read
ulong MSGIDcrc; // CRC-32 of MSGID line (3)
ulong REPLYcrc; // CRC-32 of REPLY line (3)
ulong ReplyTo; // This msg is a reply to..
ulong Reply1st; // First reply to this msg
ulong Replynext; // Next msg in reply chain
ulong DateWritten; // When msg was written
ulong DateReceived; // When msg was read by recipient
ulong DateProcessed;// When msg was processed by tosser/
// scanner
ulong MessageNumber;// Message number (1-based)
ulong Attribute; // Msg attribute, see "Msg Attributes"
ulong Attribute2; // Reserved for future use
ulong Offset; // Offset of text in ????????.JDT file
ulong TxtLen; // Length of message text
ulong PasswordCRC; // CRC-32 of password to access message
ulong Cost; // Cost of message
end;
SubField1 // Extra fields as defined below
.
.
SubFieldXX
end;
(1) This field is intended for future revisions of the specifications
to allow the use of a different fixed-length binary message
header. The current revision level is one (1).
(2) The SubfieldLen field is set to zero (0) if the header does not
have any subfield data. I.e. the length of the binary header is
not included in this field.
(3) When calculating the CRC-32 of the MSGID and REPLY lines, the
text ^aMSGID: and ^aREPLY: should be removed as well as all
leading and trailing white space characters.
The SubField structure is made up of an ID, a length specifier, and
a block of data. Zero or more subfields may follow the fixed-length
binary header. SubFields are not stored in any specific order and
are not terminated by any specific character unless otherwise
specified.
SubField:
ushort LoID; // Field ID, 0-65535
ushort HiID; // Reserved for future use
ulong datlen; // Length of buffer that follows
uchar Buffer[datlen]; // DATLEN bytes of data
end;
---------------------------------------------------------------------
Defined LoID codes
---------------------------------------------------------------------
ID=0, Name=OADDRESS
A network address. This is used to specify the originating address.
More than one OADDRESS field may exist. DATLEN must not exceed 100
characters. For a FidoNet-style address, this field must follow the
ZONE:NET/NODE.POINT@DOMAIN format where .POINT is excluded if zero
and @DOMAIN is excluded if unknown.
ID=1, Name=DADDRESS
A network address. This is used to specify the destination address.
More than one DADDRESS field may exist (e.g. carbon copies). DATLEN
must not exceed 100 characters. For a FidoNet-style address, this
field must follow the ZONE:NET/NODE.POINT@DOMAIN format where .POINT
is excluded if zero and @DOMAIN is excluded if unknown.
ID=2, Name=SENDERNAME
The sender (author) of the message. DATLEN must not exceed 100
characters.
ID=3, Name=RECEIVERNAME
The recipient of the message. DATLEN must not exceed 100 characters.
ID=4, Name=MSGID
Used to store the message identification data. All data not relevant
to the actual ID string, including leading and trailing white space
characters should be removed. DATLEN must not exceed 100 characters.
ID=5, Name=REPLYID
Used to store the message reply data. All data not relevant to the
actual reply string, including leading and trailing white space
characters should be removed. DATLEN must not exceed 100 characters.
ID=6, Name=SUBJECT
The subject of the message. DATLEN must not exceed 100 characters.
Note that this field may not be used for FidoNet-style file attaches
or file requests.
ID=7, Name=PID
Used to store the FTN PID kludge line. Only the actual PID data is
stored and ^aPID: is stripped along with any leading and trailing
white space characters. DATLEN must not exceed 40 characters.
ID=8, Name=TRACE
This is also referred to as ^aVia information in FTNs. It contains
information about a system which the message has travelled through.
The format of the field is <YYYYMMDDHHMMSS><Network address> where:
YYYY is the year (1992-9999)
MM is the month (01-12)
DD is the day (01-31)
HH is the hour (00-23)
MM is the minute (00-59)
SS is the second (00-59)
The timestamp is stored in ASCII (0-9) characters. The network
address is the address of the system. It is expressed in ASCII
notation in the native format of the forwarding system.
ID=9, Name=ENCLOSEDFILE
A file attached to the message. Only one filename may be specified
per subfield. No wildcard characters are allowed. If this subfield
is present in a message header, the ATTRIBUTE must include the
MSG_FILEATTACH bit.
ID=10, Name=ENCLOSEDFILEWALIAS
Identical to ENCLOSEDFILE with the exception that the filename is
followed by a <NUL> (00H) and an alias filename to be transmited to
the remote system in place of the local name of the file.
ID=11, Name=ENCLOSEDFREQ
A request for one or more files. Only one filemask may be specified
per subfield. If the filemask contains a complete path, it is to be
regarded as an update file request. If this subfield is present in a
message header, the ATTRIBUTE must include the MSG_FILEREQUEST bit.
To indicate that a password is to be transmitted along with the
request, a <NUL> (00H) character followed by the password is
appended. E.g. SECRET*.*<NUL>MYPASSWORD.
ID=12, Name=ENCLOSEDFILEWCARD
One or more files attached to the message. Only one filename may be
specified per subfield. Wildcard characters are allowed. If this
subfield is present in a message header, the ATTRIBUTE must include
the MSG_FILEATTACH bit.
ID=13, Name=ENCLOSEDINDIRECTFILE
One or more files attached to the message. The filename points to an
ASCII file with one filename entry per line. If alias filenames are
to be used, they are specified after the actual filename and
separated by a <NUL> (00H) character, e.g. C:\MYFILE.LZH<NUL>NEWS.
Wildcard characters are not allowed.
ID=1000, Name=EMBINDAT
Reserved for future use.
ID=2000, Name=FTSKLUDGE
An FTS-compliant "kludge" line not otherwise represented here. All
data not relevant to the actual kludge line, including leading and
trailing white space and ^A (01H) characters should be removed.
DATLEN must not exceed 255 characters. The FTS kludges INTL, TOPT,
and FMPT must never be stored as separate SubFields. Their data must
be extracted and used for the address SubFields.
ID=2001, Name=SEENBY2D
Used to store two-dimensional (net/node) SEEN-BY information often
used in FTN conference environments. Only the actual SEEN-BY data is
stored and ^aSEEN-BY: or SEEN-BY: is stripped along with any leading
and trailing white space characters.
ID=2002, Name=PATH2D
Used to store two-dimensional (net/node) PATH information often used
in FTN conference environments. Only the actual PATH data is stored
and ^aPATH: is stripped along with any leading and trailing white
space characters.
ID=2003, Name=FLAGS
Used to store the FTN FLAGS kludge information. Note that all FLAG
options that have binary representation in the JAM message header
must be removed from the FLAGS string prior to storing it. Only
the actual flags option string is stored and ^aFLAGS is stripped
along with any leading and trailing white space characters.
ID=2004, Name=TZUTCINFO
Time zone information. This subfield consists of four mandatory
bytes and one optional. The first character may be a plus (+) or a
minus (-) character to indicate a location east (plus) or west
(minus) of UTC 0000. The plus character is implied unless the first
character is a minus character. The following four bytes must be
digits in the range zero through nine and indicates the offset in
hours and minutes. E.g. 0100 indicates an offset of one hour east of
UTC.
---------------------------------------------------------------------
Message attributes
---------------------------------------------------------------------
MSG_LOCAL (0x00000001L) // Msg created locally
MSG_INTRANSIT (0x00000002L) // Msg is in-transit
MSG_PRIVATE (0x00000004L) // Private
MSG_READ (0x00000008L) // Read by addressee
MSG_SENT (0x00000010L) // Sent to remote
MSG_KILLSENT (0x00000020L) // Kill when sent
MSG_ARCHIVESENT (0x00000040L) // Archive when sent
MSG_HOLD (0x00000080L) // Hold for pick-up
MSG_CRASH (0x00000100L) // Crash
MSG_IMMEDIATE (0x00000200L) // Send Msg now, ignore restrictions
MSG_DIRECT (0x00000400L) // Send directly to destination
MSG_GATE (0x00000800L) // Send via gateway
MSG_FILEREQUEST (0x00001000L) // File request
MSG_FILEATTACH (0x00002000L) // File(s) attached to Msg
MSG_TRUNCFILE (0x00004000L) // Truncate file(s) when sent
MSG_KILLFILE (0x00008000L) // Delete file(s) when sent
MSG_RECEIPTREQ (0x00010000L) // Return receipt requested
MSG_CONFIRMREQ (0x00020000L) // Confirmation receipt requested
MSG_ORPHAN (0x00040000L) // Unknown destination
MSG_ENCRYPT (0x00080000L) // Msg text is encrypted (1)
MSG_COMPRESS (0x00100000L) // Msg text is compressed (1)
MSG_ESCAPED (0x00200000L) // Msg text is seven bit ASCII (1)
MSG_FPU (0x00400000L) // Force pickup
MSG_TYPELOCAL (0x00800000L) // Msg is for local use only
MSG_TYPEECHO (0x01000000L) // Msg is for conference distribution
MSG_TYPENET (0x02000000L) // Msg is direct network mail
MSG_NODISP (0x20000000L) // Msg may not be displayed to user
MSG_LOCKED (0x40000000L) // Msg is locked, no editing possible
MSG_DELETED (0x80000000L) // Msg is deleted
(1) This revision of JAM does not include compression, encryption, or
escaping. The bits are reserved for future use.
=====================================================================
????????.JDT Message text
---------------------------------------------------------------------
The .JDT file contains the text of messages. The text is stored as an
stream of seven or eight bit ASCII data. Allowed characters in the
text are 00H through ffH unless the header ATTRIBUTE field has the
MSG_ESCAPED bit enabled, in which case the legal range of data is 20H
through 7eH.
An escaped character is stored as \<hex> where <hex> is the two digit
hexadecimal ASCII value of the character. A single \ is stored as \\
or \5C. The case of the hexadecimal ASCII value is irrelevant, i.e.
5c is treated as 5C.
=====================================================================
????????.JDX Message index
---------------------------------------------------------------------
The .JDX file is used to quickly locate messages for any given user
name or to locate a message with a specific number. Each record in
the file consists of two ulongs. The first ulong holds the CRC-32 of
the recipient's name (lowercase), the second ulong holds the
physical offset of the message header in the .JHR (header) file.
The record number (+BaseMsgNum) within the .JDX file determines a
message's number.
If both ulongs are -1 (ffffffffH), there is no corresponding message
header.
=====================================================================
????????.JLR Lastread storage
---------------------------------------------------------------------
The .JLR file is used to maintain a user's position within a message
area. The layout of the "lastread" record follows. One record per
user is required.
LastRead:
ulong UserCRC; // CRC-32 of user name (lowercase) (1)
ulong UserID; // Unique UserID
ulong LastReadMsg; // Last read message number
ulong HighReadMsg; // Highest read message number
end;
(1) The functions to convert a string to lowercase characters that
are provided in the API will only convert characters A-Z (into
a-z). It is required that this convention is followed by all
applications.
The UserID field is a unique number for each user. If the "lastread"
record is deleted, UserCRC and UserID are both set to -1
(ffffffffH). An application may not depend on any specific order in
the .JLR file. A user's "lastread" record may appear anywhere in the
file and must be searched for when retrieving it and when storing an
updated record.
=====================================================================
Updating message headers
---------------------------------------------------------------------
If a header record grows after is has been retrieved from the .JHR
file, it must be appended to the end of the .JHR file since it would
overwrite the following header otherwise. The .JDX file must be
properly updated to indicate the new location of the header record.
The old header record must be changed to indicate that it has been
deleted by setting the MSG_DELETED bit in the Attribute field and the
TextLen field to zero (to prevent a maintenance program from removing
the message text that is now pointed to by another header).
=====================================================================
Message base sharing and locking
---------------------------------------------------------------------
To allow several programs to access the message base at any given
time, region locking is used to protect the message base from being
corrupted during updates.
When an application needs to write to any of the message base files,
it must first attempt to lock the first byte of the .JHR (header)
file. If the lock call fails, the application must either fail or
attempt to lock the file again. The message base files may under no
circumstances be updated if the application cannot successfully lock
the .JHR file.
Note that data acquired (read) from the message base may not be used
when writing data to the message base, unless the application has
maintained a lock of the message base from the time the data was
acquired or the MODCOUNTER field is the same as when the data was
acquired.
The application must open the files in shareable (DENYNONE) read/
write or readonly mode. The only exception to this is an application
that requires exclusive access to the message base, such as a message
base maintenance utility, it should open the files in non-shareable
(DENYALL) read/write mode.
=====================================================================
Reply threads and linking
---------------------------------------------------------------------
JAM introduces a new reply link pointer, not commonly used today.
This section is an attempt to describe how reply threads, reply
linking, and this new reply link pointer is implemented in JAM.
One of the major differences is that reply threads in JAM are not
based on similar or identical subjects of messages since this method
does not allow for proper reply threads.
The method used in JAM is based on the immediate relation between any
given message and direct replies to it. This is supported by many
message editors by using the MSGID and REPLY FTS kludge fields. These
are common, although expressed differently, in messages not based on
FidoNet technology, such as RFC-822. The obvious advantages include
allowing a program to easily find the original message to a reply,
and to find all replies to any given message.
The reply thread information consists of three fields: ReplyTo,
Reply1st, and ReplyNext. The reason for three fields, as opposed to
just two, is that with two fields, it is only possible to keep track
of the original message of a reply (which is sufficient) and one
reply to any given message (which is not sufficient). With three
fields, it is possible to maintain a thread of any number of replies
to any given message.
In the description of the different fields below, the following
messages and message numbers will be referred to:
1 -> 2 -> 4 -> 5
: :
: +--> 8
:
+--> 3 -> 7
:
+--> 6
Message number two, three, and six are replies to message number one.
Message number four and eight are replies to message number two.
Message number seven is a reply to message number three.
Message number five is a reply to message number four.
---------------------------------------------------------------------
ReplyTo
---------------------------------------------------------------------
This field holds the number of the message that this message is a
reply to. In the example above, the ReplyTo field would contain the
following values:
Message number one would contain zero; message number two, three, and
six, would contain one; message number four and eight would contain
two; message number seven would contain three, and message number
five would contain four.
---------------------------------------------------------------------
Reply1st
---------------------------------------------------------------------
This field holds the number of the first message that is a reply to
this message. In the example above, the Reply1st field would contain
the following values:
Message number one would contain two, message number three would
contain seven, and message number four would contain five. All other
messages would contain zero.
---------------------------------------------------------------------
ReplyNext
---------------------------------------------------------------------
This field is used to create the actual message thread or chain. In
the event that there is more than one reply to any given message, it
is necessary to maintain a thread of all the replies; this is due to
the fact that the original message can only hold information about
the first reply (the Reply1st field) to it.
The first reply (which the original message's Reply1st field holds),
has its ReplyNext field pointing to the second reply, the second
reply's ReplyNext field poinst to the third reply, and so on.
In the example above, the ReplyNext field would contain the following
values:
Message number two would contain three, message number three would
contain six, and message number four would contain eight. All other
messages would contain zero.
=====================================================================
Contacts
---------------------------------------------------------------------
Joaquim Homrighausen Telefax: +352 316 702
389, route d'Arlon Modem: +352 316 702
L-8011 Strassen eMail: 2:270/17@fidonet
Luxembourg joho@abs.lu
Andrew Milner Telefax: +352 251 621
9a, Boulevard Joseph II Modem: +352 251 621
L-1840 Belair eMail: 2:270/18@fidonet
Luxembourg andrew@fido.lu
Mats Wallin Telefax: +46 8 6453285
F<>rskottsv<73>gen 11 Modem: +46 8 6453882
S-126 44 H<>gersten eMail: 2:201/329@fidonet
Sweden mw@fido.lu
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

114
html/misc/outbound.html Normal file
View File

@@ -0,0 +1,114 @@
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=ISO 8859-1">
<META http-equiv="Content-Style-Type" content="text/css">
<META name="author" lang="en" "content="Michiel Broek">
<META name="copyright" lang="en" content="Copyright Michiel Broek">
<META name="description" lang="en" content="MBSE BBS Manual">
<META name="keywords" lang="en" content="MBSE BBS, MBSE, BBS, manual, fido, fidonet, gateway, tosser, mail, tic, mailer">
<TITLE>Binkley style outbound with MBSE BBS.</TITLE>
<LINK rel=stylesheet HREF="../manual.css">
</HEAD>
<BODY>
<BLOCKQUOTE>
<h5>Last update 02-Feb-2001</h5>
<P>&nbsp;<P>
<h1>Binkly style outbound documentation for MBSE BBS.</H1>
<P>
The MBSE BBS outbound directory structure is BinkleyTerm compatible, with
domains and point subdirectories (full 5d). There are separate "protected" and
"unknown" inbound directories for incoming sessions. Files received during
outbound sessions are always placed in the "protected" inbound directory. Only
the "protected" inbound directory is processed automatic.
<P>
<P>
Note that this is a very simple document and that it is not even finished.
<P>
<PRE>
.pol Poll flag, is handled as crash immediate, the length is always 0 bytes.
Flow files are files with the full pathnames to the files to send
on disk. Names are translated by MBSE BBS to full DOS filenames and
paths depending on your setup.
If you use it then it is importand that you think about the directory
structure to use. See also the documentation about the setup of the
<a href="ftpserver.html">ftp server</a>
The filenames may be prepended with a special character:
# = Truncate file after sent.
- or ^ = Kill file after sent.
@ = Leave file after sent, this is the default.
.flo Normal flow file (contains complete filenames to send).
.clo Crash flow file.
.hlo Hold flow file.
.ilo Immediate flow file, overrides CM flag.
The following are .pkt files, during the mail session they will be
renamed to nnnnnnnn.pkt with an unique name and added to the spool
file. Messages can allways be added to the outbound as long as the
node isn't locked.
.out Normal .pkt file.
.cut Crash .pkt file.
.hut Hold .pkt file.
.iut Immediate .pkt file.
It seems that these are subdirectories used by ifpack during packing
of mail. These are used for the news/e-mail gate.
.opk
.cpk
.hpk
.ipk
.req Request file. Contains filenames in ascii with &lt;cr&gt;&lt;lf&gt;.
.su0 Arcmail bundles, the last digit may be any digit or letter.
.mo0
.tu0
.we0
.th0
.fr0
.sa0
.sts Node status file created by mbcico. These are data files containing
three values:
1. 'time', this is the last call attempt time (in time_t format).
2. 'retries', is the number of retries to try to connect that node. This
field is zeroed when the call succeeds or when that node calls in.
It is also zeroed when a new poll is created. Currently, mbcico stops
calling a node if the counter is higher then 30.
3. 'code', is the return code of the last attempt.
0 - Successfull call
1 - No dialout port available
2 - No CONNECT or TCP connect failed
3 - Could not reset the modem
4 - System is locked
5 - Retry time not reached?
6 - Fatal error in nodelist lookup
7 - Call prohibited by config options
8 - Phone number unavailable
9 - No free matching port
10 - Unused
11..29 - Session (handshake) errors.
This file is <b>not</b> compatible with the .sts files created by <b>ifcico</b>.</PRE>
<PRE>
.spl Spool file, created by mbcico.
.bsy Busy file, for locking nodes. The 'pid' of the process who locked that
node is inserted into this file. All programs of the MBSE BBS package
(and ifcico package) check if the pid exists if a .bsy file is found.
If there is no pid found, the lock is a stale lock and is removed.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35">
Go Back</A>
</BLOCKQUOTE>
</BODY>
</HTML>

51
html/misc/semafore.html Normal file
View File

@@ -0,0 +1,51 @@
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=ISO 8859-1">
<META http-equiv="Content-Style-Type" content="text/css">
<META name="author" lang="en" "content="Michiel Broek">
<META name="copyright" lang="en" content="Copyright Michiel Broek">
<META name="description" lang="en" content="MBSE BBS Manual">
<META name="keywords" lang="en" content="MBSE BBS, MBSE, BBS, manual, fido, fidonet, gateway, tosser, mail, tic, mailer">
<TITLE>Semafore files with MBSE BBS.</TITLE>
<LINK rel=stylesheet HREF="../manual.css">
</HEAD>
<BODY>
<BLOCKQUOTE>
<h5>Last update 22-jul-2001</h5>
<P>&nbsp;<P>
<H1>Semafore files with MBSE BBS.</H1>
The directory $MBSE_ROOT/sema is the hardcoded semafore directory where all
semafore's must be created, tested and removed. When the system is booting,
the init script will erase all semafore's just before the BBS is started.
This description is valid from MBSE BBS v0.33.17 and newer.
<PRE>
zmh Purpose: to mark the state of Zone Mail Hour.
Created by "mbtask" at the start of Zone Mail Hour.
Removed by "mbtask" at the end of Zone Mail Hour.
upsalarm Purpose: Signal that the system is running on battery power.
Created and removed by UPS software.
Checked by mbtask to suspend processing.
Checked by mbfido to stop processing.
upsdown Purpose: Signal that the system will go down on low battery.
Created and removed by UPS software.
Checked by mbtask to go down.
Checked by several scripts and "mbstat wait".
newnews Purpose: Signal that there are new articles on the news server.
Checked by mbtask to start news processing.
Removed by mbtask as soon as it is detected.
mbtask.last Purpose: A timestamp created and touched by "mbtask" every
minute so you can check it is running.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BLOCKQUOTE>
</BODY>
</HTML>

61
html/misc/usleep.html Normal file
View File

@@ -0,0 +1,61 @@
<HTML>
<HEAD>
<TITLE>System load and the usleep() call.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
usleep.doc
At some time when developping MBSE BBS I decided that background utilities
did't need full speed to do their jobs. BBS utilities under DOS needed
to run as fast as possible because you needed to bring the bbs down to run
these programs and users couldn't login during that time.
Starting with mball, the allfiles creator, I inserted code that does usleep(1)
after each 5 processed files. The 1 microsecond is not really the time the
program pauses, it's probably a lot longer. I think this depends on the
hardware type, (Intel, Sparc, Alpha etc) how long Linux will really suspends
executing the utility.
The program speed downgrade at the development machine that mball needed was
3 times the original exection time, while system loading stayed under 30%.
At that time the development machine is an 486DX2-66 with a Seagate ST32151N
SCSI harddisk.
The extra usleep code is only active if you run these utils with the -quiet
switch and when this is set in mbsetup. See menu 1->5.
With this switch, the program is mostly run by cron. If you onmit
this switch, this is probably when you start the program manually, it will
then always run at full speed, no matter what the setting in mbsetup is.
If you have a fast system or don't care that the performance of your system
drops because of background processing, you can turn this future off with
mbsetup in the global section. (menu 1->5).
Remember, if you have a PII-400 MMX or so with IDE disks, you may still have
performance problems and need to set that switch to yes. There is only one
way to find out if you need it.
Well, actually, I tested this on a Dell Latitude PII-266, setting the switch to
yes gave better performance then no. Why? The CPU has more time for the slow
IDE disk. With the slow switch on programs runs even faster then with the switch
off.
Michiel.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>