442 lines
24 KiB
Plaintext
442 lines
24 KiB
Plaintext
FidoNet: Technology, Use, Tools, and History
|
||
|
||
Randy Bush
|
||
randy@psg.com
|
||
|
||
Copyright 1992-3, Randy Bush. All rights reserved.
|
||
FidoNet is a trademark of Tom Jennings.
|
||
|
||
|
||
|
||
|
||
Abstract
|
||
|
||
FidoNet is a point-to-point and store-and-forward email WAN which uses
|
||
modems on the direct-dial telephone network. It was developed in 1984, and
|
||
has over 20,000 public nodes worldwide. Although originally based on MS-DOS
|
||
hosts, it has been ported to environments ranging from UNIX to the Apple //.
|
||
There are gateways from FidoNet to the Internet, usually via the uucp
|
||
network.
|
||
|
||
Technical Overview
|
||
|
||
The public FidoNet consists of over 20,000 nodes which move email and enews
|
||
over the public telephone network using a unique protocol and data format.
|
||
As the initial implementations were written for MS-DOS, DOS-based hosts are
|
||
still the vast majority of the network. But semi-formal specifications for
|
||
the data formats and protocols have facilitated implementations for UNIX,
|
||
Apples from the // to the Macintosh, CP/M, MVS, the Tandy CoCo, and many
|
||
other platforms.
|
||
|
||
As FidoNet is almost entirely financed by private individuals, minimization
|
||
of modem/telephone time has been the principal driving force behind any
|
||
design of the data transfer protocols. The original implementations used an
|
||
inefficient xmodem-based transport, a non-windowed ACK/NAK protocol with 128
|
||
byte packets. Although rarely used in practice, this protocol remains the
|
||
minimal basic standard implementation today as it is trivial to code.
|
||
Almost all current implementations offer an optional suite of quite
|
||
efficient zmodem-based streaming transport protocols which are ACK-less,
|
||
only NAKing in case of error. It is interesting to contrast this push for
|
||
efficiency with uucp's profligate G protocol and the Internet's SMTP and
|
||
NNTP protocols.
|
||
|
||
Addressing within FidoNet is numeric with a bit of punctuation, and
|
||
specifies a particular node in the administrative hierarchy. Addresses are
|
||
of the form zone:net/node where zone is one of the six continents (North
|
||
America, Europe, Oceania, Asia, or Africa), net is the city (or larger area
|
||
if the node density is sparse), and node is the particular host within the
|
||
local network. For example, 1:105/6 is host number six within the Portland
|
||
Oregon US local network (net 105) which is in North America ( zone 1). The
|
||
addressing scheme may be extended to accommodate points which are power
|
||
users who reduce their connect time by using private (i.e. unlisted) nodes
|
||
to exchange email and enews with public nodes. Thus the extended addressing
|
||
scheme is zone:net/node.point, e.g., 1:105/6.42.
|
||
|
||
A list of all nodes in the public FidoNet network is automatically updated
|
||
and distributed weekly. This list contains the actual data telephone number
|
||
of each host, as well as the geographic location and name of the system
|
||
operator (sysop). Every city's local network maintains its local data and
|
||
sends those data to a regional coordinator who, in turn, sends the region's
|
||
aggregated data to a continental coordinator. The continental coordinators
|
||
exchange their data, and create a list of the differences between the
|
||
current week's data and that of the previous week. This `nodediff' is then
|
||
distributed back down the hierarchy all the way to each individual node in
|
||
the network.
|
||
|
||
As all modem phone numbers are published in the nodelist, point-to-point
|
||
transfers are always possible. But, as store-and-forward capabilities are
|
||
specified in the basic standards, email tends to be routed through a
|
||
world-wide hierarchic topology and enews via a world-wide ad hoc, but
|
||
generally geographically hierarchic, acyclic graph.
|
||
|
||
Topology
|
||
|
||
FidoNet's addressing hierarchy - zone, net, node, point - approximates the
|
||
route which email follows.
|
||
|
||
Power users run points which may connect to only their respective host nodes
|
||
to receive and deliver their email and enews. As they are not in the public
|
||
nodelist, points are not considered to be official nodes in the network, and
|
||
thus are not subject to constraints of technology, national mail hour, etc.
|
||
|
||
Within a local network (i.e. city), nodes usually exchange email directly
|
||
with each other. For example, 1:105/6 exchanges mail directly with all
|
||
other nodes in 1:105/*. In those cities where phone tariff zones divide the
|
||
city, local hubs are used to concentrate intra-city traffic to reduce costs.
|
||
|
||
Each local network has one node with an alias of node 0 (i.e. zone:net/0)
|
||
which is known as the "inbound host." By default, all mail from outside the
|
||
local net is delivered to the inbound host to be distributed within the
|
||
local network. Thus, a node in New York may deliver all mail to San
|
||
Francisco with a single telephone call, as opposed to a call for every SF
|
||
node for which it has mail. While each node is responsible for sending its
|
||
own mail (as FidoNet is financed from the pockets of individuals), some
|
||
local networks cooperate sufficiently to provide an "outbound host" to
|
||
concentrate all mail destined for outside the city.
|
||
|
||
Each of the six zones (continents) has a unique host which provides
|
||
inter-zone email routing. These "zonegates" have alias addresses of the form
|
||
orig-zone:orig-zone/dest-zone. For example, the gate from North America
|
||
(zone 1) to Oceania (zone 3) has an addressing alias of the form 1:1/3.
|
||
Hence, a node in North America may save the cost of an inter-continental
|
||
call to Australia by sending the message to 1:1/3, which will in turn send
|
||
it to 3:3/1, which will see that it is delivered within Australia.
|
||
|
||
Since November, 1991, an experimental system has been using the Internet to
|
||
transport mail and enews between Europe and North America. The data are
|
||
moved directly between the zonegates via IP (i.e. not gated between data
|
||
formats) courtesy of RIPE and EUnet. This saves FidoNet operators thousands
|
||
of dollars a month. Since late in 1992, this tunneling of the Internet has
|
||
been extended to Taiwan, Southern Africa, Chile, and other areas. This is
|
||
done with the explicit consent of the IP carriers involved, to whom FidoNet
|
||
owes a considerable debt of gratitude.
|
||
|
||
Gateways to the Other Networks
|
||
|
||
There are gateways between FidoNet and the uucp network, and thereby the
|
||
Internet. FidoNet is addressable from the Internet DNS universe via the DNS
|
||
zone fidonet.org. A FidoNet node e.g. 1:105/42 has the domainized name
|
||
f6.n105.z1.fidonet.org. Gating is done almost exclusively via the uucp
|
||
network. The MX forwarders for the fidonet.org zone are set up such that
|
||
there is default forwarding for all FidoNet hosts should there be no gateway
|
||
which is local to the target host.
|
||
|
||
The correct RFC822 address for a FidoNet power user at point zo:ne/no.po
|
||
is user@Ppo.Fno.Nne.Zzo.FIDONET.ORG. For example,
|
||
|
||
randy.bush@p0.f42.n105.z1.fidonet.org
|
||
|
||
And, as points are optional in FidoNet, Jane User at the BBS user at node
|
||
zone:net/node is user@Fnode.Nnet.Zzone.FIDONET.ORG. For example,
|
||
|
||
lisa.gronke@f6.n105.z1.fidonet.org
|
||
|
||
The UFGATE package, which allows an MS-DOS-based FidoNet node to simulate a
|
||
uucp host, gates both email and enews. This package made gating fairly
|
||
popular by 1987. More recently, other DOS packages have provided similar
|
||
features. RFmail, a complete FidoNet implementation which runs on UNIX SysV
|
||
and Xenix, includes gateware to transform between FidoNet message format and
|
||
that of the uucp/Internet.
|
||
|
||
Currently there are on the order of one hundred gateway systems, most of
|
||
them in North America. Aside from the expected inter-network email, there
|
||
is considerable gating of Usenet news to and from FidoNet echomail
|
||
conferences.
|
||
|
||
A number of newsgroups are shared globally by FidoNet and the Usenet, e.g.
|
||
FidoNet's MODULA-2 echomail conference is Usenet's comp.lang.modula2 and
|
||
FidoNet's K12Net conferences are the Usenet's k12.* hierarchy. Usenet
|
||
newsgroups are also made available on a purely local basis in many cities as
|
||
FidoNet echomail.
|
||
|
||
Internetwork gateways have been used extensively by non-governmental
|
||
organizations (NGOs) in Africa, as well as by an ingenious transport between
|
||
the South African academic IP network (UNINET-ZA) and the Internet
|
||
[Guillarmod 92].
|
||
|
||
Users
|
||
|
||
The public FidoNet has approximately 20,000 nodes worldwide. Although
|
||
FidoNet started in North America, by 1985 there were systems in Europe, very
|
||
soon followed by systems on the other continents. Currently, about 59% of
|
||
the publicly listed nodes are in North America, 30% in Europe, 4% in
|
||
Australia and New Zealand, and 7% in Asia, Latin America, and Africa.
|
||
|
||
FidoNet technology is also used privately within large corporations, public
|
||
institutions, and NGOs. While the scale of the private use of FidoNet is
|
||
not known, it is estimated to be at least as large as the public network.
|
||
It is known to be used in companies such as AT&T, Georgia Pacific, and the
|
||
Canadian Post Office, among others. It is heavily used by NGOs in Africa.
|
||
|
||
While hobbyists and public BBSs predominate the North American FidoNet,
|
||
perhaps half of the public systems in Europe are subsidized by small to
|
||
medium-scale businesses. In Africa, there is very serious use by NGOs and
|
||
poorly-funded academic institutions. Within North America, there is growing
|
||
use within the school systems thanks to the spreading K12Net [Murray 92].
|
||
|
||
While the original FidoNet systems were fully integrated within bulletin
|
||
board systems, FidoNet "mail-only" systems are now a noticeable portion of
|
||
the public network. These provide the owner a facility similar to ham radio
|
||
or a fax machine, but provide no public access via dial-up.
|
||
|
||
Around the world, BBSs with FidoNet capability provide the most publicly
|
||
accessible and lowest-cost email and enews service today. While most BBSs
|
||
are only usable by a single dial-up caller at a time, others run multi-line
|
||
systems ranging from two to 20 lines. Public access requirements vary from
|
||
formal user validation and possibly a small fee to completely open
|
||
facilities allowing full use by the first-time caller.
|
||
|
||
Although no formal measurements have been made, it has been estimated that
|
||
the average FidoNet BBS has over 200 active users, half of whom use enews
|
||
and 5% use private email. As not all FidoNet nodes have BBS access, we can
|
||
estimate that on the order of 2,000,000 FidoNet users read or write enews,
|
||
and on the order of 200,000 of these use private email.
|
||
|
||
History
|
||
|
||
In 1984, Tom Jennings wished to move messages from his MS-DOS-based Fido BBS
|
||
to that of a friend, John Madil. As Jennings was the author of the Fido
|
||
BBS, he was able to quickly modify it to extract messages from a specially-
|
||
designated local message base and queue them for sending to the remote BBS.
|
||
As US telephone rates are much lower in the middle of the night, he wrote a
|
||
separate external program to run this email transfer for one designated hour
|
||
to exchange mail with the other node.
|
||
|
||
This soon grew to more nodes, reaching 200 by early in 1985. The nodelist,
|
||
a list of all known active nodes in the public FidoNet, was developed as a
|
||
distributed external file and was initially maintained by Jennings. The
|
||
reserved mail transfer hour became enshrined as "national mail hour," and is
|
||
preserved today despite current technology being capable of intermixing mail
|
||
transfer and BBS access.
|
||
|
||
With the porting of FidoNet to the DEC Rainbow, FidoNet BBSs became quite
|
||
popular with the DEC Users Group in St. Louis Missouri. Ken Kaplan and Ben
|
||
Baker were particularly active, and started the first FidoNet newsletter.
|
||
As the nodelist approached 100 members, Kaplan and Baker took over from
|
||
Jennings its organization and maintenance.
|
||
|
||
As the nodelist passed the 200 mark, it became obvious that, for example,
|
||
San Francisco had much daily traffic for St. Louis and vice versa, and
|
||
dozens of telephone calls were being placed to all the various nodes in each
|
||
city. As calls within a city of the US are generally free, but calls
|
||
between cities are not, it seemed obvious to concentrate the intercity
|
||
traffic into one call per night. Therefore, what had been a simple linear
|
||
nodelist was broken into a structure of city segments transforming the
|
||
FidoNet address notation from node to net/node.
|
||
|
||
In late 1986, it became obvious that an analogous problem existed between
|
||
the continents. At the same time, the idea emerged of power users, or
|
||
points, who could use FidoNet data formats and transport protocols (as
|
||
opposed to BBS interfaces) to send and receive their mail and enews. So, at
|
||
a FidoNet Standards Committee meeting in October 1986, the nodelist was
|
||
redesigned as a four level hierarchy of zone (continent), net, node, and
|
||
point, with the address becoming zone:net/node.point, as it remains today.
|
||
|
||
The rate of growth of FidoNet seems typical of electronic networks in the
|
||
last decade. The approximate number of nodes at year ends is:
|
||
|
||
Year Nodes
|
||
|
||
1984 100
|
||
1985 600
|
||
1986 1400
|
||
1987 2500
|
||
1988 4000
|
||
1989 6500
|
||
1990 9000
|
||
1991 11000
|
||
1992 16000
|
||
1993 20000 (Apr '93)
|
||
|
||
At present, the registered public FidoNet is considerably larger than BITNET
|
||
and has recently passed the estimated size of the registered part of the
|
||
uucp network.
|
||
|
||
In February 1986, Jeff Rush developed FidoNet's form of enews called
|
||
echomail. As very few FidoNetters were familiar with the Usenet, they were
|
||
quite surprised at the popularity and rate of growth of echomail. Within
|
||
two weeks, an international echomail conference, MODULA-2, was propagated
|
||
between Europe, Australia, and North America, and today the daily volume of
|
||
compressed echomail is over eight megabytes. The social effects, both good
|
||
and bad, of echomail on the network parallel those of the Usenet.
|
||
|
||
Although primitive experiments had been conducted earlier, in 1986 gateways
|
||
between FidoNet and the uucp network, and hence the Internet, became
|
||
sufficiently reliable for production use.
|
||
|
||
Technical Standards
|
||
|
||
Technical standards development began in 1986, with the publication of
|
||
FSC-0001 describing the then-extant xmodem-based protocol suite and the
|
||
basic data formats [Bush 1986]. This was shortly followed by a description
|
||
of the nodelist in FSC-0002 [Baker 87]. A FidoNet Standards Committee (now
|
||
FTSC) was formed in 1986 by the then-active software authors, chaired by a
|
||
non-author. The FTSC collects and publishes documents called FSCs, which
|
||
are similar to the IETF's RFCs. Those which are voted as formal standards
|
||
are known as FTS documents.
|
||
|
||
There are approximately 80 FSC documents at this time and five official FTS
|
||
standards. Some of the more interesting are:
|
||
|
||
Document Topic
|
||
FTS-0001 basic data formats and protocols
|
||
FTS-0004 format of echomail
|
||
FTS-0005 syntax and semantics of the nodelist
|
||
FTS-0006 enhanced session and transport protocols
|
||
FSC-0034 control data embedded within message text
|
||
|
||
The current document set is kept on many FidoNet nodes and is available via
|
||
ftp on the internet as
|
||
|
||
ftp.psg.com:~/pub/fidonet/stds/*
|
||
|
||
FTS-0001 describes the original message data formats, session protocols, and
|
||
link layer protocols for FidoNet as it was originally developed by Tom
|
||
Jennings. The ability for a node to obey this standard is mandatory if it
|
||
wishes to be listed within the public FidoNet, although the vast majority of
|
||
connections now use the far more efficient FTS-0006 suite. Data transfer
|
||
uses xmodem and a variant called TLink, 128 byte block ACK/NAK protocols,
|
||
neither of which is streaming, bidirectional, or windowing, and which
|
||
discriminate between email and file transfer at the session and data
|
||
transfer level. Mid-file restart recovery is also absent.
|
||
|
||
The FTS-0006 session and link layer protocols [Becker 90] were developed by
|
||
Wynn Wagner and Vince Perriello in 1987 to overcome the serious inefficiency
|
||
of FTS-0001. The default data link layer described uses zmodem, a very
|
||
efficient streaming, windowing, and ACK-less (NAK only on failure) protocol
|
||
designed by Chuck Forsberg. It also provides mid-file restart recovery. The
|
||
YooHoo/2U2 session level protocol provides for exchange of identification
|
||
and authorization data as well as allowing negotiation of the link layer
|
||
protocol.
|
||
|
||
Common Software Components
|
||
|
||
Like their uucp/Internet brethren, FidoNet systems tend to have different
|
||
components to act as user, transfer/routing, and transport agents. While
|
||
not all FidoNet implementations are composed identically, on the whole the
|
||
following concepts and nomenclature are understood throughout FidoNet.
|
||
|
||
A Bulletin Board System (BBS) is often available which provides a mail and
|
||
news user agent (M/NUA) to dial-up callers of the BBS, and often provides a
|
||
console interface for the system operator as well. As BBS M/NUAs must be
|
||
usable by dial-up users on unspecified terminals, the interfaces tend to be
|
||
line oriented with rather primitive editing facilities. Some BBS systems
|
||
such as Fido and Opus provide complete software suites integrating all
|
||
components necessary to use FidoNet, while most other BBSs require the
|
||
addition of external components to use them with FidoNet.
|
||
|
||
An Editor is a console M/NUA which is usually available for those nodes
|
||
which do not have a BBS or where the system operator prefers a different
|
||
interface. As the system console generally has known characteristics,
|
||
Editor M/NUAs tend toward screen-oriented, multi-color, fancy interfaces,
|
||
often with quite sophisticated editing capabilities.
|
||
|
||
A Packer or Scanner is analogous to the mail/news transfer agent (M/NTA). It
|
||
transforms the data to/from the internal (i.e. not standardized) storage
|
||
format from/to the external FTS-0001/4 transmission format. Packer M/NTAs
|
||
also make routing decisions, usually based on data in a local routing rule
|
||
file. These local routing rules tell the M/NTA what routes to use for mail
|
||
within the local city network, cost-reduction routes for mail within the
|
||
zone, and any special routes for inter-zone mail. The NTA portion uses an
|
||
echomail rule base to decide which echomail groups are to be exchanged with
|
||
which other nodes in the network.
|
||
|
||
A Mailer is the session and link level transport layer which decides when to
|
||
make and accept FidoNet calls to/from other nodes, and provides everything
|
||
needed to transport the email, enews, and files between FidoNet nodes.
|
||
Mailers know about modems and how to control them, how to detect if an
|
||
incoming call is a human BBS user as opposed to an incoming FidoNet call,
|
||
how to pass humans through to a BBS, what times of day to place expensive
|
||
but time-dependent calls, etc. Because the mailer provides the link level
|
||
protocols, its characteristics determine inter-node compatibility; therefore
|
||
a node is best known for the mailer it runs. Hence a node might be known as
|
||
a Binkley node or a Fido node because it uses BinkleyTerm or Fido as its
|
||
mailer.
|
||
|
||
A Nodelist Compiler transforms the nodelist from the standard FTS-0005
|
||
distribution format to that needed by the node's other software, i.e.
|
||
mailer, BBS, editor, and/or packer. Aside from trivial differences in
|
||
syntax, more complex translations may be needed. I.e. mailer software
|
||
usually requires that telephone numbers be transformed given local rules.
|
||
|
||
Policy and Politics
|
||
|
||
In contrast to the uucp network or the Internet, and due mostly to the low
|
||
cost of entry, from its earliest days, FidoNet has been owned and operated
|
||
primarily by end-users and hobbyists more than by computer professionals.
|
||
Therefore, social and political issues arose in FidoNet far faster and more
|
||
seriously than might be expected by those raised in other network cultures.
|
||
|
||
Tom Jennings intended FidoNet to be a cooperative anarchy to provide
|
||
minimal-cost public access to electronic mail. Two very basic features of
|
||
FidoNet encourage this. Every node is self-sufficient, needing no support
|
||
from other nodes to operate. But more significant is that the nodelist
|
||
contains the modem telephone number of all nodes, allowing any node to
|
||
communicate with any other node without the aid or consent of technical or
|
||
political groups at any level. This is in strong contrast to the uucp
|
||
network, BITNET, and the Internet.
|
||
|
||
In 1985, the first FidoNet policy document was published. It concerned
|
||
itself almost entirely with technical procedural issues. It required a
|
||
capability to send and receive email, defined the "national mail hour" as
|
||
mandatory, delineated roles of the local network hubs and nodelist
|
||
coordinators, and stated simple restrictions on routing of traffic through
|
||
unsuspecting nodes. In addition, it stated two social rules, a proscription
|
||
against use of the network for illegal purposes (e.g. pirated software) and
|
||
a statement of FidoNet's basic social guideline, "Do not be excessively
|
||
annoying and do not become excessively annoyed."
|
||
|
||
In 1986, a well-intentioned but naive group formed the International FidoNet
|
||
Association, intending to promulgate the technology and coordinate
|
||
publication of the newsletter and other writings about the network.
|
||
Unfortunately, as FidoNet operators were far more socially oriented than
|
||
their more technical brethren in the other networks, the formal organization
|
||
of IFNA tended to draw considerable political interest and attracted the
|
||
less constructive political elements of the FidoNet culture. The issue came
|
||
to a head in 1989 with an attempt to load the IFNA board of directors and
|
||
pass a motion which explicitly put IFNA in complete control of the network.
|
||
The motion was cleverly forced into a netwide referendum (FidoNet's only
|
||
global vote to date) which required a majority of the network assent to IFNA
|
||
rule. The referendum did not pass, and IFNA was subsequently dissolved.
|
||
|
||
The first written policy was published and adopted by informal consent.
|
||
Subsequently, three revisions of FidoNet policy have been written and made
|
||
operational by various, but less democratic, procedures. The current
|
||
document, Policy-4, was written by the regional nodelist coordinators, and
|
||
has a large amount of social and political content enshrining a hierarchy of
|
||
coordinators: an International Coordinator (IC), a Zone Coordinator (ZC) in
|
||
each continent, Regional Coordinators (RCs) in subdivisions of the
|
||
continents, usually countries, and a Network Coordinator (NC) for each local
|
||
network. As it was written by the self-anointed RCs, ZCs and the IC are
|
||
elected by the RCs and NCs are appointed by the RCs. Although the document
|
||
has caused considerable acrimony and is large and complex, it contains many
|
||
useful operational guidelines, so is generally observed.
|
||
|
||
The amazing resilience of FidoNet's social and technical structure was made
|
||
evident yet again in 1989-90, when the RCs in many of the continents
|
||
attempted to exert serious social control under the recently published
|
||
Policy-4. While echomail provided quite high-bandwidth (albeit low content)
|
||
communication, and thus the political situation could be openly debated, the
|
||
power structure's inability to restrict node-to-node communication prevented
|
||
any real control from being effected. A fair number of RCs and NCs were
|
||
forced to resign, and the rest have since taken more passive and
|
||
facilitative roles.
|
||
|
||
Bibliography
|
||
|
||
[Baker 87] Ben Baker, FSC-0027, "The Distribution Nodelist"
|
||
|
||
[Becker 90] Phil Becker, FTS-0006, "YOOHOO and YOOHOO/2U2: The netmail
|
||
handshake used by Opus-CBCS and other intelligent FidoNet mail handling
|
||
packages"
|
||
|
||
[Bush 86] Randy Bush, FTS-0001, "A Basic FidoNet Technical Standard"
|
||
|
||
[Guillarmod 92] F. Jacot Guillarmod, "From FidoNet to Internet: the
|
||
evolution of a national network", "Proceedings of INET'92", H. Ishida
|
||
Editor.
|
||
|
||
[Murray 92] Murray, Janet, "K12 Network: Global Education through
|
||
Telecommunications", "Proceedings of INET'92", H. Ishida Editor.
|
||
|
||
|