home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
GEMini Atari
/
GEMini_Atari_CD-ROM_Walnut_Creek_December_1993.iso
/
files
/
bbs
/
fn132bin
/
fdman
/
chapter.08
< prev
next >
Wrap
Text File
|
1991-09-03
|
90KB
|
1,837 lines
Chapter 8: Networking 96
8 Networking
Fnordadel has the ability to __network__, that is, to share mail,
rooms and files, with other Fnordadels and other Citadels supporting
the ``C86Net'' style of networking. Since Fnordadel is a descendant
of Citadel-86, it retains compatibility with Citadel-86 networking (well,
mostly---see Section 8.6 [Networking with Citadel-86], page 121). Other
Citadel variants supporting C86Net include STadel (Fnordadel's immediate
ancestor), Citadel-68K for the Amiga, Fortress, and some others.
When two Citadels network, they follow a standard procedure. First,
one must call the other. Fnordadel can be induced to make net calls by
means of #events and #polling; read further in this chapter for more on
these. Fnordadel can also receive net calls from any system at any time
(assuming there's no user logged in, of course.) When two Citadels have
connected for the purposes of networking, they first must stabilize the
call, the caller (which starts out as the __master__) must identify itself,
and passwords, if you use them, must be exchanged. Then the caller makes
a series of requests; these can be for room sharing, file sending or
requesting, mail delivery, or whatever. After the caller has made all of
its requests, __role reversal__ is performed; this essentially makes the
caller and the callee switch roles in mid-call, leaving the callee as the
master and the caller as the __slave__. The callee now issues any requests
that it has to make in the same manner as the caller did. When the callee
is finished, the two systems hang up.
Simple, huh? Well, as it happens, this simple system has proven quite
flexible and useful; networking has become a fairly large part of Citadel
activity. So it's only natural that it's had a large amount of programming
effort devoted to it, and thus, a lot of stuff we've got to tell you about
it. So hang on to your hat, and off we go!
8.1 Networking Configuration
There is a whole whack of things that either need to be set or can be
set in `ctdlcnfg.sys' to control Fnordadel's networking ability. We divide
these into two groups: required parameters and optional ones. Please note
that there is no way to ``turn off'' Fnordadel's networking ability. You
may choose not to explicitly network with any systems, but other Citadels
will still be able to call yours and send you mail, at the very least.
8.1.1 Required parameters
These parameters *must* be defined properly in `ctdlcnfg.sys' for proper
networking to occur; indeed, Fnordadel will stubbornly refuse to come up at
all unless certain ones are defined. So define all these.
#nodename This is a string of 19 characters or less. It defines the
name by which your system will be known on the network. The
allowable characters in this string are:
o Upper and lower case letters
Chapter 8: Networking 97
o Digits
o Space characters (` ')
o Any of `* _ - .'
Spaces are equivalent to `_' (underscore) characters; therefore
`The_Rock' and `The Rock' amount to the same thing. (We
encourage the use of `_' rather than ` '; aside from our
entirely subjective opinion that it looks better, it also helps
when interfacing with other networks that might not support
spaces in nodenames.) We'd also like to recommend against using
`.' in your #nodename; it may cause confusion with domains in
later versions of the software.
We'd like it if #nodenames were kept to nine characters or
less; indeed, configur will preach at you a bit if you
define a #nodename with more than nine characters. This is
mainly because of mail routing considerations (see Section 8.5
[Mail Routing], page 118); explicitly addressing mail to
systems with long weird nodenames is a pain, and prone to
error. We'd prefer that you used a short #nodename together
with a descriptive #organization (see Section 8.1.2 [Optional
parameters], page 98.)
#nodeid This string, limited to 19 characters, defines the unique ID by
which your node will be known. It is used by the internals of
the networking software, so it will never be shown directly to
users.
What can this unique string consist of, you ask? Why, it's
no more than your telephone number. It must follow a strict
format:
<country code> <area code> <phone number>
Country codes are listed in Section 8.8 [Country Codes],
page 123. (Canada is `CA', and the United States is `US'.) The
area code and phone number are what you'd expect. Punctuation
(dashes, parentheses and so on) are allowed; they're stripped
when the string is actually used for anything. As an example,
the following is secret's #nodeid:
#nodeid "CA (403) 425-1779"
#define sharedrooms
This variable defines the maximum number of rooms which may be
shared with any one system on your net-list. The limit has
historically been 16; this value should be perfectly adequate
for most systems. If you're sharing a lot of rooms (say,
you're a major hub system), you'll want to put this higher.
Each shared room slot occupies 10 bytes for each node in your
net-list.
Once you've configured your system for the first time,
sharedrooms can only be changed by running nchange; see
Chapter 8: Networking 98
`nchange.man' for more. Do *not* simply change the value in
`ctdlcnfg.sys' and run configur; things will either come to a
screeching halt (if you're lucky), or blow up violently (if
you're not).
#netdir This is the directory in which Fnordadel will put all the files
needed in networking; these files will include `ctdlnet.sys'
(your net-list), `ctdlloop.zap' (the loop-zapper database; see
Section 8.4.3 [The loop-zapper], page 115), and many files of
a temporary nature. Make sure this directory is on a device
with some amount of free space (i.e., don't try to cram it
on a floppy which has 3k free) because the temporary files
written here can sometimes be fairly large if you do a lot of
networking.
Note that #spooldir is a synonym for #netdir.
8.1.2 Optional parameters
Many of these parameters are of the ``nice to have, but not absolutely
necessary'' variety. Fnordadel will try to use reasonable defaults where
applicable.
#organization
To make up for short #nodenames (see Section 8.1.1 [Required
parameters], page 96), you may define a string of up to 39
characters which will be used to provide a slightly better
description of your system in networked messages. It is
displayed at the end of message headers in shared rooms. For
example, let's say we're running a BBS called ``The Round
Table''. Now, this is longer than 9 characters, so we don't
want to use it as-is for a #nodename. So, we define #nodename
as `RT', which is easy to remember and type, and use an
#organization like this:
#organization "The Round Table, Edmonton"
The headers on messages from our board will appear like this:
90Jul20 8:24 pm from Biff @ RT (The Round Table, Edmonton)
The #organization field can say anything, really; some people
like to put witty little sayings in there or whatever. Just
keep it clean.
#domain The #domain field tells the system what Citadel-86-style domain
your system belongs to. A domain is a group of network systems,
usually organized by geographical region, but the grouping could
be based on anything at all. If you don't know what domain
you're a part of, leave this field commented out or define it to
be the empty string (i.e. #domain ""). You can set the field
later.
This field is primarily for Citadel-86 compatibility, which uses
state or province abbreviations as domains. Ask around your
Chapter 8: Networking 99
area to see if a domain exists, and join it if so. If not,
start your own, or join a domain from another region. Please
don't put a junk value in this field; leave it blank unless
you're joining or starting a real domain. See Section 8.5.4
[Domains], page 121.
If you define a domain, it will appear in the headers of
messages originating on your system. The domains of other
systems will appear in message headers from those systems.
Continuing the example from above, with system RT, if we define
#domain as `Alta', message headers will look like this:
90Jul20 8:24 pm from Biff @ RT.Alta (The Round Table,
Edmonton)
#define receiptk
#receiptdir
Since Fnordadel can accept files sent from other systems on the
network, we have to tell it how much we're willing to accept,
and where to put these files.
The variable receiptk should be defined as the number of
kilobytes which will be allowed to accumulate in your receipt
directory before Fnordadel will refuse to accept any more files
over the network. Notice that this really doesn't have anything
to do with the amount of free space available on your storage
device, though obviously if you run out of space, files will
not be received. What actually happens is that prior to the
receipt of a file, Fnordadel will add up the sizes of the files
currently in your receipt directory and compare the number with
your defined receiptk; if the addition of the new file would
cause the total amount of used space to exceed receiptk, then
the file will be refused. The upshot: clean out your receipt
directory after you receive files from other systems.
#receiptk defaults to `100'.
#receiptdir is, as you'd expect, the name of the directory in
which to put received files. If you do not define it, it
defaults to #netdir.
#define allnet
This simple binary switch tells Fnordadel whether you want to
give out net privs to all new users. If set to `1', all
users will be given net privs when their account is created;
when set to `0', the Sysop must explicitly grant net privileges
individually (see Section 5.2 [User Status Commands], page 80).
See [N]et-save in Section 3.4 [The Message Editor], page 52,
and .E(nter) N(et-message) in Section 3.2.1.1 [Multi-key message
entry commands], page 35, for a description of what the
possession of net privs allows a user to do and how. See also
`flipbits.man' for a description of a utility to set the net
privilege flag for all users en masse.
Chapter 8: Networking 100
#define netlog
#define netdebug
These two binary switches set Fnordadel defaults for network
logging and debugging. If set to `1', then the
logging/debugging is automatically turned on when you run
Fnordadel. See Section 13.2 [Logging and Debugging], page 152.
#define zaploops
This binary switch tells Fnordadel to enable or disable the
loop-zapper. The loop-zapper is used to control __vortexes__
in networked rooms; that is, the phenomenon whereby erroneous
backbone connections somewhere along the network result in
duplicate messages being sent to your system. See Section 8.4.3
[The loop-zapper], page 115. Suffice it to say that setting
zaploops to `1' will enable it; to `0' will disable it.
The citadel command line switch `+zap' is another way to enable
the loop-zapper.
#define purgenet
This binary switch, if set to `1', tells Fnordadel to use its
message purge feature on incoming network traffic, as well as
locally-entered messages. For more information on the purge
feature, see Section 10.2.10 [Message purging], page 137. In
a nutshell, the feature lets Fnordadel automatically delete
messages from undesireable users or entire net nodes, which you
specify. Use with caution.
#define keepdiscards
This binary switch controls Fnordadel's treatment of incoming
net messages that are discarded, either by the loop-zapper (see
Section 8.4.3 [The loop-zapper], page 115) or the message purger
(see above). If set to `1', the flag instructs Fnordadel to
keep discarded messages in the #netdir, for you to look at
later. At that time you may do such things as delete them or
integrate them into the message base. See Section 8.2 [The Net
Menu], page 104, for more details on the commands to handle
discarded messages.
If the flag is set to `0', messages discarded by the loop-zapper
or message-purger are lost forever.
#define forward-mail
Another switch. If set to `1', it tells Fnordadel to allow mail
to be forwarded through your system to others. If, for some
reason, you want to disallow mail forwarding, set forward-mail
to `0'. See Section 8.5 [Mail Routing], page 118.
#define anonnetmail
This binary switch, if set to `1', allows your system to receive
net-mail from systems that are unknown to it. This is the
default behavior of the system. If you have unwanted volumes
of mail being dumped on you by mystery nodes, you can set this
parameter to `0' and Fnordadel will reject netmail from unknown
systems thereafter.
Chapter 8: Networking 101
#define anonfilexfer
This binary switch is like the one above, but controls file
transfers with anonymous nodes. If the flag is set to `1', file
transfers to and from unknown nodes are permitted. If set to
`0', they are prevented.
#define pathalias
Here's yet another binary switch; when `1', it enables
Fnordadel's path aliasing capability. See Section 8.5 [Mail
Routing], page 118.
#hub This is a string variable which should be set to the nodename of
the system to which undeliverable mail is to be forwarded (which
system, hopefully, will be better equipped to deal with it than
yours is.) See Section 8.5.3 [Hubbing], page 120, for more
information on #hub.
#define ld-cost
#define hub-cost
These integer variables define the cost, measured in ld-credits,
of using the Fnordadel long-distance mail routing and hub
forwarding facilities, respectively. Ld-credits are given to
users by the Sysop (see Section 5.2 [User Status Commands],
page 80, for how to do so), and control who can send mail that
costs you money.
8.1.3 Setting up for networking
Networking proceeds in one of two ways: your system can call another
one, or other systems can call yours. Usually you'll do both, for local
network connections; for long-distance ones, you'll want to make specific
arrangements. There are two mechanisms for achieving networking: events,
and polling.
8.1.3.1 Network events
If you don't know about events yet, go read Chapter 7 [Events],
page 93. As they relate to networking, events allow you to schedule
network sessions, during which your BBS will presumably call other systems
(or be called by other systems) for the sole purpose of networking.
The format of the event definition is laid out in Section 7.1 [Events in
General], page 93; here we present an example only, with a couple of points
of note:
#event NETWORK all 3:01 39 ld-net 1
The above line will set up a network event which goes off at 3:01 in the
morning, lasting for 39 minutes; it will be named `ld-net'; and it will
apply to network #1. This means that your system will call only those
nodes that are part of net #1 during this session, though calls *from* all
systems will be accepted.
Chapter 8: Networking 102
During a network event, the BBS is closed to the users. If a user
connects, he will, after a delay, be shown a message to the effect of ``The
system will be in net mode for xx minutes longer; call back later.'' If a
user is logged in before an event is scheduled to go off, he will be warned
five minutes beforehand that he'd better terminate quickly. When the event
arrives, he will be booted unceremoniously.
Upon commencing a net event, Fnordadel will call all systems in the
specified net for which there is outgoing material. In addition, you can
configure things so that certain nodes will be called whether there is
work or not; this is known as ``polling''. (Note that this is different
from #polling, detailed in Section 8.1.3.2 [Polling], page 102, below; we
really must change the terminology...) See the [F] command in Section 8.3
[Editing Nodes], page 107.
Note that the event will always last the specified number of minutes,
whether the BBS has finished calling systems or not. Indeed, you may want
to set up a net session for the sole purpose of reserving a time slot for
other systems to call yours. (As we've mentioned before, Fnordadel can
receive network calls at any time, whether it's in a network event or not.
But setting up an event ensures that no user will be logged in.)
8.1.3.2 Polling
__Polling__, in this context, refers to the ability of Fnordadel to
dynamically enter network mode whenever there is outgoing work and the BBS
has been idle for a set length of time. This allows greater flexibility
than does the network event mechanism.
Essentially, we must tell Fnordadel the time periods during which we
want polling to be active; we must also tell it the required length of idle
time before systems will be polled. The syntax of the #polling definition
is as follows:
#polling <net> <start-time> <end-time> [days]
The fields mean:
net The net number to poll (usually 0).
start-time
The time (in 24-hour format) to start polling.
end-time The time to end polling.
days An optional field which is either `all', or a comma-separated
list of days, as in `Mon,Wed,Fri'.
Most systems that engage in any local networking put a fairly standard
#polling line in:
Chapter 8: Networking 103
#polling 0 0:00 23:59 all
This causes the BBS to poll network number 0 all day long.
You can also define more than one #polling duration; for example,
#polling 1 4:00 20:00 all
#polling 2 20:01 3:00 all
will cause net #1 to be polled from 4AM to 8PM, and net #2 to be polled
from 8:01PM to 3AM.
If you've got any #polling defined, you'll also want to define the
variable poll-delay. This is the length of time, measured in minutes, for
which the BBS must be idle before Fnordadel will start polling. A decent
value (or, at least, what we use) is around 15 minutes.
8.1.3.3 Summary of network events and polling
Most systems that engage in only local networking find that #polling is
perfectly adequate for decent propagation times; setting up network events
is usually unnecessary. Of course, if you've got users calling within
30 seconds after the previous one hangs up, you won't get much polling
done; but we've never seen a system that doesn't have idle time scattered
throughout the day.
If you do any long-distance networking, you'll probably want to use
a mixture of network events for the long-distance stuff and polling for
the local stuff. It would be distinctly unwise to set up polling for
nets containing long-distance systems; you don't want your board calling
cross-country every time someone enters a message in the applicable shared
rooms, do you? Instead, set up an event during the wee hours of the
morning, and get all the long-distance networking done then. You might
want to coordinate things with your long-distance connection; if both of
you jump into a network event at the same time, things will go quicker.
8.1.3.4 Special keys in network events
There are a couple of special keys that you can hit while Fnordadel is
in a network event to make it do things. You can use these only when
Fnordadel isn't in the middle of an actual net call.
`^Z' __Take Fnordadel to the background__. If you run Fnordadel
under some sort of multitasker, hitting `^Z' while in a network
event causes the same thing as when you hit it any other
time---it causes Fnordadel to drop into the background. See
Section 13.6 [Multitasking and Fnordadel], page 165.
`Q' __Quit Fnordadel__. Hitting `Q' while in a net event causes
Fnordadel to exit completely, after confirmation. This is a
good way to stop the system from calling those long-distance
systems 100 times during the day.
Chapter 8: Networking 104
8.1.4 Related parameters
There are a few other parameters that aren't strictly networking
parameters, but which will cause you networking grief if they aren't
defined properly. They have to do with your modem; see Chapter 6 [Modem
Stuff], page 86, for detailed descriptions. Ones to watch:
#define usa
#define local-time
#define ld-time
8.2 The Net Menu
The Net menu hides under the Sysop menu, which is reachable by hitting
`^L' at a room prompt. (See Section 5.1 [Sysop Special Functions],
page 75, for more on Sysop commands.) If you hit `N' at the `sysop cmd:'
prompt, you'll be in the Net menu, from which you can choose one of the
following commands:
[A]dd node
[D]iscarded messages
[E]dit node
[F]orce poll to node
[P]oll network
[R]equest file
[S]end file
[V]iew net list
e[X]it to sysop functions
[A]dd node
This command allows you to add new nodes to your net-list; you
must add a node to your net-list before you can send *anything*
to it.
You will first be asked for the node's name; type its nodename
(the hopefully short name by which the other node is known.)
If the system is a Citadel-86, it probably has a long and
twisted name, so make sure you've got it spelled correctly, or
things like mail routing, auto-reply to incoming net-mail, and
other stuff won't work quite right. Names will never exceed 19
characters, in any case. Then, it'll ask you for the node ID
of the new system. This is the node's phone number; it is,
obviously, vitally important to get this right. It should be in
the same format as your own #nodeid (see Section 8.1.1 [Required
parameters], page 96).
Next, you'll be queried about the baud rate supported by the
new node; enter the standard baud rate code (`0' is 300, `1'
is 1200, `2' is 2400, `3' is 9600 and `4' is 19200). Use
the highest baud rate supported by the other node, even if
it is higher than the highest baud rate that yours supports.
Fnordadel is smart enough to pick the lower of the two when it
dials out; and this way you don't have to edit your net-list if
you happen to acquire a faster modem.
Chapter 8: Networking 105
Lastly, Fnordadel will ask you whether the system is a
long-distance node or not. Make sure you tell the truth here;
this setting affects a number of things, including the method
by which dialout is done. (See Section 6.2.4.2 [Long-distance
dialing], page 91.)
The rest of the settings for the new node will default to
(hopefully) reasonable values. In some cases you'll have
to immediately edit the node to set other things like net
passwords, Citadel-86 status, and so on.
[D]iscarded messages
This command gets you into a small sub-section where you can
view and deal with incoming net messages that were zapped
or purged by your system, if you configured things to save
such messages. (See Section 8.1.2 [Optional parameters],
page 98, for the way to configure this; see Section 8.4.3
[The loop-zapper], page 115, for details on the loop-zapper;
and see Section 8.1.2 [Optional parameters], page 98, and
Section 10.2.10 [Message purging], page 137, for details on the
message purge feature.) After hitting `D', the system will
either tell you there are no discarded messages, or it will tell
you the number of discarded messages, show you the first one,
and then give you the following prompt:
[A]gain, [D]elete, [I]ntegrate, [N]ext, [S]top:
[A]gain Redisplay the current message and prompt again.
[D]elete Delete the current discarded message, if you confirm
your desire to do so, and advance to the next
discarded message, if there is one.
[I]ntegrate
This is the interesting command. If you confirm the
action, this tells Fnordadel to integrate the current
discarded message into your message base as though it
had never been zapped or purged. It will be passed
along to any backbone systems sharing the room, just
as it normally would have been.
You might run into difficulty if the message was
in a room that no longer exists on your system, or
whose name has been changed. The same is true if
the message came from an STadel or derivative, and
the room is aliased there to something other than
the name in use on your system, or if the room is
aliased to a different name on your own system (see
Section 8.4.4 [Shared room aliasing], page 117). In
any of these cases, Fnordadel won't know where to put
the message now, so it will ask you if placing the
message in the Aide> room is okay. Once it's there,
you can move it. If you don't okay the placement in
Aide>, nothing is done.
Chapter 8: Networking 106
If the message is successfully integrated into a
room, you will be asked if the discard message file
should be deleted, and then shown the next discarded
message, if there is one. If the message is
not integrated, you will be returned to the discard
prompt.
[N]ext Take you to the next discarded message, if there is
one.
[S]top Stop the discard message processing and return you to
the net commands menu.
[E]dit node
This command takes you to the net node edit sub-menu. See
Section 8.3 [Editing Nodes], page 107, for an in-depth look.
[F]orce-poll node
This is a quickie command for forcing Fnordadel to make a single
net call to another system. Supply a system name, and Fnordadel
will call the system regardless of traffic pending, receive-only
status, l-d status or anything else.
[P]oll network
This command allows you to force a one-time poll of the
specified network. If anyone is logged in at the time, they
will be immediately terminated (with extreme prejudice, we might
add) and Fnordadel will call all nodes in the specified net for
which there is work.
[R]equest file
Use this command when you wish to get some files from some
system with which you network directly. You'll be asked for
the system from which to request files, the room on the other
system from which to get them, the filename(s) to get, and the
directory on your system in which to place the received files.
The room on the other system must be ``network readable'' (see
Section 8.4.1 [How to share a room], page 112) for the request
to work. You may use wildcards (`*' and `?') in the filename
specification.
The file request will be spooled for later; the next time
your system connects with the other one, the request will be
made and, if the other system can oblige, the files will be
transferred.
Note that it is possible to request files from a system with
which you have not previously networked. Simply add the node to
your net-list in the standard manner, and `[R]equest' the file
as usual---the other node doesn't have to know about yours. (We
use this in the distribution of Fnordadel; any other node can
call us and request new versions, assuming they know the name of
the room and the filenames. See Appendix A [Fnordadel Support],
page 170.)
Chapter 8: Networking 107
[S]end file
This command allows you to send a file or files to a node
with which you network directly. You'll be asked for the
target node name and the name(s) of the file(s) to transfer; you
should provide the full path-spec, and wildcards (`*' and `?')
are permitted. The sendfile will be spooled for later; the
next time your system connects with the other one, the sendfile
will be made, subject to space availability on the other system.
If there wasn't enough space, the other node will say so and
you'll get a message in Aide> to this effect. You will have to
re-enter the send command once the remote system has corrected
its space problems.
[V]iew net list
This prints out a nicely formatted list of all the nodes in your
net-list. The format is as follows:
* sysname CA 403 432 1098 CRMF 2400 0,1
^ ^ ^ ^ ^ ^
| \ | | | |
"need the name of the nodeId various baud |
to call" the node (phone number) flags rate |
flag |
|
nets to which the node belongs
The ``various flags'' may consist of one or more of the
following:
`C' The system is a Citadel-86
`R' The system is receive-only (i.e., your system will
never call it)
`M' There is mail pending
`F' There are file sends/requests pending
The ``need to call'' flag (the leading asterisk) appears if
there is any work pending for the node; it doesn't mean that
your system will call the node, because the node may be set to
receive-only. (See Section 8.3 [Editing Nodes], page 107.)
e[X]it to sysop functions
This should be blatantly obvious.
8.3 Editing Nodes
There is a sub-menu under the Net menu (which is itself a sub-menu under
the Sysop menu; see Section 8.2 [The Net Menu], page 104) which allows
you to edit various things pertaining to nodes in your net-list. Nodes
must obviously be added to the list before they can be edited, using the
[A]dd node command; again, see Section 8.2 [The Net Menu], page 104. The
commands on the node edit menu are as follows:
Chapter 8: Networking 108
[A]ccess setting
[B]aud setting
[C]- set receive-only status
L[D] role reversal
[E]xternal dialer setup
[F]- set polling days
[I]D change
[K]ill node from list
[L]ocal setting
[N]ame change
[P]assword settings
[R]ooms shared
[T]oggle Cit-86 status
[U]se nets
[V]iew node configuration
e[X]it net editing
[Z]- set l-d poll count
[A]ccess setting
An access string is an alternate way of dialing a system.
Normally, the dial command for the modem is formed by taking
the last seven digits of the node ID (for local systems), or
the full ten digits, i.e., including the area code, prefixed by
a `1' (for long-distance systems), and sandwiching this between
the dial prefix and the dial suffix. (This all assumes that
you've got #usa defined in `ctdlcnfg.sys'; see Section 6.2.4
[Dialing out], page 90, for more on this stuff.)
But if you specify an access string, Fnordadel forgets all of
the above, and simply spits the access string at the modem
(still sandwiched between the dial prefix and suffix.) You'd
use this if you're dialing a country other than Canada or
the USA, for instance, or if you're dialing a system which
is long-distance but within your area-code. (Some telephone
systems don't like it if you dial 1-areacode-number within the
areacode.) Because the string is used as-is, you can embed any
special dialing commands that your modem supports, like `,' to
pause the dial or whatever.
The access string is also used as a command line to pass to an
external dialer that you may have set up for this node; see
below.
[B]aud setting
This allows you to change the node's baud rate. The acceptable
values here are the same as elsewhere in Fnordadel: `0' is 300
baud; `1' is 1200 baud; `2' is 2400 baud; `3' is 9600 baud; and
`4' is 19200 baud. Note that Fnordadel will never attempt to
call out at a baud rate higher than the highest rate supported
on your system; so it's perfectly safe to list a system at 19200
baud if you're only running on a 2400 baud modem; one day, you
too may have a 19200 baud modem, and when you do, your BBS will
be ready for it!
Chapter 8: Networking 109
[C]- set receive-only status
A node can be set to __receive-only__, which means that
Fnordadel will never dial out to it, even if there is work
pending for that system---you'll have to wait until the other
system calls yours.
If you're entering nodes into your net-list for the sole purpose
of dialing out to them manually using the [T]elephone command,
(i.e., they aren't Citadels), then set receive-only status to
prevent an accidental network callout.
L[D] role reversal
This is somewhat of an outdated command; it allows you
to specify whether role-reversal will be performed with this
(presumably long-distance) system. It defaults to Yes, so you
should never have to muck with it.
[E]xternal dialer setup
Fnordadel allows you to define an external dialer for each net
node; that is, a program which will do the work of dialing and
connecting with the system. The main use for this is if you're
using some sort of service like PC-Pursuit, or a packet-switched
network, or whatever. When using this command, specify the
external dialer number; Fnordadel expects to find the external
dialer programs in your #netdir, named `dial_n.prg', where n is
the dialer number. If you have an external dialer set for a
node, it will use the access string as the command tail to pass
to the dialer.
So, say you're using PC-Pursuit. You've taken the PC-Pursuit
dialer program and put it in #netdir as `dial_1.prg'. You've
set the external dialer (using the [E] command) to "1". You've
set the [A]ccess string to `-x foobar'. When Fnordadel dials
this node, it will run the program so: `#netdir\dial_1.prg -x
foobar'. When the dialer program finishes, there should be a
carrier present and the baud rate should be set up correctly,
assuming the call connected. Fnordadel will then proceed with
networking as normal.
[F]- set polling days
Despite the fact that this command has the word ``polling'' in
it, it in fact has nothing to do with #polling (the ability to
make net calls at any time.) Rather, this command lets you
specify the days on which the net node will be called *whether
there is work pending or not*. The calls will still happen
only during applicable network events. This allows you to, say,
regularly call a long-distance network feed to pick up stuff,
even when there is no outgoing work pending.
The format of the days specification is any of `Mon', `Tue',
`Wed', `Thu', `Fri', `Sat' and `Sun', separated by commas. So
`Mon,Wed,Sat' is a valid specification. (This format is the
same as that used in the #event and #polling definitions; see
Section 8.1 [Networking Configuration], page 96.)
Chapter 8: Networking 110
[I]D change
When a system with which you network changes its phone number,
you'll have to make the change in your net-list, and this is
how. Just enter the standard node ID format:
<country> <area code> <number>
as in `CA 403 425 1779'.
Note that if you change the node ID of a system, the loop-zapper
records for that node will be invalidated. The loop-zapper will
pick up the change as a matter of course (it will look like a
new system, as far as the loop zapper is concerned), so this
isn't a problem or anything.
[K]ill node from list
This command will remove a node from your net-list. Simply
type its name; Fnordadel will ask you for confirmation before it
kills the node.
Currently Fnordadel does not unshare all the rooms that this
system was sharing; you must do so manually before using this
command, or things may screw up later on. (Edit the room
and type `U'; see Section 4.2.1 [Sysop room-editing commands],
page 70, and Section 8.4.1 [How to share a room], page 112.)
The confirmation prompt will remind you of this fact, in case
you forgot.
[L]ocal setting
This command is for telling Fnordadel whether this system is
long-distance (i.e., out of your local calling area) or local.
You do want to be accurate with this; don't fib.
[N]ame change
If the node has changed its nodename, you'll want to make the
corresponding change in your net-list to keep everything working
smoothly. Just type in the new name.
[P]assword settings
If you suspect security problems when networking with this node,
then set the passwords. They must be agreed upon by you and
the other Sysop beforehand. You'll define the password that
your system uses when calling the other one, and the password
that your system should expect from the other when it calls you.
They may be the same, though for optimum security you'd want
them different.
Please note that Citadel-86 systems use a different form of net
passwords, and therefore you must tell Fnordadel that this node
is a Cit-86, or passwords will not work. See [T]oggle Cit-86
status, below.
[R]ooms shared
This command prints out a list of the rooms that your system is
sharing with this node. Rooms with messages that need to be
sent to the node are flagged with an asterisk.
Chapter 8: Networking 111
[T]oggle Cit-86 status
Actually, it's not a toggle, but [C] was taken. Anyway, if
the node is a Citadel-86 system, you should tell Fnordadel
so by using this command. The value of this flag is
checked for things like file requests, network protocol changes,
and net passwords, so it is essential to turn the flag on
for Citadel-86es. Note that direct Cit-86 derivatives like
Citadel-68k for the Amiga are functionally identical to Cit-86
(as far as networking goes) so you must turn this flag on for
them as well.
[U]se nets
Fnordadel uses the concept of __net numbers__ to form logical
groups of systems. When you first enter a net node into your
net-list, it defaults to being a member of net number 0. But
you can set it up so that it's a part of a different net,
or several nets at once---valid net numbers are from 0 to 31.
These net numbers are referred to in network event definitions
(a node must be part of the net to which the net event applies
for Fnordadel to call the node during the event) and in polling
(which applies to specific net numbers). You may also remove a
node from all nets; this has the effect of removing it from the
standard list of valid net nodes printed out when a user hits
`?' when asked for the target system of a piece of net-mail; and
also removes it from consideration when the system is trying to
route net-mail (see Section 8.5.2 [Path aliasing], page 119).
The format of the [U]se nets specification is as follows: To
add a node to some nets while preserving the current settings,
use `+netlist'. To remove a node from some nets, use
`-netlist'. To specify a totally new set of nets, just use
netlist. What's a netlist, you ask? It's just a series of net
numbers delimited by commas or spaces. For example, if the node
is currently in net 0 and 2, and you wish to add it to net 5,
type `+5' when asked for the nets you want to use. To remove a
node from net 0 (the default net), type `-0'.
[V]iew node configuration
This command prints a quick summary of the settings for this
node.
e[X]it net editing
This exits back to the Net menu.
[Z]- set l-d poll count
You can tell Fnordadel how many times you'd like it to attempt
to call an l-d system during an event before giving up, hence
this command. Normally the system will be called until
Fnordadel obtains a carrier, and then will not be called again
during that session, whether the call was a complete success or
not. This command overrides that; just specify the number of
calls.
Chapter 8: Networking 112
8.4 Roomsharing
For most systems, the primary purpose of networking is to share rooms.
Rooms designated as shared (or ``networked'') by the Sysop will have all
messages entered in them sent to the systems with which he has shared the
room; the other systems have, presumably, set up the same thing, and so
you end up with a sort of super-room spanning several BBSes. (There are
zillions of little exceptions and modifications to the above description,
which we'll let you discover for yourself.)
8.4.1 How to share a room
To make a room shared, you need to edit the room. This is accomplished
by .A(ide) E(dit) while in the room in question; you must have Aide status
(and be logged in, naturally) to use this. In this menu you'll find
a few useful commands, detailed here. (For more on the room edit menu,
see Section 4.1.2 [The .A(ide) command], page 63, and Section 4.2.1 [Sysop
room-editing commands], page 70. These are the commands we're interested
in here:
[S]hared
[U]nshare
[Y]- toggle backbone status
[N]et readable
[Z]- autonetted room
[P]ermanent
[S]hared Use this command to make a room shared to start with, and also
to add new systems to the shared list for this room. When you
hit `S' you'll be asked if you want to make the room shared;
answering ``no'' will make the room not shared and return to the
menu. (If the room was shared before, it will still be made
unshared, but no nodes will be removed from the shared list for
the room. This may cause strange behavior, so be careful.)
If you answer ``yes'', Fnordadel will ask for a list of net
nodes with which to share the room. Typing a `?' will list
the choices available to you; systems must be in your net-list,
obviously, before you can share a room with them. Simply enter
the name(s) of the nodes, one at a time, with which to share the
room, and enter a `<CR>' with no node name at the prompt to
finish.
[U]nshare Use this command to remove one or more systems from the sharing
list for this room. Simply type their name(s), one at a time,
and finish with a `<CR>' at the prompt. If you want to make
the room completely unshared, i.e., not a network room any more,
use this command to disable each node currently connected to the
room. Then use [S]hare, and answer ``no'' to make the room
non-networked.
[Y]- toggle backbone status
This command lets you turn backboning on or off for one or more
nodes with which the room is being shared. See Section 8.4.2
[Topography and backboning], page 113, for more on backboning.
Chapter 8: Networking 113
[N]et readable
This command tells Fnordadel whether files can be requested from
this room over the network. It has no effect if the room is
not a directory room, obviously. If you set the room to be not
network readable, then any and all file requests for this room
will be refused.
[Z]- autonetted room
In a normal shared room, messages are only saved as Networked
messages if the authors have net privileges; this can, however,
be overridden using the __autonet__ feature. If a room is
autonet, all messages entered in it are saved as net messages,
regardless.
Use this with caution. Especially if the room is a
long-distance networked room, you could be in for a rude shock
if a ruggie phones and dumps a load of rubbish into it---you'll
pay to send it all out over the net, and all the other systems
sharing the room will likely be very peeved.
[P]ermanent
This is not strictly a networking option, per se, but it rates
a mention. If a room is shared, you'll likely want to make it
permanent to stop Fnordadel from automatically expiring it if
it empties of messages. (Say, if you haven't managed to call
the feed for a while, or whatever.) Other systems tend to get
peeved if shared rooms start dropping off your system without
any advance warning, since their Aide> rooms will fill up with
warnings when they attempt to resume sending messages.
8.4.2 Topography and backboning
The standard room sharing method, used for most local connections, is
for every system carrying a given room to share the room with all other
systems carrying it. This kind of arrangement would look like this:
---NodeA--- Every system is sharing the room
/ | \ with every other system.
NodeB------)-----NodeD
\ | /
---NodeC---
The main advantage in this setup is that it's quite robust. If a system
suddenly drops off the net, it won't disrupt anything (topography-wise,
that is; people will probably notice, but it won't necessitate any change
in the room sharing method.)
However, it's not very efficient in terms of aggregate time spent doing
networking. Whenever there are new messages in the shared room, each
system has to call all the others. In addition, this method is totally
insane if the systems are not local to each other, or if there is a large
number of systems sharing the room. So, backboning was invented.
Chapter 8: Networking 114
Backboning allows network messages to be passed on to another node even
if they weren't entered on your system. More specifically, if you turn
backboning on for a given system, say foobar, in a given room, all messages
received by your system (except from foobar itself, of course) in that room
will be sent out to foobar, in addition to all messages entered locally on
your system.
What this does to the net map is allow much greater flexibility in
connections. First, here is an example which employs a central hub system
with lots of little ``spokes'':
NodeI NodeB NodeC NodeA shares the room with
\ | / all systems, while all the
\ | / other systems share the
NodeH----NodeA(Hub)----NodeD room only with NodeA. NodeA
/ | \ turns backboning on for all
/ | \ systems; the other systems
NodeG NodeF NodeE do not use backboning.
This arrangement will basically shift the bulk of the net load to NodeA.
The other nodes will not know that any backboning is going on; they
will simply share the room in the standard manner with NodeA. NodeA is
responsible for passing all of the other systems' messages on to all the
other systems by turning on backboning.
This works pretty well in local situations, and in long-distance
situations where the cost of calling NodeA is not much different than
calling any one of the other nodes. No node is ever more than two hops
away from any other, and so propagation times are good.
In local situations you might want to use this arrangement to reduce
the aggregate time spent in net mode by concentrating it on NodeA; the
other systems will only have to make one net call every time new messages
are entered, instead of many calls. However, you've probably noticed a
drawback---if NodeA ever disappears, the sharing scheme has to be redone,
possibly by promoting one of the other systems to be the hub.
In long-distance situations, there are often more cost-effective ways of
arranging things. Here's another example:
NodeC NodeH Nodes B, C, F, G and H
\ / share as normal;
\ / Nodes A, D, and E flag
NodeA---NodeD---NodeE---NodeG all other systems as
/ | backboned.
/ |
NodeB NodeF
This arrangement allows NodeG, for example, to net with NodeE instead of
a (possibly more distant) hub like NodeD. It allows Nodes A, B and C to
rely on NodeD for their feed (we assume in this example that A, B, C and
D are all local to each other.) (In this case, it would be nice if the
Sysops of A, B and C helped with NodeD's phone bill.)
Chapter 8: Networking 115
There are many variations on the above examples; the guiding rule is
that if you wish to pass messages on to another system, turn backboning on
for that system. But be *very very* careful that loops are not introduced
in the net topography, or you'll have a ``vortex''.
NodeC NodeH Nodes B, C, F, G and H
/\ / share as normal;
/ \ / Nodes A, D, and E flag
NodeA--NodeD---NodeE---NodeG all other systems as
/ | backboned.
/ |
NodeB NodeF
This modification of the previous example illustrates how a vortex can
happen. NodeA and NodeD are each backboning a room to all their net
connections. NodeC incorrectly decides to share the room with both NodeA
and NodeD. Thus, every message entered on NodeC is sent to both NodeA
and NodeD. But because NodeA and NodeD backbone the room to each other,
they also send all of NodeC's messages to each other. NodeD will also
send the duplicates out to NodeE, which will propagate them to its local
connections. This obviously causes a lot of duplication (and expense, if
there are any long-distance connections). To automatically detect and
eliminate this vortex problem, a loop zapper was developed.
8.4.3 The loop-zapper
With the advent of backboning came sloppy net management. (Well, we
suspect that the sloppy net management was around before, but it never had
such a good opportunity to manifest itself.) Anyway, if your room sharing
arrangement has a loop in it, you have what we in Edmonton dubbed a
__vortex__. (The term appears to have gained national popularity.) The
loop-zapper is a brute-force method of stopping vortexes.
The way it works is pretty simple. Each incoming networked message has
in it the node ID of the originating system, the date and time on which
the message was created, and possibly a message ID number from the system
that originated the message. Fnordadel keeps a database in which it stores
the node IDs of all systems from which it has ever---directly or indirectly
through backboning---received a message.
For each node ID, Fnordadel then records the date of the latest message
to be received, and what its message ID number was (if any; STadel does not
pass along such information, but Cit-86 and its clones for other machines
do, as does Fnordadel). Moreover, this is done in each room in which
messages have been received. So when new messages come in, the node IDs,
dates, message ID numbers and rooms of the messages are checked against the
loop-zapper database. If a message
o is dated earlier than the latest one received in that room from that
node, and
Chapter 8: Networking 116
o has a lower message ID number than is recorded in the database
it is assumed to be an old message coming back again, and will be rejected.
A message to that effect will be printed on the screen (and in the net-log,
if you're keeping one.)
To enable the loop-zapper, either define the `ctdlcnfg.sys' variable
zaploops to `1', or invoke citadel with the command line argument `+zap'.
The loop-zapper database is kept in your #netdir as `ctdlloop.zap'. If
you happen to delete this file, you'll have to reconfigure and start the
loop-zapper again. The loop-zapper will be built as the messages come in;
you can also build a loop-zapper which reflects your current message base
by running the utility makezt. The contents of your loop-zapper database
may be viewed by using the utility scanzt. See the respective man pages
for directions on using these programs.
Fnordadel tries to be smart about detecting truly looped messages,
versus ones that are abnormal but not duplicates. This is why it checks
both the date/time stamp *and* message ID number of each message, and only
rejects those where both values are older than the database shows. For
example, it's possible for a glitch or system crash on another system to
cause it to start sending you messages with message ID numbers that look
old; but if the dates are new, the messages will be accepted, not rejected,
on the assumption that the other system's message ID counter got reset to a
value lower than before.
Likewise, the clock may have been screwed up on some other system (e.g.,
its clock got set to some point in the future, some messages were sent out,
and its clock is now back at the correct value, or else it got set to
some point in the past and hasn't been corrected yet). Your loop-zapper
database will thus show a date/time that is greater than the one on the
incoming messages, but as long as the messages have new message ID numbers,
they will be accepted, not rejected. Note that no version of STadel ever
sends the message ID number, so the loop-zapper only has the date/time
stamp to work with. Thus it's easier for Fnordadel to mistakenly start
zapping messages from an STadel, if that node's clock got messed up.
The Fnordadel loop-zapper database is also self-correcting to some
degree. When any message is accepted in a room, both its date/time stamp
and message ID number are recorded as being the newest ones seen, even if
they are lower than what was there before. In this way, your database will
weed out incorrect date/time values, or message ID numbers. It can't weed
out both if they occur simultaneously, though; if a new message comes in
and has the bad luck of having an old date/time and an old message ID
number, the loop-zapper will reject it.
If you ever have a node get screwed up and the database doesn't seem to
correct itself, the only way to stop Fnordadel from zapping all the node's
messages is to delete your `ctdlloop.zap' file and start from scratch. Run
the makezt utility to build a new database from your current message base,
or just let Fnordadel run and accumulate new information over time.
From time to time, your system may incorrectly zap a small number of
messages from one or more nodes, and then return to normal. Zapped
messages can be saved off-line if you so desire (see keepdiscards in
Section 8.1.2 [Optional parameters], page 98.) You may then read through
Chapter 8: Networking 117
them and optionally delete them permanently or tell Fnordadel to integrate
them into your message base (if they look like they were zapped in error).
See Section 8.2 [The Net Menu], page 104, for instructions on these
commands.
Although the loop zapper is quite smart, there's currently one glitch in
it. You may notice that if two identical messages come in during the same
network call, the zapper will let both of them all through. Hey, so it's
only close to perfect...
8.4.4 Shared room aliasing
If you don't like the standard name by which a shared room is known on
the network and would like to have that room differently named on your
system, you can accomplish this using shared room aliasing.
Simply put a file called `alias.sys' in your #netdir. It should consist
of `<TAB>'-separated fields as follows:
<system> <roomname> <alias>
<system> is the name of the system to which the alias will apply; the
special name `%all' makes the alias apply to any and all systems
with which you share the room.
<roomname>
is the name of the room on your system.
<alias> is the name of the room on the other system(s).
We actually recommend against using the aliasing feature unless there's
a really good reason for doing so. The standard room names are usually
fine, and more importantly, it's possible to alias a room to another name
and then share the room with another system; the Sysop of the other system
may not realise that the room he's getting from you is the same as the
standard net room and may decide to share it with yet another system in
such a way as to create a vortex. So if you use this feature, be very
careful.
Also note that if you are sharing aliased rooms with a system, and
change the name of that system in your net list, you must exit Fnordadel
and edit `alias.sys' to update it with the system's new name. If you
don't, Bad Things will happen.
8.4.5 A few hopefully wise words
o Be considerate when sharing or unsharing rooms with a system. If you
tell another Sysop to share a room with you, make sure you've shared
it with him, or his Aide> room will be flooded with messages reporting
that your system isn't sharing the room with his.
Chapter 8: Networking 118
o We've already mentioned this, but it bears repeating any number of
times: Be careful when using backboning, and when sharing rooms in
general. Make sure you understand the topography of the room in
question before messing about; you don't want to cause a vortex, do
you? <PROD> No, you don't.
o Please try to police the net rooms. This applies especially to the
national networked rooms, which cost people money to transport. If
you have a twit or two who are entering stupid messages (or, worse,
``vandalism'' type of stuff like 10K of profanities and so on), it
is up to you to stomp on it as soon as possible. Moreover, you
must also be on the lookout for what Citadelians refer to as __room
drift__; if users on your system start talking about Pascal programming
in a networked Religion room, you must put a stop to it. Please be
considerate for your fellow Sysops downstream.
o You should be aware that there are some incompatibilities between
systems descended from STadel and those directly descended from
Citadel-86. We are working on eliminating them all in Fnordadel,
and hope eventually to make Fnordadel a seamless connection between
the STadel network and the Cit-86 network. For the time being,
not everything works perfectly. See Section 8.6 [Networking with
Citadel-86], page 121. As for normal room sharing, you should have
only one real problem any more: Cit-86 messages can only be 7500
characters long, while STadel and Fnordadel messages can be 10000
characters long. Thus long-winded people posting on your system will
get cut short if the messages migrate over to a Cit-86. This could
cause some confusion.
8.5 Mail Routing
Another popular use for the Citadel network is for private mail. In the
simplest case, that of sending mail to another user on the same system,
mail delivery is an understandably easy job. When you want to send mail to
a user on a system which connects directly with yours, it's also a pretty
easy thing. However, when you want to route mail through one or more
intermediate nodes before it reaches its destination, things get a little
tricky. This section details a few helpful features designed to make mail
routing simpler and more effective.
8.5.1 Net addresses
When you go to the Mail> room and hit [E]nter, the system asks you to
tell it to whom you want to send the mail. If the mail is going to
be a networked message, you have two ways in which the address can be
specified. One is using `@' notation, and the other is using explicit
__bangpaths__, which have as their distinguishing feature the `!' character
as a separator. The two forms produce identical results; it's just a
matter of taste, really.
The `@' form is as follows:
Chapter 8: Networking 119
user@system
which means that you wish to send the mail to the user named user on the
node called system.
The bangpath form is like this:
system!user
which means the same thing as the previous example.
If you want to send mail through several nodes, you'll have to provide a
`To:' address something like this:
node_a!node_b!node_c!user ,
or perhaps
node_b!node_c!user@node_a
As you'll notice, the `@' and `!' forms can be mixed. The two examples
above both address the mail to a user on `node_c', which (we happen to
know) is reachable by a direct path from our system to `node_a' to `node_b'
to `node_c'.
Your system may also receive routed mail from other systems with which
it networks. If the mail is destined for a user on your system, then it
is delivered to that user and the message stops. But the message may be
addressed to someone on a system further on. If you want your system to be
able to pass such mail on, you'll have to make sure that the `ctdlcnfg.sys'
variable #forward-mail is defined as `1'. If it's `0', your node will
simply reject all routed mail.
8.5.2 Path aliasing
So, forming net addresses is easy, right? But it's a pain to have to
remember explicit addresses through half a dozen other systems to reach the
one you want. So Fnordadel allows you to define, once and for all (or
until you change the definition), the paths to systems. Then when someone
wants to send mail to someone on such a system, they need only type a `To:'
field of `user@system', and let Fnordadel figure out where `system' is.
You can also use the path aliasing feature in strictly local situations; if
you have, say, a Citadel-86 system with a really weird nodename, you can
alias it to something short and essentially pretend that its name (for the
purposes of net mail) has changed.
The way it works: First of all, if you want to enable the path aliasing
feature, you should define the `ctdlcnfg.sys' variable #pathalias to be
`1'. If it's `0', Fnordadel won't even bother. The path alias data is
stored in a file called `ctdlpath.sys' in your #netdir. When someone
enters a message addressed to an unknown node, Fnordadel looks in this file
for an alias to the unknown system. (Note that ``unknown'', in this
context, means any system which is not in your net-list, or which is in
your net-list and is not a member of any nets. See the [U]se nets command
Chapter 8: Networking 120
in Section 8.3 [Editing Nodes], page 107. Also note that incoming mail
from other nodes is subjected to the same treatment; Fnordadel doesn't care
whether the mail is local.) If it finds an address, it will substitute
this into the `To:' field of the message and mail the message off to its
target. If the message was local, there may be special charges (in terms
of ld-credits) which apply to the message; see Section 8.1.2 [Optional
parameters], page 98, on the `ctdlcnfg.sys' variable #ld-cost for one such
cost.
The `ctdlpath.sys' file consists of `<TAB>'-separated lines of the form:
alias path [surcharge]
where alias is the nodename being aliased; path is a string defining the
path to the node; and surcharge is an optional number of ld-credits which
will be charged to the user for using the aliasing feature.
Here is a sample `ctdlpath.sys':
devnull `<TAB>' poopsie!%s `<TAB>' 1
alberta `<TAB>' dragos!myrias!%s `<TAB>' 2
Backfence `<TAB>' Backfence [MN] `<TAB>' 0
Silly `<TAB>' Silly_Cit-86_Name[MN] `<TAB>' 10
The special sequence `%s' means ``the destination node''. In this
example, let's say we wanted to mail to `Holly' at the system `devnull'.
We enter a `To:' field of `Holly@devnull'. Fnordadel discovers that
`devnull' is not in our net-list, so it reverts to Plan B---path aliasing.
Searching `ctdlpath.sys' for an entry for `devnull', it finds that the
route to `devnull' is through `poopsie'; so it massages the path into
`poopsie!devnull' (since the alias specified `poopsie!%s', and `devnull',
the destination system, is substituted for the `%s'). After appending the
user name to the whole thing, the `To:' field is `poopsie!devnull!Holly';
Fnordadel now spools the mail for delivery to `poopsie'. The user who
entered the mail is charged two ld-credits---one for the fact that it's
long-distance mail, and one for the surcharge listed in `ctdlpath.sys'.
Or, in the above example, if we wanted to send mail to a user on
`Silly_Cit-86_Name[MN]' and didn't want to make our users or ourselves type
that, we'd simply be able to give a `To:' field of `user@silly' and let
Fnordadel worry about it; it would check the alias file and use the entry
therein to massage the `To:' field to `Silly_Cit-86_Name[MN]!user'.
8.5.3 Hubbing
What happens if your system gets mail addressed to an unknown node, and
it doesn't have an alias defined for that node? If you have defined the
`ctdlcnfg.sys' variable #hub, then your system will have a last resort.
All mail which cannot be dealt with either by direct connection with the
target system, or by an explicit path in the message in which the first
node in the path is directly connected, or by path aliasing, will be
forwarded to the system defined as your #hub. This system (hopefully) will
be better able to deal with the mail than yours was, either because it is
connected to more systems directly, or because it has a more extensive path
alias file than you have.
Chapter 8: Networking 121
Mail which is entered locally and is forwarded to the #hub for delivery
can be charged extra ld-credits based on the setting of the `ctdlcnfg.sys'
variable #hub-cost---see Section 8.1.2 [Optional parameters], page 98.
8.5.4 Domains
Domains are supported in this version of Fnordadel, but in a somewhat
superficial manner. Primarily for Citadel-86 compatibility, you can set
the value of a `ctdlcnfg.sys' parameter called #domain, to tell Fnordadel
what Citadel-86-style domain you are in. See Section 8.1.2 [Optional
parameters], page 98. Citadel-86 uses this field for domain mail, a
feature Fnordadel does not yet support.
We also have some additional domain support. By placing lines beginning
with a period (`.') character into `ctdlpath.sys', we can tell Fnordadel
information about what other domains we are a part of and about how
to reach other domains. For example, consider the following lines in
`ctdlpath.sys':
.uucp `<TAB>' foobar!%s `<TAB>' 1
.citadel
.uucp
These lines define us to be members of the `.citadel' and `.uucp' domains;
in addition, they specify that any mail bound for the `.uucp' domain is
to be routed through `foobar' (and to be charged, in the local case, an
additional ld-credit.)
Look for better domain support in later versions.
8.6 Networking with Citadel-86
Originally developed by Hue, Jr., back in the early days of Citadel-86,
the Citadel networker is a fairly flexible beast. Indeed, it has
proved so flexible that numerous Citadel developers have mutated it in a
variety of interesting ways. A major mutator, so to speak, was David
Parsons (orc), who did STadel, from which Fnordadel is descended. Some
of the improvements and changes resulted in incompatibilities with Cit-86
networking.
It is our intention to eliminate or work around all of these things at
some point, hopefully in the near future. In order to make your Fnordadel
work as smoothly as possible with a Cit-86, you should set the Cit-86
status flag for it in your net list, and ask its Sysop to set the STadel
status flag for your system in his net list. As of this writing, the
following are the areas in which Cit-86 and Fnordadel networking differ:
o Mail routing has been done in remarkably different ways. Cit-86
supports STadel-style mail routing as a sort of after-hack, but don't
rely on it too much. (Similarly, don't tell your local Cit-86 friends
to rely on you too much for mail routing, either.)
Chapter 8: Networking 122
o Fnordadel currently has minimal support for Cit-86 domains, although
it will set the domain field on locally-originating messages, and
pass through the domain field on net messages from other systems.
See Section 8.1.2 [Optional parameters], page 98, and Section 8.5.4
[Domains], page 121.
o Cit-86 supports a networking option to compress network information on
the fly. Fnordadel does not yet support this facility. This will
probably cause you to see messages something like ``Reply BAD: <10>
unknown'' during networking sessions. This is nothing to worry about.
o Cit-86 doesn't use the #organization field, or pass it on to other
systems that it nets with, so in backboned shared rooms, messages from
your system will lose the #organization field the first time they pass
through a Cit-86.
o Cit-86 also doesn't support the STadel message subject field.
o Cit-86 messages are limited to 7500 characters in size, while STadel
(and its descendants) support messages up to 10000 characters long.
Thus when your messages pass through a Cit-86, they may get chopped
short.
The following are incompatibilities which we inherited from STadel, but
which we have fixed:
o The network sendfile/file request methods used to be different; sending
files to a Cit-86 would work (and sendfiles from the Cit-86 to you
would also work), but file requesting (in either direction) wouldn't.
This is now fixed---everything should work.
o Fnordadel and Citadel-86 couldn't use the Ymodem protocol during
netting; they should be able to now.
o The network passwords should work fine now.
The following things are bits of funny business between Cit-86 and
Fnordadel, but are harmless:
o If a Cit-86 is backboning any rooms to your system, you may notice
that each time it nets with your system, it will attempt to send
each backboned room, whether or not there are any new messages to be
transferred. (It will send 0 messages, basically.) We can't imagine
why it does this, but it seems to be normal and will not cause a
problem.
o There are net commands that Cit-86 supports but Fnordadel doesn't, and
possibly vice versa. In particular, Cit-86 has two commands that
Fnordadel doesn't yet know about: 8 (a different form of room-sharing)
and 10 (for data compression during networking). They will cause
messages during networking, such as ``Reply BAD: <10> unknown'', when a
Cit-86 asks your system to carry out such a command. These are nothing
to worry about.
Chapter 8: Networking 123
8.7 Interfacing to Other Networks
Using the #event mechanism, custom networking software and (often) lots
of system resources, it is theoretically possible to make your Fnordadel
talk to just about any other network in existence. Of course, most of the
custom software has never been written, so it's largely theoretical.
STadel had a program called uucall, which was for talking to Unix
machines using the UUCP protocol, and allowed incoming and outgoing mail
and News (the Usenet analogue to rooms). uucall is not currently supported
by Fnordadel (and thus, is not included with it); it needs some hacking.
If anyone is strongly interested in seeing it running, let us know---we
occasionally need a bit of encouragement. Our plans are, tentatively, to
redo the UUCP support using a different approach, but the uucall code is
there, and with a little effort could be made to work---it worked with
Fnordadel for a long time, and then broke when we changed something or
other, and we've just never gone back and fixed it.
STadel also had a program called bixcall, which was for talking to the
Byte Information eXchange (BIX). We've never seen BIX in our lives, so
we've no way of testing it at all. We can send a copy to anyone running
Fnordadel and you can see if it works; there isn't much we can do to
support it, though.
8.8 Country Codes
Country codes are used in your #nodeid (see Section 8.1.1 [Required
parameters], page 96; they consist of one to three letters which uniquely
identify your country. The following list is considered standard; it is
purloined directly from `COUNTRY3.MAN', in the Citadel-86 documentation.
Abu Dhabi AH Afghanistan AF
Ajman (U.A.E.) JM Albania AB
Algeria DZ Andorra AND
Angola AN Anguila LA
Antigua AK Argentina AR
Australia AA Austria A
Bahamas BS Bahrain BN
Bangladesh BJ Barbados WB
Belgium B Belize BH
Bolivia BV Botswana BD
Brazil BR Brunei BU
Bulgaria BG Burma (Union of) BM
Burmuda BA Burundi UU
Cameroon Republic KN Canada CA
Cayman Islands CP Central African Empire EC
Central African Rep. RC Chad Republic KD
Chile CF China (People's Rep) CN
Colombia CO Congo Republic KG
Cook Islands (Rarotonga)RG Costa Rica CR
Cuba CU Cyprus CY
Czechoslovakia C Denmark DK
Djibouti, Rep of FS Dominica DO
Dominican Republic DR Dubai (U.A.E.) DB
Chapter 8: Networking 124
Ecuador ED Egypt, Arab Rep. of N
El Salvador SAL Ethiopia ET
Falkland Islands FK Faroe Islands FA
Fiji Islands FJ Finland SF
France F French Guiana FG
French Polynesia FP Fujairah (U.A.E.) FU
Gabon Republic GO Gambia GV
Germany (Dem. Rep) DD Germany (Federal Rep) D
Ghana GH Gibralter GK
Greece GR Greenland GD
Grenada GA Guadeloupe (Fr. Ant.) GL
Guam GM Guatemala GU
Guinea GE Guyana GY
Haiti HC Honduras HT
Hong Kong HX Hungary H
Iceland IS India IN
Indonesia IA Iran IR
Iraq IK Ireland, Rep of EI
Israel IL Italy I
Jamaica JA Japan J
Jordan JO Korea (South) K
Korea, Dem People's Rep KZ Kuwait (Persian Gulf) KT
Laos LS Lebanon LE
Lesotho BB Liberia LIB
Libya LY Liechtenstein FL
Luxembourg LU Macao OM
Madagascar MG Malawi MI
Malaysia MA Maldives MF
Mali MJ Malta MT
Mariana Islands(Saipan) SA Martinique (Fr. Ant.) MR
Mauritania, Islam Rep MTN Mauritius IW
Mexico ME Monaco MC
Mongolia MH Monterrat MK
Morocco M Mozambique MO
Nauru Islands ZV Nepal NP
Nethelands Antilles NA Netherlands NL
New Caledonia NM New Hebrides NH
New Zealand NZ Nicaragua NK
Nigeria NI Norway N
Oman (Persian Gulf) MB Pakistan PK
Panama PA Papua New Guinea NE
Paraguay PY Peru PE
Philippines PH Poland PL
Portugal/Madeira/Azores P Qatar (Persian Gulf) DH
Ras Al Khaimah (UAE) RK Reunion Islands RE
Rumania R Rwanda RW
Saint Kitts (WI) KC Saint Lucia LC
Saint Pierre + Miquelon QN Saint Vincent VQ
San Marino RSM Saudi Arabia SJ
Senegal SG Seychelles Islands SZ
Sharjah (UAE) SH Sierra Leone SL
Singapore RS Solomon Islands HQ
Somalia Republic SM South Africa SA
South West Africa WK Spain / Canary Islands E
Sri Lanka CE St Helena HI
Sudan SD Surinam SN
Chapter 8: Networking 125
Swaziland WD Sweden S
Syrian Arab Republic SY Taiwan TW
Tanzania TA Thailand TH
Togo TO Tonga TS
Transkei TT Trinidad and Tobago WG
Tunisia TN Turkey TR
Turks + Caicos Islands TQ USSR (Russia) SU
Uganda UG Umm Al Qaiwan (UAE) QA
United Arab Emirates EM United Kingdom / N Ire. G
United States of Amer. US Upper Volta, Rep of UV
Uruguay UY Venezuela VE
Viet Nam VT Virgin Islands (Brit) VB
Western Samoa SX Yemen Arab Rep. (San'a) YE
Yemen, People's Dem Rep AD Yugoslavia YU
Zaire ZR Zimbabwe RH
