==========================================================================
FidoNet Technology Primer
Copyright 1988-1994, Chris Anderson
==========================================================================
The first TBBS systems designed by e-Soft predated many of the
technologies that many take for granted today. They ran on TRS-80
computers that were considered substantial if they had 48K of memory to
make available to a program. With the advent of the IBM PC with its
640K memory option and the many clones of that machine, the
"Possibilities" became far greater.
Within just a couple of years of the advent of the "IBM PC", something
called FidoNet technology was born, and shortly, e-Soft added the
capability to its software to work in this medium.
FidoNet technology began as the Fido BBS system that could dial and
communicate with other Fido systems. This was done to share information
between Fido users and to distribute new Fido code on a timely basis.
What Tom Jennings saw as a way to simplify his job as a developer
quickly turned into a world-wide phenomenon.
Today, this technology has generated dozens of different networks,
moving tens of megabytes of new mail each day around the world. Both
person-to-person mail between just two systems and wide-broadcast mail
for distribution to many systems is available in most networks. In the
wide-broadcast area, topics of discussion range from discussion of the
latest films, programming in esoteric languages, to the care and feeding
of tropical birds. It would be the rare persons, indeed, who would not
find their own favorite hobby, vocational or other special interest
represented among the available topics. In one network alone, over 800
such topic areas are being distributed daily to those systems who choose
to participate in them.
The sysop members of these networks will receive all of the available
mail on the topics to which they are subscribers. Their users can enter
messages locally on a BBS, and those messages are forwarded daily to all
other systems that subscribe to the same topic areas. As the same
messages are appearing on many systems, the name given to this
technology was "EchoMail". In addition, many sysops offer individual
messaging between two people that is destined only for the intended
receiver's system, and this is called "NetMail".
This same technology can also be used on corporate systems for
interlinking offices around the world. ASCII (characters) are far
cheaper to send than bit images (such as a FAX), and many companies use
both NetMail and EchoMail technology to communicate between offices and
with their employees in the field. Files can be "attached" to messages,
making it possible to move data of any sort between systems in an
automated fashion.
For the amateur network sysop, EchoMail has been a real boon. The
diversity of topic areas and views to be found within them provide more
options for the users and greater interest in participating on a
particular BBS. In addition, entire networks exist for the sole purpose
of distributing the latest in shareware files and digitized images.
To understand the technology better, it will help to get some basic FIDO
terminology under your belt. These words will be used OFTEN during
discussions of any mailer and BBS net software.
NETMAIL
The international system of Electronic Mail. Designed primarily to
transfer E-Mail messages between individual users around the world.
The user sends his message from a local system and this message is
forwarded to the appropriate system automatically. The sending
system pays for the service by placing the outbound call, sometimes
billed as a one minute call to the receiving system's location at
late hour long distance rates. Replies are paid for by the
reply sender.
In most networks, all NetMail is transferred at least nightly during
an hour devoted to this task. In FidoNet, this is known as Zone Mail
Hour, or "ZMH". This is synchronized event takes place in each
FidoNet zone coast every day of the week. Since it is done during
the "wee hours of the night", when system activity by users and phone
rates are generally the lowest, the FidoNet world is divided up into
Zones for this purpose. In FidoNet, there are presenty six such
zones. In addition, many systems allow sending and receiving of
messages 24 hours a day, even during the higher priced daytime hours.
Mail sent out irrespective of any sort of schedule is often called
"Crash" mail, and is often sent as soon as it is posted by the
sender, although how and when such mail is sent is controlled by each
sysop.
ECHOMAIL
The method of sharing message boards between systems. This allows
systems to share one or more message boards on a worldwide basis.
These shared boards are usually called "echos" or "echo conferences".
During the night, each system sends its day's messages from selected
message areas to a central point and receives other systems' new
messages in return. Distribution of echos is, as noted, almost
always handled by a central system in each area to avoid confusion
and possible duplication of messages. This service is provided by
sysops at no charge to their users. An exception would be a board
that charged for access to all or most if its services.
Zone Mail Hour
Participants in the Fido NetMail system are obliged to make their
system available during Zone Mail Hour on a daily basis. This hour
is synchronized to occur simultaneously within each Zone. For
example, the North American continent observes the following hours:
0100-0200 Pacific Standard Time
0200-0300 Mountain Standard Time
0300-0400 Central Standard Time
0400-0500 Eastern Standard Time
Times are NOT adjusted for daylight savings time. If your system is
in the Pacific zone, your ZMH time slot would be from 0100-0200
during standard time, and from 0200-0300 during daylight time if it
is observed in your area.
"OTHER" HOURS
A net may also observe other hours where your system needs to be
available. Often, these times are used for EchoMail transfers. Note
that sending EchoMail during Zone Mail Hour is, particularly in
FidoNet, not appropriate unless multiple lines are available to
permit you to receive NetMail from whatever system calls. Some
systems are unable to send NetMail on a continuous basis, and the ZMH
is therefore the only time at which they will be able to attempt to
contact other systems.
An example is that in the 104 (Denver) net, we once used the hours of
0100-0200 open for sending our EchoMail from the day to our central
"collection points" - our EchoMail Hubs. From 0200-0300 we had Zone
Mail Hour, and from 0300-0400 we received EchoMail from the
coordinator.
ZONES, REGIONS, HOSTS (NETS), HUBS, NODES AND POINTS
Each of these is descriptive of the position of a system in the
overall network. Technically, every system in a FidoNet technology
network is a "node". A node is, after all, a "connection" within a
system. However, certain nodes have responsibility for routing data
between other nodes.
"Zones" are the largest discrete group of systems. There are now six
FidoNet zones covering the world. Every node has an implied zone
number (see Net/Node Number, below). Zone numbers are also sometimes
used for interconnect to other networks using Fido technology. These
networks have differentiated themselves by using zone numbers that
had not previously been used by FidoNet.
If FidoNet continues to add zones, this could someday present a
problem, and new identificiation methods have already been
established to handle this problem in a different way. This "Domain"
addressing technique won't be discussed here, but you should be aware
of it.
"Regions" identify a large geographical area within a zone. In the
U.S. Zone, there are several regions, each taking care of a group of
states. One FidoNet region is 15 which takes in Colorado, Utah,
Arizona, New Mexico and Wyoming. It's known as the Mountain Region.
Region numbers are never used as part of a Net/Node number. However,
be aware that your Net Coordinator's boss is the Regional
Coordinator. He helps handle nodelist updates and the like, but
isn't involved in the day-to-day moving of mail unless it has been
routed via the RC.
"Hosts" (also known as "Nets") are the next smaller subdivision.
Within Region 15, Denver is Net 104. On a typical Fido style
nodelist, you'll see these referred to as a "Host". The person who
administrates a net is known as the Net Coordinator. This is the
person who is responsible for making sure that the current Nodelist
(a Fido technology "phone book", so to speak) and other important
items are made available to the members of the local net. The Net
Coordinator also assigns the node numbers (see below) in the net
area.
"Hubs" serve to distribute to a smaller geographic area or grouping
of nodes, taking some of the load of distribution from the Net
Coordinator's system. For example, as part of the Denver Net (104),
various suburbs and surrounding cities may be grouped around a Hub.
These are never included in Net/Node numbers. Not all nets make use
of hubs for assistance.
"Nodes" are the last step in the chain (but remember that actually,
ALL systems are Nodes). Each system has a unique Node number within
its Host or Net area.
"Points" are "superusers". They use mailer software to receive mail
from a member of the network, and do not have their own node numbers
listed in the nodelist. However, they may have unpublished private
net (Point Net) numbers which are used to handle movement of mail
between their systems and their respective Boss Nodes. In some
networks, Point Net numbers can be received by applying to the Zone
Coordinator. Contact your local Net Coordinator for information on
this process. You can then assign the node portion of the number to
systems as you see fit. Many mailer and utility packages do not
require the use of private net numbers in order to handle the
addressing of point mail.
"NET/NODE NUMBER" - the mailing address that makes it all work. In
fact, the proper definition is ZONE:NET/NODE, but unless
international or inter-net transactions are occuring, the Zone number
typically defaults in software to the zone of your own address. The
level of detail contained in the address is referred to as nD
addressing. 2D addressing is the use of simple net/node. 3D
addressing include zone:net/node. 4D addressing is
zone:net/node.point. 5D addressing using domains whose form is
zone:net/node.point@domain. No eSoft products use this addressing
method at this time.
If you were in the U.S., Denver area, your number would be
1:104/something, since the U.S. is part of Zone 1, and the Denver
area net is Net 104. If your node number within 104 is 114, your
full address would be 1:104/114. As noted above, the Zone is
sometimes ignored, so you might be referred to as 104/114.
Remember that Regions and Hubs are used for administrative purposes,
and don't figure into the net/node address number.
"AKA" ADDRESSES - some systems hold more than a single address in one
or more nodelists. If you participate in more than one network (and
hence, more than one zone), or for certain administrative purposes
you carry more than one address in your own zone, you will select a
"primary" address, and your other addresses will be "AKA" (Also Known
As) addresses in your configuration.
MESSAGE
Of course, the primary purpose of all this is to move "messages"
around the system between nodes. There are several types of message,
and each is handled in a unique way by your software. We've already
covered the definitions of EchoMail and NetMail messages above. There
are several other types of "messages" as well, including the File
Attach message and the File Request message. We'll touch on those a
bit later in this file. The utility software associated with mailer
software will sometimes operate on the message with a filename in the
form of *.MSG. Other systems avoid this intermediate stage and place
the messages directly into the message base if there is a "database"
style message base in use as is the case with TBBS.
Messages can usually be sent with a variety of attributes, some of
which are FidoNet standards, and some of which are unique to
particular software. A few of these attributes include
Private - Various software can be configured to handle this
in a wide variety of ways. In many cases, only the
sysop, the sender, and the receiver are made capable
of reading a "private" message. Since the point of an
echo is to move useful mail to a great many systems,
sending a "private" message in an echo is usually
inappropriate. Hundreds of systems may be forced to
receive a message that their users can never read.
Crash - Flags that this message is to be sent "crash". On many
systems, the configuration causes a the message to be
sent immediately to its destination either directly or
via whatever appropriate routing has been supplied.
Hold - A message with a "hold" flag on it must generally be
picked up by a call *from* the destination system, but
will not be sent to it by placing a call.
Kill/Sent - Most often used only on NetMail messages, this flags
your software to delete the message once it has been
packed or sent to the destination, avoiding cluttering
up your own message area with traffic that has already
been sent on its way.
PACKET
The most BASIC unit of transfer between two systems is NOT the
message, it is the "packet". A packet is prepared by your software
that contains all of the messages destined for a given system - all
in one tidy bundle. There is no compression technique used here,
only the bundling process takes place. When two systems make
contact, and if things are configured properly, they will exchange
any packets destined for each other. If you have four messages
destined for a node, they will be transferred in a single packet
during the connect. They are then broken down into "messages" by the
receiving system's unpacking software, and inspected for potential
file requests or attaches. Regular messages are then processed in
whatever fashion the software is designed to use to get the messages
to someplace where they can be read. If you should ever spot a file
whose name is in the form *.PKT, that's a packet. Note that when we
discuss moving archived (compressed) mail files back and forth later,
that it is the packets (*.PKT files) that are compressed and
archived. The FidoNet standard for this is the old SEA 5.X ARC
standard, although many systems will use the newer ZIP or other
formats - but ONLY where mutually agreed upon in advance. As you
will note in the documentation for FLAME, *.PKT files will use other
extensions if they exist as stand-alone (unarchived) outbound mail
waiting for other systems.
There are official FidoNet Technical Standards covering the exact
construction of packets. Most software has been written correctly,
and will conform to these basic formats. If, however, your software
is prone to deviating from those standards, you're likely going to
run into trouble with your fellow net members when *their* software
takes exception to undecipherable messages or packets. It is *your*
responsibility to remedy such situations when they occur. Always
stay abreast of modifications and bug fixes for your software that
are intended to enable your software to maintain FidoNet standard
operation. If questions arise, the FTS standards are the final
authority for such matters.
If you're interested in seeing just how these standards allow your
system to talk to others, you may want to locate and download these
standards as created by the FidoNet Technical Standards Committee
(FTSC). A great deal more thought has gone into making our systems
function well together than first meets the eye!
FIDONEWS
If you are a member of FidoNet, each week, and a day or two before
you receive the new NODEDIFF file (the update to our FidoNet "phone
book"), you'll receive the Fido News. The Fido News is a collection
of editorial material, rants and raves, amusing stories, and
sometimes a useful list of the latest known revisions for much of the
software used by FidoNet systems. This practice has lately been
on-again/off-again.
Traditionally (until August 1990), the Fido News was transmitted in
archived (ARC) format. The editor of Fido News then decided it would
appropriate to use a "freeware" archiver, and began transmission in
LHARC (LZH) format in August of 1990. Your Net Coordinator or
Administrative Hub may recreate these files as ARC files, or may pass
them through to you as LHARC files. If your brand of computer has no
LHARC utility available for it, you should request that it be
converted before it is sent to you.
FIDONET POLICY
FidoNet sysops are obliged to operate by a set rules known as
"Policy" If you plan to enter into the system, you should get a copy
of whichever is currently available (Policy 4 at the time of writing)
and read it. Most important are the understanding of Zone Mail Hour
(above) and the responsibilities of the individual Sysop. Pay
particular attention to what is known as an "annoyance". Fido is
reasonably tolerant of a lot of things, but Major Annoyances should
be avoided. The policy also explains the responsibilities of the
nodes up the chain from you, and therefore explains what you can and
cannot reasonably expect from them.
There is also a separate policy governing the movement of EchoMail
messages. It has never been voted upon by the membership of FidoNet
at large, but most areas within FidoNet abide by its rules. The
present version of this policy is 3.1C.
In addition, your own net may adopt local policies detailing its
own preferred method of operation so long as it does not come into
conflict with FidoNet policy.
Other networks have their own policies, and you should familiarize
yourself with the policy of any network before making application for
a node number within that net.
Now for some other terms related directly to your software and its use:
EVENT (also known as a SCHEDULE)
An Event is just that... an event... It is an action that is taken
at a specific time of day or within a range of times by your
computer. You will want to set up Events so that at the appointed
time, your system will begin to execute each Event. All you'll need
to supply is the time and a description of what you want
accomplished. An example of this would be to tell your mailer
software that at 0200 it needs to put itself into send/receive mode
for NetMail, but to refuse file requests from other nodes. TIMS
handles this by use of RESTRICT blocks.
NODELIST
All of the addresses for the over 12,000 FidoNet systems are
contained in a file called the Nodelist. Each Fido technology
network maintains its own list. The FidoNet file is updated on a
weekly basis by the Fido coodinators. In addition, for those that
already have the most recent large working file, small update files
called NODEDIFFs, or "diffs" are made available weekly to add to the
existing file. This avoids having to shuffle around the big one once
a week to all systems.
The large file is distributed as NODELIST.Axx, where xx represents
the number of the distribution. This number is the first two days of
the day of year. The .Axx extension indicates that the file has been
archived using the ARC 5.0 or similar archive techniques. After
un-ARC'ing the file, it will look something like NODELIST.241 instead
of NODELIST.A41. You don't see the entire day, of course, until you
un-ARC the file. Unless you specifically request this file, or are a
new node, you will likely never download or otherwise receive the
NODELIST file. Once you have the NODELIST, small NODEDIFF files may
be applied to it to keep it up to date.
The list is not useable by most software packages in its form as
distributed. This list will likely need to be translated to operate
with your mailer package. In addition, an index and some other
necessary files are usually created from NODELIST.xxx. Most
software, including TIMS, can be supported by the XLAX nodelist
compiler. However, if you are a TIMS 1.1 owner, you already have the
XLAXNODE and XLAXDIFF software under the guise of TBBSDIFF and TBBSNC
on your distribution disks. Not all of the available commands were
documented in the TIMS manual, however, and you might wish to pick up
a recent copy of XLAX in order to discover the remaining commands.
You will receive NODEDIFF.Axx files weekly. These are the changes
rather than the entire list. These can be incorporated using
TBBSDIFF or XLAXDIFF. NODEDIFF.Axx files have the same extension
(archive indicator + day number) as the larger files.
It's much faster to incorporate changes into your existing list than
to receive an entire list each week! You'll discover that the
archived version of the full list runs nearly a megabyte in length!
Several files are needed for compiling any nodelist. In the case
of TBBSNC, two of the more difficult to create are the file
containing costs and the file containing corrections for dialing.
For these examples, these are called COSTS.TXT and DIALFIX.TXT. The
latter isn't too difficult, but you're going to either have to borrow
the former, or do some substantial work to get accurate costs built
into your nodelist if it needs them.
COSTS
The TBBSNC docs provide an excellent description of the format for
this information. This list will probably the most time-consuming
proposition in the entire setup unless you can get an accurate list
from another sysop in your own local calling area. Best bet is to
find the closest FidoNet sysop and rework that list as opposed to
building one from scratch. One word of caution! If you use someone
else's list, be aware that this person may be using a different long
distance carrier, and that your rates may vary somewhat from his,
even if you are in the same calling area. Getting rates from your
carrier can be a real problem. They HATE to send out rate lists for
you in most cases. However, experience shows that threatening to ask
them by phone, area code by area code, often produces results. In
general, rates don't vary much in the 1am-4am once you get outside a
certain distance from your area, but be sure!
International rates are a little easier to get in most cases. For
in-state calls (where your local phone company has you by the
pursestrings), the possibilities may be endless and may require that
you do some random sampling and simply generate an average in order
to avoid a list that could take weeks to enter. Of course, it should
come as no surprise that in-state calls wind up costing more than
long distance. You'll get an education into the cost of phone calls
as you go about this process!
Be sure that you enter the default domestic and international rates
at the top of the list per the TBBSNC docs just in case your list
misses something along the way.
DIALING FIXES
All of the entries in the node list are in the full length form. For
example, a Colorado number might appear as 1-303-123-4567. If you
live in Colorado, dialing 1-303- before every number might get you a
recording telling you that you really didn't need to do that. In
fact, you don't even need the 1- for calls in your local calling
area. However, a nationwide change took place in the U.S. in
February 1994 that requires a full 1-areacode-number for all long
distance calls, even those within your own areacode. This file is
where these things are dealt with. TBBSNC docs cover this well.
Again, you may wish to consult a nearby sysop to see if you may make
use of an existing list.
NODELIST ENTRIES
Everyone participating in a Fido technology network should be
familiar with the makeup of a nodelist entry. Here is an example of
such an entry (split into two lines for convenience - they are never
split in the list).
,114,The_Dinosaur_Board,Niwot_CO,Chris_Anderson,1-303-652-3595,9600,
HST,V32b,CM,XA
Most of this information requires no explanation. The first number
is a node number (114) within Net 104. The second bit of information
is the name of the BBS. Note that underscores are always used in the
nodelist entry, but are generally converted to spaces by other
software. The next items are system location, and sysop name. The
phone number is "normalized" to include all of the dialing
information required for somebody in the U.S. to place the call to my
number. For those that are in the same area code (303), their
nodelist compiler must remove the 1-303 if they are a local call, and
the -303 if they are not a local call. Next, the baud rate.
The baud rate is a little hinky. You may have a modem that can make
a zillion (ok, only 28800) bps connect to another modem. But this is
left to the modems involved. 9600 is the highest baud rate that is
reflected in the nodelist. A call placed by an HST modem or
V.FC/V.34 modem to a system with a similar modem would indeed connect
at the higher rate if the software was configured properly to do so.
Keeping track of modem types can be important if you have multiple
lines and differing modem types, as it may be beneficial for you to
allow only certain of your modems to outdial to certain systems.
What follows the baud rate varies a great deal based on the system
configuration and the diligence of the local net coordinator. These
are called the FLAG information. For a system running 9600 or
faster, there must be a flag that indicates the modem type in use.
The combination of HST and V.32bis connect possibilities are
indicated in the above example because the system uses an old Courier
HST Dual Standard that supports both. Next, we have the mailer
software type. In our example, this is XA. Several mailer packages
fall into this category, including TIMS. This flag is sometimes
needed to establish what sort of FidoNet technology protocols are
available on the other system's mailer.
Last, you should understand the CM, #09 and MO flags. The CM
identifies a system able to receive mail (a 'crash' system) on a 24
hour basis. The #09 indicates that the system is not a CM system,
but supports the Zone 1 (North American) zone mail hour at 0900 hours
Greenwich (Zulu, CUT, or whatever you prefer to call it). A system
with an MO flag is "Mail Only", and calling it with normal comm
software will get you nowhere, as there is only a Fido technology
mailer there - no BBS.
It is strongly recommended that you have a look at the end of the
Nodelist and find there a text section explaining the meaning of all
of the other possible flags. You should also be aware that some NC's
and hubs aren't very diligent about getting the right flags into the
list (with the exception of the "CM" flag). You should check your
own entry to be sure it is correct in the nodelist. A program like
LIST.COM is a handy way to do this, using the <F>ind feature. Just
search for Host,xxx where the xxx is your net's number. Just below
that, you'll find your own entry.
You may see a couple of "oddball" entries in the Nodelist. First,
there is the "Down" entry. This means that although the system may
still exist, it is either down due to technical or other troubles, or
the NC has been unable to communicate with it for unknown reasons.
Failure to be available for NetMail by your NC during Zone Mail Hour
may get you a "Down" notation in the list. Continued failure to be
available for contact during ZMH may cause the NC to remove your
entry from the list!
Also, there is the "PVT", or Private node. There are a few folks out
there that either don't want calls from anyone except their NC or
hub, or are running software that most other systems couldn't connect
with reliably. These are discouraged, but when included in the list,
they are marked as PVT and their phone numbers are generally
unpublished in the list. The reason for their inclusion is to allow
you to know how to route mail to them via their NC or hub. Yes, it's
possible (and also common) to deliver NetMail to one system by
sending it to another for re-routing. We'll cover this elsewhere.
FILE REQUESTS, FILE ATTACHES and other neat stuff
Besides the normal traffic of NetMail, EchoMail and the like, a
typical mailer system has a few more tricks up its sleeve that you
may find very useful.
One such feature is the File Attach Message or its equivalent on your
system. A File Attach Message can be used to send a copy of any
file between systems. When you get your weekly copy of your NODEDIFF
file from your Net Coordinator or Hub, it is done by creating a
special kind of message or file whose job it is to direct his mailer
to send you the file.
Besides the File Attach Message, there is the File Request Message.
Sometimes, in order to abbreviate File Request, folks will use the
form freq or f'req instead. You'll often see someone talking
about freq'ing a file. This is the File Request. The file request
message contains the name of the requested file in the subject line
of the message, and has a special flag bit set to indicate to a
compatible mailer that this is the purpose of the subject line.
*.FLO FILES
In addition to the File Attach Message, many mailers (including TIMS)
can operate from file list files. Such files are nothing more than
ASCII lists of files that need to be sent to another system. Much
more detail on this method is covered in the FLAME docs on this disk.
*.REQ FILES
Another approach to requesting files (other than the file request
message) is the sending of the *.REQ file. This file extension has
become recognized by most mailer programs. Such files are named
using your system's net/node number in eight hexidecimal digits,
using .REQ for the extension. The file contains the list of files
that you are requesting, and in most cases, may contain filenames
with wildcards.
The *.REQ file is seen by the remote system, and if configured to
respond to your request, will send you those files that match the
requested filenames during the mail session. These files are
generated by FLAME when using a FLAME "GET" or by TIMS when using a
TIMS.CTL "DO TBBS GET".
During any event that allows you to place a call to the system for
which you've set up a File Attach or File Request, your mailer system
will dial that system, and use the message to indicate to the other
system that a file transfer is desired. So long as the other system
hasn't included something like NO-FILES or NO-INBOUND or similar
restrictive statements in the current event, and as long as the other
system talks the same "language" as yours, the file transfer will
occur.
ROUTING MAIL
It's possible to send a message directly to any system with a
published number in the Nodelist. This is due to the fact that
systems are required to observe the minimum FTS-0001 (Fido Technical
Standards) protocol that allows for the most basic mail packet to be
transferred between systems. However, an alternative is to send the
same message to the NC or hub of the destination node instead. Your
mailer or "packing" software will allow you to send a message
destined for a node to another system for re-transmission. It is
always acceptable to send mail routed to another node's Net
Coordinator or net hub if, for whatever reason, you find any
difficulty in connecting directly. However, it is considered poor
form to route through any other system without first obtaining
permission from that system. Moreover, it is entirely possible that
another system won't have the proper routing installed to re-transmit
your message to the destination in the first place. Except for NC or
hub routing, ALWAYS ask first.
FLAME can be asked to route mail and files by specifying ROUTE
commands within the ROUTE.CFG file, and TIMS has a limited ability to
route mail and files using the DELIVER statement within TIMS.CTL.
APPLYING FOR A FIDONET NODE NUMBER
Although written specifically regarding FidoNet procedures, you'll
find that much of the information presented here is applicable to
beginning on any amateur network. The same is true for the process
of obtaining and using your own node number.
First, you'll need to locate the Net Coordinator (sometimes known as
the NC) for the net you want to join. In the case of FidoNet and
some others, it is preferred that you join the net nearest your
physical location unless there is a substantial reason (long distance
to nearest hub, etc.) that makes it financially more reasonable to go
outside your local area.
In order to find the NC, just locate any bulletin board in your area
that supports FidoNet (or your choice of another network). You'll
want to talk the local sysop out of a copy of the current Nodelist
either via disk or download. Quite a few network sysops make these
lists available for download.
Next, you'll need to create a message with your software to the NC
who will always be the /0 node of any network. For example, let's
say that you local or nearest network is 104. You'd send your
application for a node number to 104/0. During the time until you
receive an official number, use something like node number 999 or
9999 to send your request. The request should include at least the
following information:
Your name and voice phone #
The name and location of your board
The phone number of your board
Hours of operation
Whether or not you are able to handle continuous (crash) mail
Baud rates supported [if 9600+, please include which version(s)]
Which mailer software you are using
Each of these items is important as all but your voice phone # are
required items for your own Nodelist entry.
After sending your request, you should be available for a NetMail
response from the NC during the hours you've specified for your
system. He will return with your net/node address. Don't forget
that people take vacations and the like, so be patient. However, it
should NEVER take more than three weeks to get your node number. If
it does, follow up with another message and perhaps a voice call.
=============================================================================
ECHOMAIL, HOW IT WORKS
Most of the traffic moved through FidoNet and other FidoNet
technology networks is in the form of what we call EchoMail. There
are several other techniques for moving mail that are in use by other
networks (e.g., GroupMail) but this discussion will remain focused on
the more popular EchoMail model.
Again, a few definitions are going to be helpful:
STAR SYSTEM / REGIONAL ECHO COORDINATOR
There are a few selected systems across the U.S. that act as "stars"
for FidoNet echomail. These systems supply cross-country connection
between the various nets by accepting and distributing mail between
each Region's primary system (often run by the Regional Echo
Coordinator, or REC for short). In the case of some of the larger
nets, they are connected directly to the "Star" systems, bypassing
the Regional Coordinator due to the load of mail involved. It might
look something like this (things tend to change frequently!), an
abbreviation of a real "star" system
Western Star ------- MidWestern Star ------- Eastern Star
/ /|\ / /|\ /|\
/ | | \ /
etc A large Net | | \ / etc
may be an 104 | | \ /
exception. / | \ Satellite
/ | \ Service
/ | | Provider
/ | |
/ | |
/ | |
Region Region Region
14 11 12
|
etc | etc
/|\
/ | \ This is the more
/ | \ typical arrangement.
/ | \
Net Net Net
108 110 115
etc etc etc
Alternatives at both the net and node level include obtaining inbound
mail from a satellite system. In this case, replies are returned by
a phone call to the satellite service provider.
Regions typically serve the nets. Each net has its own primary
system, usually run by the Net Echo Coordinator (NEC for short), who
distributes the mail within the net. Often, the NEC appoints hubs to
help in distribution of the mail. This is especially important in nets
with a large number of systems and a large volume of EchoMail being
imported.
TAG LINE / ECHO TAG
Each message in an echo area must include information regarding the
specific echo to which the message belongs. This is placed at the
top of the message before exporting to the outside world, and is used
by all receiving systems to know in the message area, or "board",
into which the message needs to be placed on the BBS. It is also
used for making copies of the message as needed (see below). This is
called the Echo Tag, or AREA Tag. Most BBS software does not display
this information, or strips it into a separate file before placing
the message in to the message base.
How is this mess kept straight? Messages flying all over creation
and somehow, we manage to keep track of who needs to receive them and
who's already seen them. Enter the SEEN-BY line, and another piece
of useful information, the PATH line.
Although not used to figure out where things need to go, it is easier
to explain the whole procedure if we start with the PATH information
attached to each message as it travels its course. The PATH is
simply the list of systems through which any message has passed to
get from its originating system to the destination system. Since
messages will take different paths to reach different systems, each
sees a slightly different PATH line when the message is delivered.
Assume, for example, that there are five systems that all share mail
between them (a radically simplified model of the real distribution
system shown above). Let's call these systems 100/1, 100/2, 100/3
100/4 and 100/5.
Let us further assume that 100/2 is handling all of the distribution
for mail between some of these systems. In other words, all mail
must pass through 100/2, regardless of where it originates, and is
then passed on to the other two systems (100/1 and 100/3). In
addition, it will be assumed that 100/3 is in turn 'hubbing' for
100/4 and 100/5.
The topology of our "mini-net" would look like this:
100/2
/ \
/ \
100/1 100/3
/ \
/ \
100/5 100/4
A message from 100/1 that is shared by all other systems would pass
to 100/2 first, then to 100/3 and on to 100/4 and 100/5. The PATH
information will always show how the message got to where it finally
was posted on any system. For example, the message from 100/1 shows
only 100/1 on the PATH line of the message as it leaves 100/1 bound
for 100/2. The 100/2 is then attached before the message is routed
on to 100/3. The 100/3 is then attached to the message before it is
forwarded to 100/4 and 100/5. At 100/5, then, the path information
should look like this:
PATH 100/1 100/2 100/3 100/5
This is often abbreviated by software, making the assumption that if
no net number is provided, it is assumed to be the same as the last
listed net. In this (the most common) case, the PATH information
would include the net number only once (since no others are involved
in this message) and would simply be
PATH 100/1 2 3 5
If a message were originated at 100/2, the path at 100/4 would
appear as
PATH 100/2 3 4
and at 100/1, it would simply be
PATH 100/2 1
Where multiple nets are shown, paths might look like this:
PATH 100/1 2 13/13 104/1 115 114
This shows that a message was passed up from 100/1 to another node
(2) in that net, on to a star (13/13) system, to net 104, and down
through a couple of nodes in net 104 to the final destination of
104/114.
The next item of importance is the SEEN-BY line(s). This information
is used by each system along the PATH to determine who has seen the
message, and for whom copies need to be made. As a message is
processed by any system, SEEN-BYs are added for any systems for which
a copy is made by the processing system. Using our 5 node example
above, a message moving from 104/1 to 104/5 would function this way:
Message as sent from 100/1 SEEN-BY 100/1 2
Message as sent from 100/2 SEEN-BY 100/1 2 3
Message as sent from 100/3 SEEN-BY 100/1 2 3 4 5
Note that since 100/3 needs to make copies for both 100/4 and 100/5,
it adds the SEEN-BY for both nodes for which it has made copies.
Each system should provide itself in the SEEN-BY information when it
is the originating system. Why? If it did not do so, the next
system that received the message would send a copy back!
The method of deciding who should be receiving copies is usually one
format or another of a file called AREAS.* Various software
packages like to see this file in slightly different formats, but the
essential information there is the echo tag with the list of nodes
for which that system is responsible for making copies.
So, to wrap it up, the PATH shows how the message got from the
originator to anyone receiving the message, and the SEEN-BY shows
those systems for whom copies were made along the way.
Checking for the sources of duplicate messages is simplified by the
PATH information. By observing the two (or more) paths that the
message may have taken to get to the destination, it is often easy to
tell who has been sending the message to the wrong system(s), or
fouling up the SEEN-BY information along the way. Note that
clobbering SEEN-BY information or by making it unreadable to some
other system is guaranteed to create duplicate messages. Although
the PATH line must always begin with a "Control A" (a hex 01), the
SEEN-BY line should NEVER start with one of these. Most systems
won't "see" the SEEN-BY information if the line(s) start out that
way.
ORIGIN LINE
The origin line can be used by the sysop to provide any information
that helps identify the system that is originating the message. This
information always starts with a '*' and a space, and is typically
followed by the name and phone number of the originating system.
Do NOT include your net/node number in the origin line if your
software will add this automatically. All too often, new sysops add
this to the origin line info, only to discover it is being duplicated
by the software. Also, please note that much software won't display
an origin line of >80 characters total, so remember that when you
create your message, space must be left for the net/node and "*
Origin" information.
TEAR LINE
This line starts with a '---' and is appended by either the message
editor/BBS software, or the message packer. Some software will
delete any previously entered information and replace it with its own
as your message passes between your various programs. Others will
simply append a second origin line. That is frowned upon in most
nets as a waste of space.
HOW A MESSAGE LOOKS
Here's the "readable" portion of an EchoMail message, including a
couple of items we haven't yet discussed (note that not all software
allows the viewing of these items, even though they exist in the
message). The control A (01hex) character will be represented by a
"^" so that you can see where it would appear in the message.
AREA: ECHONAME
^EID: eid info
^MSGID: msgid info
^REPLY: zone:net/node
Text of the Message
* Origin: Origin line information (zone:net/node)
--- tear line information
SEEN-BY seenby nodes list
SEEN-BY continuation of list if required
^PATH path information
The EID information is designed to help your software check for
duplicate messages. Not all software uses this information for this
purpose. Most times, this is simply a check sum of information
within the message. The MSGID information was designed, as well as
the REPLY, to identify more accurately the originator of the message,
although MSGID has been used for duplicate checking as well.
When quoting any message with a message editor, it is important that
you not accidently leave any of the EID, MSGID, SEEN-BY or PATH
information resident in the message without something to preface it
that would keep software from recognizing it. For example, if you
have a need to quote the PATH information, be sure to delete any
little smiley-face that appears for the 01hex, and stuff something in
front of it (such as a ">") just to be safe. Some software will
automatically convert such information to a "safe" format when
quoted.
DUPLICATES
As you can imagine, a fouled up SEEN-BY line or two in a message can
cause a great number of duplicate messages to be created. Unless a
system using the EchoMail technique described above has the full
necessary SEEN-BY information, a system is likely to start generating
copies for people that should have been listed, but aren't. Broken
software can become a real problem here!
PACKERS and ARCHIVERS
There are numerous utilities in use out there for handling the
archiving and unarchiving of mail files.
Problem: Not all utilities are flexible about the file name extension
used for archived mail files. Not all systems can accept all
extension variations! Your mail files *may* not be unpacked by
the receiver under certain circumstances!
Problem: Some of the utilities used on other systems will create
packets improperly, generating "short packets" or other
anomolies. Fortunately, these are rare at present.
File extensions: Currently the following have been noted as file name
extensions that are being generated by various utilities:
A) FILENAME.MOn
"MO" (never changes) n=sequential number
This is an older and rather rare format. FLAME will
recognize files using this form.
B) FILENAME.ddn
dd=day of week (SU, MO, TU, WE etc.) n=sequential number
between 0 and 9. This is the most commonly seen format,
and is the style generated by FLAME under most
circumstances. FLAME recognizes files using this form.
C) FILENAME.ddx
dd=day of week (SU, MO, TU, WE etc.) n=sequential
number/letter depending on the half hour of the day during
packing (i.e., it will be 0-9 or A-Z depending on the time
of day). FLAME recognizes files using this form, but does
not generate them.
D) FILENAME.xxx
xxx=minute of the month in base 36 (using 0-9 and A-Z in
all three positions) This format is used by few systems,
but it is recognized by TIMS and generated by ARCMAIL if
it is configured to create such extensions. It virtually
guarantees a lack of accidental file overwrites on the
received system. FLAME can be asked to generate filenames
of this form, but this cannot be controlled on a
node-by-node basis, making it unusable in most situations.
Don't be surprised if the B formats does't always follow the
actual day of the week. Some just cycle through 10 digits in the
'n' position and then begin the next day regardless of the day of
the week when the file is created.
Formats A and B are acceptable to most systems. Many others can
deal satisfactorily with format C. A few recognize archives in
format D.
HOW ARCHIVE FILES ARE NAMED
Your system will probably be receiving and sending a great many
archived mail files. It helps to recognize the naming conventions
for these in order to identify their source or destination.
(apart from the extension, which we've already discussed):
Incoming and outgoing archived mail files use the following method
for the root portion of the name:
NNNNnnnn.ext
NNNN=sender's net number - receiver's net number
nnnn=sender's node number - receiver's node number
In both cases, the result is always expressed in 4 hexidecimal
digits.
Example: I am node 104/114. I am having mail transfers with
node 363/18. If I send an archived bundle to 363/18,
the result will be:
104-363 114-18
= -259 96 decimal
= FEFD 0060 hexidecimal
= FEFD0060.ext filename
If 363/18 sends something to me, on the other hand:
363-104 18-114
= 259 -96 decimal
= 0103 FFA0 hexidecimal
= 0103FFA0.ext filename
Both archiving and mailer software may make use of this convention to
determine where things are headed for. However, if both incoming and
outbound files are present in the same directory, there may well be
complete confusion for your mailer. AVOID THIS! Your mailer will
not be able to recognize which direction the archive is headed (in or
out).
Mail sent by 104/115 to 104/114 would look to the 104/114 mailer as
though it were either sent by 104/115 or *destined* for 104/113. The
filename would be identical. Keep your inbound and outbound files
areas separated.
104-104 115-114
= 0 1 decimal
= 0000 0001 hexidecimal
= 00000001.ext filename
Now, if this were an incoming file, it would be correctly interpreted
as a file *coming* from 104/115. But what if the mailer was asked to
deal with an outbound file instead? You'd get the following:
104-104 114-113
= 0 1 dec8imal
= 0000 0001 hexidecimal
= 00000001.ext filename