Dec 262017
| WWIV Network Program Version 3.3. | |||
|---|---|---|---|
| File Name | File Size | Zip Size | Zip Type |
| DE1.EXE | 9156 | 5594 | deflated |
| LNET.EXE | 24858 | 14406 | deflated |
| NETAPP.FRM | 1534 | 746 | deflated |
| NETINIT.C | 2575 | 928 | deflated |
| NETREG.FRM | 1551 | 639 | deflated |
| NETWORK.EXE | 77482 | 42367 | deflated |
| NETWORK1.EXE | 38878 | 20510 | deflated |
| NETWORK2.EXE | 57392 | 27569 | deflated |
| NETWORK3.EXE | 68716 | 34389 | deflated |
| README.NET | 3674 | 1351 | deflated |
| REQ.EXE | 17248 | 9860 | deflated |
| WWIVNET.DOC | 82699 | 27709 | deflated |
| WWIVNETP.DOC | 51407 | 17420 | deflated |
Download File NET33.ZIP Here
Contents of the WWIVNET.DOC file
WWIVnet Docs
v2.33a
by
Wig De Moville
Filo
April 26, 1993
1. HISTORY
The first version of WWIVnet Docs was written by Will
Daystrom, also known as The Captain (1 @2370), who ran the White
Star Line and who copyrighted the Documentation for WWIV v4.10
and WWIVnet Docs under White Star Line Software. His documentation
was excellent and would not have needed to be rewritten if the WWIV
BBS software and the networks associated with it were not growing
and dynamic. However, v4.21a of WWIV introduced the ability for
a BBS to be on more than one network, and with that ability many
new networks were started. This documentation has been rewritten
with those changes in mind, so that the current documentation will
be useful regardless of which WWIV-based networks a board happens to
belong to. The part of the documentation detailing the policies and
procedures of WWIVnet has been moved to a separate document.
This version of the WWIVnet Docs is written by Filo (1
@2050), and is deliberately not copyrighted in order that future
versions can be built upon it without anyone's having to worry
about copyright infringements. If additional changes in the
documentation are necessary, I will offer them as v2.x if I am
still involved with WWIVnet. If I am not, then the next author can
decide whether to continue with 2.x or change to v3.x. I think
that 3.x should be reserved for a major change in the working of
the WWIV-based networks.
2. INTRODUCTION
A network is a voluntary association of bulletin boards using
WWIV software and participating in a network by calling one another
to facilitate the transfer of electronic mail (email) and
message bases (subs). At the current time, WWIV-based networks
constitute the second largest network running on private computers
in the United States. There are over 2000 systems located in the
United States, Canada, England, Germany, Italy, Spain, Mexico and Japan.
Through this network, a user of any of the bulletin boards that are
members may send email to a user of any other board. A user may also
post on a message base which may be read by the users of systems which
subscribe to that message base; thus, many of the networked subs have
international distribution. Because this system of communication is
read by others and because it has an effect on systems other than the
one on which it originates, a spirit of cooperation must prevail.
Out of this spirit grows systems of organization and regulation which
are known as networks and which are discussed in separate documents
distributed by those networks. This document covers some of the aspects
of the software which should be of interest to users and/or sysops
regardless of the particular WWIV-based network(s) with which they are
affiliated.
WARNING: When you unzip the network software, you should see "-
AV" on the line next to every filename. Furthermore, after the
files have been extracted, you should see the message:
Authentic files Verified! # XLD658 WWIV Software Services
If you do not see the "-AV" and the above message (be sure the
number is "XLD658"), then the files you have have been tampered
with, and you should not use them. Since this software is used by
several WWIV-based networks, the files herein should not be
extracted and included in another network package. If you desire
to distribute NETxx with another network software, you should
include the NETxx.ZIP file in its entirety within the other network
archive in order to preserve the AV codes.
3. REGISTRATION
Up until net28, the WWIV network software has been distributed freely
to everyone. Starting with net28, the net software is distributed much
like the WWIV software itself.
The WWIV BBS and network software is distributed as shareware, which
means (in this case) that you can use the WWIV and WWIV network software
for up to two months before deciding whether or not to register WWIV.
If, at the end of the two month period, you decide to register WWIV,
please see the 'read.me' file in the WWIV .ZIP file for information on
how to register. If at the end of two months you decide NOT to register
WWIV (and hence not use WWIV software for your BBS), you must stop using
the WWIV and the network software.
If/when you register WWIV (and receive a WWIV registration
number), you have also registered the network software, and may
use the bbs and network software on your system as you wish -- as
a standalone BBS, or in a network.
If you are running a BBS that is in no way based on WWIV
software, but that uses the WWIV network software, then a similar
registration procedure applies. You can use the network software
for a two month trial period. If you decide to continue using the
network software after the two month trial period, then you must
register the network software for $20. If you do not register the
network software at the end of the two month trial period, you must
stop using it. Registration of the network software for those systems
not running a BBS based on WWIV is done by following the instructions
in the NETREG.FRM included with each NETxx.ZIP packet.
Thus, there are two ways you can legally continue to use the
network software after the two month trial period. Either
register WWIV, or (if you are running BBS software that is in no
way based on WWIV software), register the WWIV network software for
$20.
4. ORGANIZATION
WWIVnet originally began in 1988 with 25 charter members who
helped Wayne Bell develop the network software and debug it.
Since that time it has spread from a small Los Angeles-based system
of local boards to several international networks. Currently, the
three largest of these networks are WWIVnet, WWIVlink, and IceNET.
The network software is in its 33rd version although there will
undoubtedly be many future versions written as well. These
versions are referred to as Net1, Net2,...Net20, etc.
5. WWIV Software
WWIV v4.20e and up supports the automatic request for a sub
and the automatic removal provided that each board has the network
software to support the feature and provided that the sysop has
configured his board to allow auto-requests. Beginning with NET32,
the automatic request feature and an option for the description of
the sub in the SUBS.LST is included in BOARDEDIT. This feature
should facilitate a board's adding or dropping subs that are
subscribed to.
The network software includes the creation of informational
files on each network system which reflects subs or messages
received that have 'no place to go.' In effect that would mean
that the receiving sysop has not created a message base for that
sub or has deleted it but is still receiving mail for it. The
sysop should check this file regularly and if he is receiving subs
that he has not ordered or does not want, he should notify the
sending host to please remove his system from the distribution
list. This information and other information on network
connections may be found in your GFILES directory in files named
NETDAT0.LOG, NETDAT1.LOG and NETDAT2.LOG. The NETDAT0 is the
newest log and NETDAT2 is the oldest log. These logs are only kept
for a three day period unless you make other provisions to have
them saved. They may provide useful information to you in terms of
what you are/are not receiving and in terms of problems that may
occur in your network connection. Under v4.22 of the BBS software
the sysop can access these logs from the bulletin board by typing
a comma at the main menu.
The sysop should also occasionally review his DEAD.NET file
which will be in DATA. Messages in this file are those which
were bound for another system but which cannot be delivered after
having arrived on your system. Often these are due to one of two
factors. The first case might be due to a board's having
subscribed to a sub and having been put on the distribution list
for it before that board has been added to the bbslist. Thus the
system does not know where to deliver it. If that is the case, the
DEAD.NET should be left alone because once the system is added, the
network software will deliver that mail to the new system. The
second case would occur when a board has left the network or has
been temporarily disconnected from the network. It may still be
receiving mail because either the sysop failed to notify the host,
mail was already in the system, or because the host sysop has
failed to remove the board from the distribution list. In that
case, the mail may be safely deleted. Before deleting the mail,
you should check with the board's AC to be sure that the board is
out of the network.
In addition, the sysop should write the host of the sub
whose mail is going to DEAD.NET and inform the host of which
board is no longer on the network and request that host delete the
board from the distribution list. NET32 and up also has a feature
to report on undeliverable e-mail to another system in the form of
a System Short Message (SSM).
Sysops who receive subs from other systems have the responsibility
to restrict access to the sub according to the rules of the host. For
example, some subs may limit access to User Number 1, to users with 255
access, or some other requirements such as all posts must not have tag
lines. The receiving sysop must also take steps to inform users of the
rules applying to a particular sub. GFILES are often a good way of doing
this.
These guidelines for sysops are nothing more than common
sense and normal courtesy which reflect the desire on the part of
all to cooperate in order to make the network work properly and
efficiently. One of the interesting features of the network is
that it is a great leveler. No one (except possibly a few sysops)
knows the age of the person making the post; therefore, people's
impressions of the person who posts is made entirely based upon the
language used and the thought expressed. As a consequence many a
young user can convey the impression that he is much older and more
mature, and some older users may convey the impression that they
are irresponsible, illiterate users. One hopes that users will opt
to convey the impression that they are mature, responsible human
beings.
Sysops may choose to promote responsible use of the network
by asking users to make their network posts conform to certain
suggested guidelines. For example, the Sysop may request that
users:
o Not Use Foul language on the network
o Not make personal attacks against others
o Not post a lot of one-line messages on the network
o Learn the differences between using A, W, or P to respond to
network messages.
These are merely suggestions for responsible use of the
network and are not requirements; however, some of those
suggestions are also found in the rules of the hosts of many
network subs. Where they reflect the host rules, they are generally
considered network rules for that sub.
The following information lets you see at a glance the type
of message (ie where it originated) when reading message bases:
[1] = messages posted by you
<2> = messages posted by someone else remotely
(3) = messages posted by someone else locally
//BOARDEDIT now manages additional information for you, such as
the host system #, whether a sub you host is auto-requestable, and whether
the sub is automatically reported for SUBS.LST updates. This additional
info is stored in the "SUBS.XTR" file in your data directory, but DO
NOT MODIFY THAT FILE DIRECTLY. Use //BOARDEDIT all the time. If you're
using net31 or earlier, you'll notice that your nnall.net, allow.net,
and subs.pub files will automatically be updated for you. With net32
or later, the files will be deleted, as all the info is now in the
SUBS.XTR FILE.
You can now gate subboards among networks your system is a member of. This is
done in //BOARDEDIT, simply by entering net info for multiple networks. In
order to support sub gating, you need to be using net32 or later. Do not try
listing different sub types in the same network, as it probably won't work.
Gating DOES work with net-validation. You can gate subs as either the host or
as a subscriber system, but please do not gate subs unless you really have a
good reason, and know what you're doing. Additionally, you need the per-
mission of the original sub host in order to gate messages.
You can now net subboards by sub name (instead of just sub type). A sub name
is 1-7 chars of upper-case letters and numbers, and doesn't start with a
number. Note that in order to use sub-by-name, the host AND all subscribers
need to be using v4.22 (or later) AND net32 (or later). Other than that,
subs-by-name works the same as subs-by-type. Because of changes being
made by the telephone companies (see Section 10 - Future Directions), it
may soon be necessary to run v4.22 or better in order to be able to use
the sub-by-name feature in almost all networks. There may even be a
MANDATORY UPGRADE of both WWIV software and NET VERSION in the near future
as a result of these changes.
If you connect to the same system number in multiple networks, you can now
force a callout to either one (you are prompted to select which one).
Future versions of the network software will allow you to pick up all
network messages for your system on one call to the same connecting
system.
You can now (correctly) forward mail between networks. If you're using net32
or later, if the person you forward the email to auto-replies, the reply will
correctly go back to the original person who sent the email.
6. INSTALLATION
This section of the WWIVnet Docs takes you step-by-step through the
installation process involved in setting up the network executbles
and other files necessary to the operation of a WWIV-based network.
6.1. Apply for Network Node Number
The first step is to obtain a node number. The appropriate
method for doing this varies from network to network and is covered
in the documentation specific to the network that you are interested
in. You may consult the NETWORKS.LST file included with this docu-
mentation to determine if a "contact person" has been designated for
the network you are interested in.
The node number should be entered in INIT under Option 2 if you
are on a single network; otherwise the information on each of your
networks and network nodes is entered in INIT Option N.
You may wish to enter information in INIT for a "Net low time"
and "Net high time". If you do this, it means that beginning at the low time
and ending with the high time, a user who attempts to log in will receive a
message indicating that your board is only accepting network calls during that
time period. For example,
Net low time : 03:00
Net high time : 05:00
would indicate that the network time period is from 3am to 5am. Military
times are used to indicate time periods in the network.
Also, in INIT option 1, you should insure that your board name and
telephone number are entered exactly as they are shown in the BBSLIST.###
or the BBSLIST.NET file which are also discussed later.
6.2. CALLOUT.NET
You will have a CALLOUT.NET file which should be placed in your DATA
directory, or in the case of multiple-networks--in the date directory
for each network, and which will show the systems that you connect with.
This file is in the following format:
@node [macro options] [transmit options] [callout options] [password]
Each of these options is discussed in turn. The node is the
node number of the board you are connecting with.
6.2.1. Macros:
Macros are often used to achieve special purposes. These purposes
include (a) connecting with another board in your area code where it is
necessary to dial 1 before dialing the board number, (b) using a telephone
service such as PcPursuit where special numbers, passwords, etc., must be
sent, (c) connecting with another board that is running WWIV as some form
of door (i.e., WWIV is not answering the phone--instead some other
software answers).
The macro to use is designated in the CALLOUT.NET by %x
where x is an integer number. The macro should then be provided
in the DATA directory under the name Mx.NET where x is the same
number.
For example, if you use PcPursuit to call St. Louis, Mo.,
and Phoenix, Az. you would need a macro for each city. The macro
commands and a sample PcPursuit Macro are in Appendix B of this
document.
6.2.2. Transmit Options:
Transmit options are basically two. You may use the &
parameter which means that files will be transferred each
direction when a connection takes place. If the & is omitted then
the transfer will be uni-directional; from you to the other board.
In such a situation, you pay to send your files to the other board,
and presumably, it will pay to send its files to you. This is not
a very efficient arrangement and is basically discouraged.
The other transmit option is for network compression. If
you specify the ; parameter, then network traffic to be transmitted
to that node will be compressed, using pkzip's compression techniques.
PKzip or other compression programs are not needed, as the
compression/decompression code is built into the network software
(using the PkZip data compression library). You must ensure, however,
that the system for which you specify compression is using net24 or
higher; if they are using net23 or lower, all compressed data sent to
that node will be lost.
Please do not assume that compression should be used for all
your net connections. Local connections and high speed connections
that also use V.42bis are probably not good choices for using
compression. Also, try to avoid using MNP5 on connections for which
compressed data is sent. The packets that are created begin with z.
For example,
Z5252.NET
would indicate a compressed net packet bound for node 5252. You
should check with the Sysop of the other node before enabling
compression between your system and the other. Some
experimentation may be necessary to determine which connections
benefit from compression.
6.2.3. Callout options:
These options affect when your board will call the other
board.
/x Where x is an integer between one and 9.
This means that the network will force a callout to that board every x
days, even if there is no mail waiting to be sent to that system. This
parameter is often set where one board does not often call the other.
= This means to call during PcPursuit hours (6 pm to 6 am
Monday thru Friday and anytime on weekends). These parameters are
handy for those long distance connections utilizing PcPursuit.
For a board to make use of PcPursuit for the network, a macro
must be used (see appendix for a sample macro).
- The minus parameter means to call during times when
rates are cheapest (11 pm to 7 am and anytime on weekends). This
parameter is recommended for long distance connections in order to minimize
your phone bill.
! This limits the number of calls per day to 1. The
board will attempt to call out starting 20 hours after the last
successful connect. This feature only works with WWIV v4.12
or higher.
!x Where x is an integer. This limits the number of calls
per day to 20 divided by x. The board will attempt to call out
every 20/x hours after the last connect. This feature only works
with WWIV v4.12 or higher.
+ The plus parameter indicates that your board does not
call the indicated node; instead, that node should be calling you.
If both of you have the + parameter in CALLOUT.NET then no
transfers will take place between you.
~ The tilde (~) means that your system will never call
out to the other system, and that the other system will never call
yours to pick up mail. The other system will only call yours
to send data to you.
^ The caret (^) is used to enable the HSLINK protocol
between your system and another. If present on both systems (and
the HSLINK executable is found on both systems), the network will
attempt to use HSLINK as the protocol instead of Zmodem (or
ymodem). CAUTION: Be sure you do NOT have the -! modifier in your
HSLINK.CFG file. NET32 now appends that modifier to the command
line for outgoing Net calls. If the -! is present in the
HSLINK.CFG file, it may cause conflicts that could prevent
optimiun performance when recieving Net calls. See Appendix for
details on setting up HS/Link for WWIV.
Another set of parameters may be used to designate that the
board should call between certain hours. These parameters are
illustrated below:
(3 )5 would mean that the board should call between 3 am
and 5 am. Times are specified in 24 hour time. Midnight is
specified as 0.
These parameters are useful if you are having a connection
with a board that runs a NET TIME PERIOD or to insure that local
connections take place during non-busy hours. If none of these
time delimiting parameters are used, your board will make the
connection with the other anytime that there is mail to go out and
the board is not busy. This is NOT recommended for long distance
connections unless you are using a WATTS line or other system that
makes long distance a fixed cost. It may be used for local
connections if desired.
6.2.4. Passwords:
You should not enter a password in your CALLOUT.NET. The
network software will generate a password between the two systems
once there is a successful connection. This is one way that you
can tell whether or not your system has connected with the other.
If there is a password present, there has been a connection.
For more information on passwords, see the section on Trouble
Shooting NetWork Connections. Also note that the password will be
in quotation marks as the last item on each line of CALLOUT.NET.
If you lose your password for some reason such as corrupt files
or hard disk failure, you will need to contact the other sysop to
have the password removed from his CALLOUT.NET file so that a new
one may be established.
6.3. Network Software
You should obtain the latest version of the Network software
and place the files in the main directory of your BBS. That will
be the directory where the BBS.EXE file resides. You may determine
the latest version of the software, by asking your network contact
person or other network official to supply you with a copy of it.
You should remain alert for changes in the network version. Currently,
it is NET33; however, future versions will be released as needed. It is your
responsibility to obtain these versions once you are on a network.
You may usually obtain them from Amber (Wayne Bell's board), from the
WWIV Support Boards (you will get a list of these with the WWIV
software, and the list is updated from time to time), or from one of
your networks officials.
6.4. BBSLIST and CONNECT:
There are basically two ways of using the network software. One of these
ways is best suited for small networks and the other lends itself to larger
networks. While both methods will work for small networks, the large method
must be used when a network approaches 500 systems due to the way that some
of the software functions. A small network will only need two of the files
mentioned below (BBSLIST.NET and CONNECT.NET) and all nodes will have a
listing in each. Large networks will use several BBSLIST and CONNECT files.
All of these files should be placed in the DATA directory if your board is
only on one network. If you are on more than one network, then the files
for a particular network should be in its separate directory as you defined
it in INIT option N.
BBSLIST.NET - For a small network, this file can list all nodes
participating in the network. The general format of this file is
discussed in the appendices. A small network does not need any of
the remaining BBSLIST.x files. In a large network, this file functions
as a time/date stamp and will normally be two bytes long. If you did
not get a file like this with your network data files and if things are
not functioning properly, you may need to create this file. All that
is necessary is to create a file name of BBSLIST.NET and put a single
space inside of it and save it.
BBSLIST.0 - This contains the numbers of valid groups in the
network. It will look like an N*.NET file, sort of. All systems
in the network will have a copy of this file. Let us say that a particular
network has groups 1,2,3, and 60. In that event, the BBSLIST.0 file
would appear as follows:
~754648789 A number such as the one given would appear on the
first line following a tilde. This number is a
time/date stamp and will change from time to time.
:A This lets the software know that the information
for each group will be found in separate files rather
than in the BBSLIST.NET and CONNECT.NET.
1
2
3
60 Observe that the group numbers are shown one per line.
BBSLIST.xxx - This file will have a number in the place of
xxx. The number will be the group number and the file will have
all of the BBSLIST.NET entries for that group. All systems will
have a BBSLIST.1-255 for all groups listed in BBSLIST.0. However,
the information in the file will pertain only to that group. You
may note, at times, information in your network logs regarding
bbslists ending in 5xx. Depending upon the type of software being
used by your network for updates, these probably indicate that a
"partial" update was received and processed. Normally after processing
these files (the BBSLIST.5xx and CONNECT.5xx) are removed from the hard
disk.
CONNECT.NET -- For small networks, this file will reflect the
connections of all nodes in the network. For a large network, this will
be a time/date stamp type file similar to that discussed for the
BBSLIST.NET. If things do not work right and the CONNECT.NET file is
missing, try creating it with a space inside.
CONNECT.0 - This file will exist on all systems for a large
network and will show connections between systems in different groups. For
example, if area codes 512 and 502 are part of the same group (group 4),
a connection between boards in those groups is not between groups, even
though it is long distance, and the connection would not be shown in
the connect.0 file (it would be shown in the connect.4 file). However,
a connection between 512 and 213 which are in different groups would be
shown in the connect.0 file. Note that systems with connections listed
in the connect.0 file will almost certainly also have connections listed
in their local (group) connection file also. Some networks refer to
groups as zones or regions so be alert for this difference in terminology
in the respective network policy documents.
CONNECT.xxx - This file will exist on all systems and will
show connections between systems within that group. This will not
show connections to systems in other groups.
If your connection within the group will be calling you,
then you need only wait until you receive the files. Thus, once this
update arrives at the board which will be calling you, that board will
callout to you and you will receive the necessary files. One exception
to this is that some smaller networks use a different method of sending
network updates. If you are on a small, private network, then you
should check with your network administrator regarding what you should
do (if anything) in order to receive updates.
If you are to call the other board (and it does not call
you), then you will need to keep in touch with that sysop so that
you have an idea of when the network update comes in. If you
obtain new network files via a download or some process other than
receiving them through the network as an update, then you may need
to force the network software to do an analysis. This may be done by
using the following command at the DOS level. (Note: if you are on
more than one network, you may need to use "dot commands" as discussed in
the appendix.
NETWORK3
That will run NETWORK3.EXE which analyzes your BBSLIST, CONNECT, and
CALLOUT.NET files. If you add a Y after the command (ie space Y) then
the network will send you a form letter as feedback letting you know the
results of the analysis and sometimes identifying problems with your setup.
Although it is natural for you to want to begin to subscribe
to subs and so forth, you should exercise patience until you are
'officially' in the network. If you order subs before your board
is official, then your system will show up as "unknown" and the
mail will not reach you. Since many hosts of subs like to send new
subscribers the rules regarding posting on that sub, the fact that
you are an unknown system may result in a delay in your receiving
the sub. If you wait until you are officially in the network, then
these problems are avoided.
If you are joining more than one network, it is important that
you establish these connections ONE AT A TIME. The reason for this
is simply that if you have several CALLOUT.NET files that have not
established passwords and so forth for your connections, it is
possible to have the passwords get confused (ie an incorrect
association between network and password established). This may
be avoided if you proceed in an orderly fashion and add one network
at a time.
6.5. Information Needed for BBSLIST listings
Your Board Name -- exactly as you want it to appear in the
Network. You may wish to peruse a current listing of boards on the
network in order to select a name that is unique.
Your telephone -- this should include both area code and
complete number.
Maximum Baud -- this should be the maximum baud rate that
you can support. If you are using a high speed modem capable of
more than 2400 bps then you should indicate the rate that your
serial port is locked at as the maximum baud rate or the maximum
connect speed supported. You should check with the network
administration for the conventions followed on the network that you
are joining. The network software reports various information
regarding hi-speed modems. These parameters are discussed in the
appendices.
Some networks will also want either your registration number
(if you are registered). That information may (or may not) be
reported in brackets in the BBSLIST information.
The information above will be included in the BBSLIST.XXX
for your group along with a group identification number. In that
listing, some networks identify area coordinators (AC's) by a ^ next
to the telephone number. Group or Zone Coordinators are often
identified with a %.
6.6. Net Editor
Black Dragon (1@3080 WWIVnet) developed the Net Editor to facilitate
the updating of network files by sysops and Area Coordinators. That
program is fully compatible with all network data structures since the
beginning of WWIVNet to the present. You should check with your network
administrators regarding whether or not updates in that format are
acceptable to them. Some administrators will not be setup to receive
them from netedit.
7. USING THE NETWORK
Using the network is relatively simple. Sending netmail,
subscribing to network subs and hosting network subs are discussed
in this section.
7.1. Sending Netmail
Netmail is like email on your local system. That is, users
on your board may send email to one another by entering either the
name or user number of the person that the mail is to be sent to.
In netmail, you must also use the node number as part of the
addressing scheme. Suppose that user number 5 on your system
wishes to send netmail to user 2 (KatyDid) at 3451. In that case,
the netmail could be addressed as follows:
2 @3451
-or-
KATYDID @3451
Please note that this is merely an example; there is no user named
KATYDID @3451. If the BBS is using NET32 or later and v4.22 or later,
and that board is on multiple networks, the software will provide a
listing of choices if the node number given is not unique (ie exists
on more than one network to which the board is a member.)
Such mail may be sent by the user in one of several ways.
The user could simply use the E option to send email and then
address it properly. The user might use the A response to send a
private message to someone who has posted on a national message
base, or the user might use either the A or S to respond to a
message received privately from another system. Any of these
methods will result in netmail being sent to another system.
Mail may also be sent from one WWIV-based NetWork to
another by using the following type of addressing:
NETWORK NAME #UserNumber AT NodeNumber @XXXX where XXXX is the
gateway node number. For example to send mail from WWIVlink to
user #1 at node number 1 on WWIVnet, the mail would be addressed as
follows:
WWIVNET #1 AT 1 @2050
That is just an example. Any node that is running the NET32
software can function as a gateway node provided that it has
connections in both networks. Addressing gateway mail by name
is also permissable. For example, to address Wayne Bell by name in
the previous example, you would use:
WWIVNET RANDOM AT 1 @2050
For those who care, Random is Wayne Bell's handle.
7.2. Subscribing to a Netted Sub
The method of subscribing to a networked message base
depends upon the version of NETxx that you are using. To subscribe
to a message base hosted by another system (i.e., a netted sub)
while using NET30 or earlier, there are 3 things which you must do. First,
you should send netmail to the host of the sub requesting
that she place you on the distribution list for that sub. It is a
good idea to name the sub and sub-type in that letter as many
people host more than one netted sub and it will prevent them from
getting confused. Second (for versions prior to NET32), you should
enter your DATA directory and create a file. The name of the file
should be NNsub-type.NET and it should have the host's node number in it.
Although you can do this with an ascii text editor, it may be easiest
to do this from the DOS level with the copy con command.
To accomplish this, type in the following (note information beginning
with -- is commentary and should not be typed) assuming that you are
subscribing to the WWIV New Sysop's sub (sub-type 22050; hosted by
2050):
copy con NN22050.NET --followed by an ENTER or RETURN 2050
F6 --the F6 means press Function key 6 or you can hold control down
and press Z.
A successful result will result in the message "One file
copied" being seen on your screen. Please be sure to put two N's
in the NNxxxx.net file. One N is used for a host system, so if you
put a file with one N into your data directory, it will result in
messages being doubled, most disconcerting to the host and other
systems which subscribe to that sub.
Starting with WWIV v4.20 rev D and ending with NET31, there
is an alternative to having many little nn*.net files in your DATA
directory. You can list all the subs you subscribe to in the file
'NNALL.NET' in your DATA directory. Each line in the NNALL.NET file
contains the information for one subboard. The first number on the
line is the sub type, and the second number is the host system.
Anything after that is a comment. For example, you might have the
following lines:
1701 1 Star Trek sub
10001 1 Politics sub
22050 2050 WWIV New Sysop's sub
Note that you >MUST< be using WWIV v4.20 rev D or later for
this to work.
Starting with NET29, it was possible to auto-request a sub. This
meant that if the sysop had listed the sub in a file called
ALLOW.NET in DATA, then the subscriber/sysop could automatically
request the sub.
This method has been further refined under NET32
and v4.22 of WWIV so that the ALLOW.NET is not used and the
NNALL.NET is not used either. SUBS.XTR contains all of the
pertinent information regarding the sub and the networks that it is
on.
The third step is to either use B (for boardedit) when you
are at W-F-C or type //boardedit when you are logged onto your BBS
and then set up the message base. Be sure to indicate the sub-type
number in the option for that: Completed result for the New Sysop's
Sub might look like the following under v4.22 :
A. Name : WWIV New Sysop's Forum
B. Filename : NEWSYS
C. Key : None
D. Read SL : 60
E. Post SL : 60
F. Anony : No.
G. Min. Age : 0
H. Max Msgs : 50
I. AR : C
J. Net Info :
Network Type Host Flags
a) WWIVNet 22050 2050
K. Storage typ: 2
L. NetValidate: No
M. Require Ansi: No
N. Disable Tag: No
O. Description: WWIV New Sysop's Forum for Help & Advice on WWIV
Since the host of New Sysop's Forum permits visiting sysops
to read and post and since the sysop of this board assigns an SL of 60 and
an AR of C to visiting WWIV sysops, he can be sure that the host's
requirements are met.
Although you are not required to do so, it is a good idea to
send a short thank you or other acknowledgement to the host to
let him know when you begin to successfully receive messages on
the sub. If the host has special rules and regulations that you
need to inform your users of, you may do this in several ways.
You could include such information in a form message (i.e., a
message named FORMxx.MSG where the xx may be either integers or letters)
which you send to all users. You also might make the first message on the
message base contain the rules and then make it a permanent message. If
you choose this form, be sure to make such a message before you get
hooked up to receive the messages, else your message will go out on the
network. Finally, you could put a synopsis of special rules in the GFILES
area and direct your users to read that.
7.3. Hosting a Netted Sub
As part of some networks, you will receive SUBS.LST, a listing
to be found in your network dATA directory regarding the various networked subs
that are available for you to subscribe to. At some point, you may wish to
host a netted sub yourself. If you do, you should first make sure that
there is not another sub already out there serving the same need. If
there is, then you should only host a sub on the same topic because you
think that you can do it better or because yours will have a special
slant. On the other hand, you may have expertise in an area or information
on a subject which is not being currently addressed on your network and for
which you think that there might be a demand. In that case, you could
decide to host such a sub.
To host a sub, you must create an Nsub-type.NET file in DATA
and in it, you should keep a list of the systems which subscribe. The list
may be vertical or horizontal as long as there is a space between numbers
when they are placed horizontally. Personally, I recommend a vertical
listing from lowest to highest; that way you can easily tell when a sub
has already subscribed. The traditional numbering of subs would start
with your node number. For example, assume that you were node 5290, then
your logical sub numbers would be:
Hosted Sub Sub-type Host
First 5290 5290
Second 15290 5290
Third 25290 5290
Fourth 35290 5290
Fifth 45290 5290
Sixth 55290 5290
You may observe, however, that not all subs in a network
are numbered this way. This is because of two occurrences.
First, many boards hosted subs before this numbering system was
developed. Secondly, sometimes the original host ceases to sponsor a sub
and another sysop takes it over but maintains the original numbering
scheme. For example, Sub-type 2370 is the number of the WWIV
Modifications Net Sub which started in 1988 at the White Star Line. After
Will Daystrom, the originator, no longer could host the sub, it was
passed to others. Although the host number changed, the sub-type
originally used continued to be used in some networks.
Net32 and V4.22 of WWIV support a Sub-by-Name concept which means
that you may use any legal 7 letters or characters as a SubType. This
numbering convention will enable boards to handle more subs than was
possible before under the sub-as-integer concept. NOTE that future
changes (see Section 10 Future Directions) may effectively necesitate
your being able to use the sub-by-name approach. Thus if you have not
upgraded your WWIV version, you should give some thought to doing so
soon.
You may want to develop a form message to send to those sysops who
subscribe to your sub. Such a message should remind them of the name,
sub-type, and host and it should provide any rules that you may have
regarding who may access the sub or who may read/post there. Also you
should get in the habit of reading your mail regularly and responding
quickly to requests for the sub. If you have indicated (under NET32
and version 4.22) that the sub may be auto-requested, then if you have
a file called SA......NET in GFILES, and if the dots are replaced with either
the subtype number of the first 6 letters of the sub-by-name, then that
letter will automatically be sent to those who subscribe to the sub with
the autorequest function.
You may wish to advertise your sub. There are some National
netted subs which have been developed just for that purpose and you should
use them if you can.
The host has the right to run his sub as he sees fit and may
establish any rules he wishes. The only restriction on sub topics
is that they be legal. If a host chooses to 'throw' someone off
of a sub, the individual has no recourse. Of course someone may
start her own sub if she wishes. These rules are followed on most
networks, however, you should refer to the documentation for the
particular networks you are a member of to see if that network has
different rules for sub hosts.
WWIV v4.12 and following introduced a feature known as Net
Validation. This feature may be toggled on or off in BOARDEDIT.
When it is toggled on, messages will not leave your system until
they have been validated. A host, when reading new messages on
a sub, may press X to prevent a message from being sent out.
After reading the messages, she will be asked, "Net Validate
these Messages?" A Y response will result in all messages being
sent out except those where an X was pressed. After all messages
have been read, pressing X will cause them to be sent again.
NOTE: This should not be done for it may result in sending out
duplicate messages across the network.
8. NETWORK FILES
8.A FILES in same directory as BBS.EXE
The files discussed below are the Network executable files
which should be placed in the same directory as your BBS.EXE
file. The files which belong in your DATA directory are discussed
under 8.B.
1) NETWORK.EXE - This file is run when a BBS is calling
another board through the network. This program handles the modem and
the network security.
2) NETWORK1.EXE - This program analyzes P*.NET files to
determine which are for local distribution and which are to be sent to
boards that you connect with. The latter files will be stored in DATA in
Sxxxx.NET files where xxxx is the node number of the receiving board, or in
Zxxxx.NET files if the packet is compressed.
3) NETWORK2.EXE - This program analyzes local mail and
distributes it to the proper message sub or to email.
4) NETWORK3.EXE - This program analyzes CONNECT.NET and
BBSLIST.NET. The analysis may cause the network software to leave you
messages. The sysop should read these messages and respond to them ASAP.
These messages are discussed in the Appendix.
5) LNET.EXE - This program allows the deletion of corrupted
messages prior to their being sent over the network. It can also be used
to delete a message which the Sysop does not want to go out over the
network....such as one which violates the spirit or rules of a Sub. As a
general rule, a Sysop should not use LNET to read outgoing messages. One
exception to this is to use LNET to read the messages in DEAD.NET. LNET
cannot read mail in packets which have been compressed.
DEAD.NET is a file to be found in DATA for messages
that could not be delivered because the system and/or routing was in
error. The header for these messages in DEAD.NET indicates the systems
which it is for and the number of days since it was written. Sometimes
messages go there because a new board has not gotten set up yet; but often
they go there because one or more of the destination boards have gone down.
If these messages are several weeks old, there is probably no harm in
deleting the DEAD.NET.
6) DE1.EXE - This program analyzes net packets to make certain
that it is authentic. Such packets are referred to as Source Verified
messages. This file is NOT used by all networks. Since it is network
specific, if you are a member of more than one network, you should place
this file in the network data directory.
7) DExxx.EXE - This program authenticates updates received
from the group coordinator. Again, this files is not used by all networks
and it is network specific. If you are on several networks, put these
files in the network data directory for each separate network.
8) NETINIT.C - This file needs to be used only if you have
registered WWIV and have modified the structure or size of the
userrec structure. If you have modified it, compile and run NETINIT and it
will store information necessary for the network in the CONFIG.DAT file.
9) REQ.EXE - This file is provided to allow those systems that
do not run WWIV BBS software a means of auto-requesting subs.
Additional files may be added to the network as the development
progresses or some of the existing files may be changed and/or
eliminated.
8.B Files in your Network Data Directory
The files that belong in your network data directory will vary
somewhat from network to network depending upon whether the "large"
or "small" form or file organization is being used and upon whether
or not the network employs group or zone coordinators who send out
updates. As mentioned earlier, those executables (like DEx.EXE type
files) belong in the network data directory.
In addition, the BBSLIST.NET and possibly BBSLIST.1, BBSLIST.2,
etc., the CONNECT.NET and possibly CONNECT.1, CONNECT.2, etc. and
the CALLOUT.NET files must be present in order for the network to
function properly. When the network analysis is performed by
NETWORK3.EXE, additional binary data files will be created such as
CONTACT.NET, BBSDATA.*, etc.
You may also find FBACKHDR.NET (an information file distributed
by the net coordinator for the network), SUBS.LST and perhaps
SUBS.1, SUBS.2, etc which provide information on the subs available
in the network. CATEG.NET, an information file that permits sub
hosts to categorize their subs so that they automatically show up
in SUBS.LST according to the proper category. NETWORKS.LST, a
file showing the various WWIV networks and whom to contact for
additional information on that network as well as information on
the coordinator of that list so that persons creating a network
will know whom to contact to get their network on the listing.
8.C "Dot Commands"
Beginning with NET32, it is possible to use "dot commands" when
it is desireable to force a network executable to work with a specific
network. If no "dot command" is used, the program defaults to using
the network executable with data in the DATA directory. On the
other hand, if you are on more than one network, Option N in INIT will
create a file called NETWORKS.DAT in the DATA directory. Dot commands
work by using data from the networks in the order listed in the
NETWORKS.DAT file which is the same order that you see when you use
option N in INIT. The first network listed is associated with .0; the
second with .1, etc.
For example, to force LNET to run on the DEAD.NET file in the
second network listed, you would use LNET .1. To force a network
analysis on the third network listed, you would use NETWORK3 Y .2.
Under NET31, it was necessary to set environmental variables to
make these commands work. These environmental variables are no
longer needed under NET32 and should NOT be used.
9. TROUBLE-SHOOTING NETWORK CONNECTIONS
Utilizing the NETWORK is really very simple. If you have tried
everything you can think of to remedy a problem and are unable to do so,
contact one of the Sysops of a SUPPORT Board and enlist aid. Do not
contact WAYNE BELL except as a last resort. Sometimes there are problems
with the code and/or its compatibility with different modems; however,
those type of problems can only be addressed after all other avenues have
been thoroughly explored, and even then that may not be the solution. For
example, many WWIV Sysops have registered the WWIV software, obtained the
source code and made extensive modifications to the BBS.EXE. In that
event, it may be a modification that is causing the problem rather than the
network software.
When seeking help, be prepared to provide information on your
system, your modem, the error messages you get and so forth. Debugging
network problems is usually a process of eliminating the various possible
sources of problems one by one. Any information which you can provide to
speed this process makes it easier on all concerned.
A few common problems, and their solutions, are described
next.
9.1. You force callout and the cursor returns to WFC
First, be sure that you are attempting to force the call
during any agreed upon hours. If it is not during the agreed
upon hours, the network software will prompt you "Are you sure?"
An affirmative response will allow the call to proceed. If the call does
not connect, you should double check the CALLOUT.NET, CONNECT.0, and
BBSLIST.x to be sure that no typographical errors were made. Zeros cannot
be o's, group designators must be correct, etc.
Also, under Net20 and later you should ensure that all files in
your network dATA directory are correct as they affect your board and
the board that you connect with. For example, a failure to show your
connection will cause an error.
If no typographical errors were made, run network3.exe from
DOS level and force a reanalysis. If after doing all of these
things, the board will still not call out, go to your network data and
delete BBSDATA.NET, BBSDATA.IND, and BBSDATA.ROU as well as CONTACT.NET
and rerun the NETWORK3 program which will force the reestablishment of the
deleted files. This will often cure the problem. If it does not, first
check your NETDAT0.LOG in GFILES to see if it provides any clue as to the
nature of the problem. If not, you should then contact one of the support
boards and explain your problem in full detail. The command line
NETWORK3 Y will force local feedback to be sent to you from the network
software. The resulting information may be useful in determining problems
in your network setup.
9.2. Your board calls out and gets a "Bad PW" message
The "Bad Password" message will show up in your net log which is
readable from WFC by pressing N. If that is the case and a successful
connection has never been made, then the remote sysop should ascertain
that the CALLOUT.NET is correct. If so, then check the CONNECT.x and
BBSLIST.x. If a successful connection has been made in the past and a
password between the two boards has been established, then try again as
line noise may be the culprit. If the "Wrong Password" persists over
several tries, then it is possible that a file has become corrupted. In
this event, both you and the remote sysop need to delete the password
which was generated by the network and let the net software reestablish
the password. If you have never successfully connected with the other
board, then the error may be due to the other sysop's not having setup
for the connection. You should contact him and ascertain whether or not
the connection if reflected in his CONNECT.xxx file or CALLOUT.NET
file. It may also be that a faulty connection caused his board to create a
password whereas yours did not.
9.3. Your board calls and gets a "NO NET" message
This occurs when an unsuccessful connection occurred. Often
it is only because the other board is busy. The remedy is to try
again. If the board is a new board and you know it is not busy,
then both you and the other sysop should make certain that all
files are in the proper places. There are several Binary files
created by the network. These are CONTACT.NET and BBSDATA.*.
Sometimes these files will become corrupted and this may be the
cause of a failure to establish a connection. You may delete
these two files from the DATA directory and then run NETWORK3.EXE
again. This re-analysis will recreate those two files and may
cure the problem. This problem (no net) may also occur when the
modems have connected but are not recognizing each other's signal.
It may be that one modem thinks the connection is at 14.4k whereas
the other thinks it is at 12k or something else.
10. FUTURE DIRECTIONS
In the near future, WWIV BBS software is likely to include
some of the following features:
REMOTE access by boards or users as a Sysop Selectable option.
This feature would be similar to the SNARF software sometimes used
as an external utility on WWIV boards. This option is currently
under development and will support direct calls from your board
to others in multiple networks using Zmodem and/or HSLINK and
using PcPursuit or normal connections. It will be capable of
utilizing the WWIV macro commands, will provide logging features,
and will provide the ability to send or receive specified files.
OFF-LINE READER(s) for users to download message bases, read and
reply while off-line and then upload responses. This feature seems
to be well-developed and is available through 3 QWK mail readers and
the WOMR for WWIV systems only.
Increased INTER-NetWorking among established networks. Although
this currently occurs under NET32 and v4.22 with WWIV-based networks,
this inter-networking is likely to be extended to other networks such
as FidoNet and/or UUCP net.
A change in the method of assigning node numbers. WWIV-based
networks have generally assigned node numbers that took advantage of
the fact that all US area codes had either 0 or 1 as a middle digit.
Thus, nodes 00 - 49 were indicated by using the first and last
digit of the area code as the first two digits of the node numbered
followed by 00-49 if the area code had a middle digit of zero and by
50-99 if the area code had a middle digit of one.
Growth in the number of US phones as well as a desire to maintain
compatibility with some international phone companies has led the
phone companies of the USA to announce that they will begin assigning
area codes having neither zero or one as the middle digit. Different
networks may handle this in different ways. WWIVnet has decided to
handle this by using a node numbering system whereby the group that
a 4 digit node is in is represented by the first digit of the node
number. A 5 digit node number will have the group as the first 2
digits. Node numbers will no longer reference the area code. Each
group will have a maximum limit of 1000 nodes.
One aspect of this future renumbering will be that the traditional
means of indicating the sub numbers available for a board to use ( see
Section 7.3) will no longer work well. This change will probably
mean that either some person(s) within each net must be made responsible
for subtype numbers or that widespread use of the sub-by-name concept
must be applied. Network coordinators and network administrators are
strongly encouraged to give this matter serious consideration and
sysops are alerted to the fact than a mandatory upgrade in WWIV and
network software may occur as a result.
Some of these developments will be due to the direct efforts
of Wayne Bell and others will be due to the efforts of programmers and
others who are dedicated to making WWIV the finest software available.
If you have questions about anything in these documents, you
should first ask your network administration for explanation or help. If they
do not know the answers, then contact Filo (1 @2050 WWIVnet, WWIVlink,
IceNET), and only as a last resort contact Wayne Bell (1 @1 WWIVnet or
1@3050 IceNET).
Because WWIV BBS software and network software are dynamic, growing,
and constantly improving, these docs will be updated from time to time.
11. APPENDICES
11.1 Appendix A - Macro Language
A macro is not normally needed for calling another BBS with the
network software. However, when it is needed for reasons discussed in
the body of the documentation, then it should be used. Use of a macro
is indicated by using a %x in the CALLOUT.NET with at least one space
following the node number and before the % sign. The x should be an
integer. In the network data directory, a file called Mx.NET should
be created which contains the macro. The x should be the same integer
as that used in the CALLOUT.NET. You may have several different macros
where they are necessary.
The network macros should have one of the COMMAND words listed below
on the left margin of the macro, followed by additional information within
quotes following the command line. See appendix B for an example for a
macro that might be used for a PcPursuit connection.
The commands supported are listed below in alphabetical order. It is
common to have DEBUG as the first line of the macro.
DEBUG -- This command should start the macro and should be followed by an
open and close quote (""). This will cause results to be echoed to the
screen.
DIAL -- This command causes the modem to dial whatever number that you
put there. (For example, DIAL "631-5841"). You can also use two replaceable
parameters with this command, %1 for area code and %2 for the 7 digit phone
number shown in BBSLIST.x.
FAILURE -- This command allows you to define a failure condition. Typically
the failure is "BUSY".
PARITY -- This command allows you to set the parity at something other
than 8N1.
SEND -- This command causes whatever is in quotation marks to be sent via
the modem. The information in quotes must end with a left brace ({) which in
the macro language indicates a carriage return. You can also use the send
command to dial the phone if yout put everything that must be provided to the
modem (for example, SEND "ATDT631-5841{" would cause the modem to dial the
number indicated.
SETBAUD -- This command allows you to set the baud rate for the call.
SPEED -- This command allows you to set the comport speed for the call.
SUCCESS -- This command allows you to define a success string.
TIMEOUT -- This command will cause the modem to pause for the number of
seconds indicated or until a WAITFOR condition has been met, whichever
comes first.
WAIT -- This command is similar to the TIMEOUT command except that the
modem or macro will wait the number of seconds indicated regardless of
any following WAITFOR condition.
WAITFOR -- Anything in quotes following this command will be the condition
that the macro waits for before continuing.
11.2. Appendix B - PcPursuit Macro
DEBUG "" {enables you to see what happens}
SPEED "2400" {speed you are calling at
DIAL "686-2452" {put your local PcPursuit Access #
TIMEOUT "7"
SEND "~@~D~{~D3{"
WAITFOR "@"
send "~D~{"
waitfor "NOT"
send "~D~{"
waitfor "NOT"
SEND "~C D/MOSLO/24,password,idnum{" {each city has its own code
TIMEOUT "7"
FAILURE "D/MOSLO/24 BUSY"
SUCCESS "ANSWER TONE"
WAITFOR "D/MOSLO/24 CONNECT"
SEND "~I{"
SEND "~ATZ{"
WAITFOR "OK"
SEND "ALT 5{" {see comment below
WAITFOR "HELLO"
TIMEOUT "30"
DEBUG ""
SEND "D%2{"
WAITFOR "DIALING"
FAILURE "BUSY"
WAITFOR "ANSWER"
The ALT 5 character referred to above can be made with an
ascii editor capable of using extended ascii symbols. The actual
symbol looks like the Club suit in a deck of cards, "the puppy
track". You can make this character by holding the alt key down,
pressing a 5 on the number pad and releasing the ALT key.
The macro above has been used successfully for PcPursuit
connections. The comments on the right side after the left brace
({) should not be typed; they are only partial explanations to
help you understand what the macro is doing. Note that each SEND
line ends with a left brace. In the MACRO script language this
signals a carriage return. In PcPursuit, each pursuitable city
has a city code. In the example above, MOSLOW is St. Louis,
Missouri. You would need a macro for each city that you call.
The %2 in SEND "ATDT%2" is the 7 digit phone number which the
macro will take from the BBSLIST data.
In conjunction with DIAL or SEND, you may use %1 for the
area code and %2 for the 7 digit telephone number. If you use
DIAL, you do not need to use the ATDT command; but with SEND you
need it.
Using the simple script language contained above, you can develop
elaborate scripts. In our area, we have written scripts that logged the
network onto QBBS and RBBS boards and selected Door programs which were
WWIV setups which in turn ran the network.
If you have trouble developing the scripts to use for a particular
application, you should be able to get help from any Support Board. You
will need a text file taken from a screen capture of what you are logging
into. Then the support board should be able to help you develop the
appropriate script for you to use.
11.3. Appendix C - Network message types
The network recognizes various types of major and minor type
messages, and these are often reflected during the analysis which
takes place after a network message is received. The information
which follows briefly explains each of these message types.
These types may be expanded in the future.
main type 1 - net info
(all type 1 msgs must be use method==1)
0 - feedback to sysop
1 - bbslist.net
2 - connect.net
3 - subs.lst
4 - wwivnews.net
5 - fbackhdr.net
6 - Additional wwivnews.net text
7 - categ.net
8 - networks.lst
main type 2 - email
(no method requirements)
minor type not used
main type 3 - post (from host to subscriber. numeric sub types only)
(no method requirements)
minor type is sub type
main type 4 - UNUSED
main type 5 - pre-post (from subscriber to host. numeric sub types only)
(no method requirements)
minor type is sub type
main type 6 - external msgs
(no method requirements)
minor type is external message type
main type 7 - email by name
(no method requirements)
minor type not used
(name of destination user at start of msg text)
main type 8 - net edit msgs
(email 1@3080 WWIVnet for a list of these)
main type 9 - subs.lst
0 - subs.lst
1 - subs.1
2 - subs.2
...
main type 10 - UNUSED
main type 11 - bbslist.*
(method must be 1 or ((minor_type % 256)+256))
0..255 - bbslist.
257..511 - bbslist.a
513..767 - bbslist.
main type 12 - connect.*
(method must be 1 or ((minor_type % 256)+256))
0..255 - bbslist.
257..511 - bbslist.a
main type 13 - unused
main type 14 - group info (from GC)
(method must be 257..511)
0 - email to sysop
main type 15 - ssm
(no method requirement)
minor type unused
main type 16 - sub add request
(no method requirement)
0 - sub by name, sub name first part of text
other - minor-type is sub-type
main type 17 - sub drop request
(same desc as 16)
main type 18 - sub add response
(same desc as 16 plus..)
first byte of text (after sub name, if any) is status of request
main type 19 - sub drop response
(same desc as 18)
statuses for 18&19:
0 - ok
1 - not host
2 - not there (can't drop you)
3 - not allowed to add/drop this sub
4 - already there (can't add you again)
main type 26 - post by name
(no method requirements)
minor type unused
sub type is first part of msg text
this is from subscriber to host, and from host to net
main type 27 - new external
(no method requirements)
minor type is external type
(see section
NOTE: all major type 1, 11, 12, and 14 messages are appropriately
source-verified.
Information for this appendix supplied by Wayne Bell, Random, 1@1
WWIVnet.
11.4. Appendix D - Identifiers Used in BBSLIST
< USRobotics HST protocol
> Hayes V-series protocol
| Telebit PEP protocol
! V.32 protocol
$ V.32bis protocol
/ Compucom 9600 protocol
? Fax modem
^ Area code coordinator
% Group coordinator
& Network Coordinator
+ Network Server
= PCPursuit connection(s)
\ FidoNet front-end
_ Dead-end node.
The identifiers above may be stacked together. For example,
"compatible and supporting v.32bis. This list will be expanded
from time to time as other hi-speed modems enter the network.
The identifier for dead-end node should not be used except
in emergencies. It is a means to force the network to treat a
node that would NOT normally be a dead end node as if it were
one in order to facilitate temporary re-routing of messages.
11.5. Appendix E - Using the Net Software for Private Networks
The network software may be used for any legitimate private
network as long as the user understands that the author is under no
obligation to provide the software which distributes network updates and as
long as the functioning of the private network does not interfere in any
way with the functioning of other WWIV-based networks. The author will
assume no responsibility for insuring the operation of any private
networks or any other network utilizing WWIVnet or WWIV software.
Further, the WWIV support board Sysops are under no obligation to
explain how to set up and/or operate a private network. Of course,
even for private networks, in order to continue using the WWIV network
software past the two month trial period, you must have either
registered WWIV, or (for BBS software that is in no way based on WWIV
software) registered the WWIVnet software. The NETUP software
developed by Wayne Bell and used by some networks for updating their
network files may be purchased for $300 by contacting 1@1 WWIVnet or
WWIV Software Services.
11.6. Appendix F - Automated subboard requests
Net29 and above support automated subboard subscriptions. In
order for this to work, BOTH systems (the host and the subscriber)
must be running Net29 or later. The program 'REQ.EXE' can be used
to subscribe or drop subboards.
There are some files associated with automated subscription under Net29,
Net30, and Net 31:
ALLOW.NET (in the DATA directory) - lists subboard types that are
under automated control. If you host sub type 1701, and you want
systems to be able to automatically subscribe to it, you would
have the number 1701 in the ALLOW.NET file. If a sub type is not
listed in the file, or the file does not exist, then sysops will
not be able to automatically subscribe to the subboard.
DISALLOW.NET (in the DATA directory) - lists system numbers that
are NOT allowed to automatically subscribe/drop subboards. If
you want to keep a certain system from subscribing to any of your
subs, place their system number in the DISALLOW.NET file.
SA*.NET (in GFILES directory) - This is a text file that is sent,
as part of a pseudo-email, to a sysop when they are added to a
sub. If you host sub 1701, then the file 'SA1701.NET' would be
appended as part of a piece of mail to the sysop that is
subscribed to the sub. It can give any rules of the sub, etc.
The DISALLOW.NET file may still be used with NET32 and higher.
SR*.NET (in GFILES directory) - If a system is not allowed to
automatically subscribe to a sub (if the sub isn't listed in the
ALLOW.NET, for example), then this piece of mail is appended to a
message informing the sysop that he cannot be automatically added
to the sub. The file should list why it isn't under automated
control, and if it would be worth the effort to email the sysop
and ask for it. This option also works with NET32 and higher.
The REQ.EXE program is very simple to use. You need to know only
if you want to add or drop the subboard, the sub type, and the
host. You then put all this info on a command-line, such as:
REQ A 1701 1
To REQuest an Add to type 1701 hosted by @1. To drop the sub,
you'd say:
REQ D 1701 1
You should get email back from the system when you are automatically
added/dropped from a subboard. You will get no mail back, and nothing
will happen, if the remote system isn't running net29 or later. If you
request to be added to a subboard that you don't have configured into
your system (in //boardedit), then when the response comes back
indicating you were added, the network will automatically request
that you be dropped from the subboard (since there is nowhere for
the messages to go), and you will NOT get an indication in feedback.
11.7 Appendix G - Multi-Networking with NET 31 and v4.21a
Beginning with NET31 and v4.21a of WWIV it is possible to network
among WWIV-based networks rather easily. The methodology for doing this is
discussed more thoroughly in the documentation for WWIV v4.22.
11.8 -Appendix H - USING HS/LINK WITH WWIV & NET32+
HS/Link WILL work properly on most WWIV systems using its
DEFAULT settings (NO HSLINK.CFG file). Put HSLINK.EXE in your main
BBS directory. Add a caret (^) to the desired lines in CALLOUT.NET and
have the systems you connect do the same (it must be present at BOTH
ends). Once this is down, if you have 103k free when the system
attempts a NET callout and HST protocol is NOT in use, it will use
HS/Link for the NET transfer.
This probably will NOT work if you are using PC Pursuit. (see
below)
For more information on using and optimizing HS/Link for WWIV,
download and read WWIVHSLK.ZIP which can be found on most Source
Distribution Systems, and many others. It may also appear under the
filename of HSLKWWIV.ZIP
=== Info for PC Pursuit users ===
The problem with PCP is that being a timeshare net, it does
not transmit data continuously, especially during busy times. There
may be delays in data transmission. If the HS/Link default block size
of 1024, or 4096 is used, and the default window of 8 is in effect,
HS/link will send 8 of these blocks before stopping for an
acknowledgment. If PCP is busy, this may be more data than it can
"swallow" in one gulp. Once PCP gets behind, it may have problems
recovering, in which case the data may or may not get thru. Even if it
does, the ACK may not get back to the sending end, in which case
HS/Link waits for it's internal timeout, before trying again. Often
PCP cannot recover at all, and HS/Link will finally abort the
transfer.
This problem can be resolved by using smaller blocks, and
smaller windows. A setting of 512 or smaller for the block size is
recommended, and a window of 4 should work fine. This will give PCP
smaller blocks of data, and HS/Link will stop more often to check that
the data has been received.
You can force these settings by creating a file called HSLINK.CFG
with your ASCII editor. It should contain only the following two
lines, and should be in the same directory as HSLINK.EXE:
-S512
-W4
CURRENT HS/LINK VERSION :
Be sure to use the LATEST release of HS/Link. While the current
version is always compatible with older versions, you will not get the
benefit of the latest enhancements and fixes if you are using an old
version.
LOG FILE
Starting with v1.13D0, HS/Link will create a logfile if the
environment variable HSERR is defined. To create a logfile called
HSLOG.TXT on your C drive in your Gfiles directory, just add this line
to your autoexec.bat file. SET HSERR=C:\GFILES\HSLOG.TXT HS/Link
will keep appending to this file, so you will want to provide some
means of erasing, renaming, and or zipping it in your nightly event.
=== CAUTIONS if using a CONFIG file ===
DOWNLOAD DIRECTORY (-U) :
This option controls the destination directory for incoming files. By
default, HS/Link will put incoming files into the "current" directory.
This is where WWIV is expecting to find them. WWIV changes to the
'TEMP' directory before receiving files. The BBS will move the files
to where they belong, so the -U OPTION SHOULD NOT BE USED for the BBS.
FORCE REMOTE TO USE LOCAL OPTIONS (-!)
This option causes the remote (called) end to use some of the options
specified by the calling end. This does NOT affect any of the options
having to do with security, such as the upload path, or the overwrite
option. It does affect block size (-s), xon/xoff (-hx), and windows
(-w). NET32 will append the -! option to the HS/Link command line for
outgoing calls, thus forcing the remote to use these settings for NET
transfers. Since it is not present on the command line for incoming
NET calls, the calling system will be able to use the settings that
are best for his phone lines. It SHOULD NEVER BE PRESENT IN THE CFG
FILE THE BBS WILL BE USING!
MINIMUM BLOCKS (-nm) :
Removes block numbers from each block, thus saving a few bytes. No
improvement in performance has been measured. It's effect is similar
to that of Ymodem-G, and the results can be catastrophic if an error
does creep in. This option SHOULD NEVER BE USED!
SLOW HANDSHAKE (-hs) :
Sends Xoff or lowers RTS during disk I/O. This causes the computer to
signal the modem not to send any data during disk I/O. It is available
for systems with slow disk access. It may help if you get frequent CRC
errors or COM overruns on clean lines. Be sure NOT TO DISABLE Xon/Xoff
HANDSHAKING IF THIS OPTION IS USED.
Information for this appendix supplied by :
Lance Halle 1@6211 WWIVnet
MOON VALLEY TRIANGLE Phoenix, Az.
602-942-9228 24 hrs
11.9 Appendix I -- Meaning of symbols in SUBS.XTR
11.9.1 You are reminded that you should not modify these directly.
Always use BOARDEDIT when making changes to this file.
11.9.2 Meaning of symbols
A typical entry in SUBS.XTR might look like this:
!8
@Novice & Veteran Sysops Helping Each other with WWIV
#0
$WWIVnet 22050 3 0
!x = The number of the Sub on the board (ie the sub index in BOARDEDIT.
@ = The long description for the sub (for auto-subs-info)
#0 = Flags (currently not used but for future expansion)
$NETWORK SubType Flags Host Category
Flags are 1 for auto-addrop, 2 for auto-info (3 for both).
Host is 0 if you are the host (you host it), otherwise the host system #.
Category will be an option that will permit the sysop to self-classify
a sub according to pre-defined categories, thus facilitating the maintenance
of network wide SUBS.LST type files. The categories will be listed in
CATEG.NET which will be found in the network data directory.
11.10 -- Technical Information regarding use of external message
Interface
Net33 (and later versions) will include a method whereby messages for external
programs can be transferred through the network. This does not describe how to
read network data files, or how to write net packets, only how to integrate a
program that does those things with the network. (see the WWIV source code, or
WWIVnet technical docs, for info on that.)
All received message packets that are destined for the local system are stored
into "LOCAL.NET" in your network data directory. The network2.exe program is
then run to process the messages. If any messages are of the "new external"
type (main_type_new_extern, 0x001b), then they may be saved for processing by
an external net program.
Each external network program requires a program (.exe or .com, NOT .bat),
which will take as parameters a filename of a network file (p*.net format), and
a network number identifier (.net_num). Each external network program can take
as input a contiguous range of minor_type's.
External network programs are described in the 'EPROGS.NET' which (optionally)
exists in the network data directory. The eprogs.net file is a text file, and
has a line describing one external net program per line. Each line has three
pieces of information: the program name (1-8 chars), the starting minor_type,
and the stopping minor_type. So, for example, if an external net program
'netprog.exe' is to handle main_type 0x1b, minor types 100-103, then the line
in the eprogs.net file for that processor would be:
netprog 100 103
(If the program handles only one minor_type, then the starting and stopping
minor_types should both be the same, and equal to the minor_type to be
processed.)
As local.net is processed, any main_type_new_extern messages encountered cause
network2 to search the eprogs.net file to see if any external net programs are
set up to handle that minor_type. If none are found, the net message is thrown
away. If there are two or more programs listed to process that minor_type,
only the first receives the message. Net messages accepted for an external net
program are stored to a temporary file while local.net has been processed.
After local.net has been completely processed, and deleted, network2 runs the
external net programs, in order, passing them the filename of the temporary net
file for that program, and an indication of which network is being processed.
After the program exits, the temporary net file is deleted.
Note that it IS allowable for an external net program to create a p*.net file
for outgoing messages, OR to put net messages to the local.net file which will
be immediately re-processed by the BBS.
Please do not blindly grab minor_types. If you need a lot of separate
message types, the message type can be stored in the text part of the message
and a single minor_type used instead.
There are also local.net pre-processors allowed in net32. The preprocessors
are listed in the 'epreproc.net' file in the network data directory, one per
line. BEFORE network2 processes ANY of local.net, each preprocessor is run, in
order, passing each the ".net_num" parameter to indicate which network is being
processed. The pre-processor may then scan through local.net, and mark as
deleted (main_type=65535) any message processed by that preprocessor. The
preprocessor may even append additional messages to the local.net file, if that
is desired.
Information for this appendix supplied by Wayne Bell (Random), 1@1 WWIVnet.
December 26, 2017
Add comments