FidoNet: technology, tools, and history.
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 nonwindowed ACK/NAK protocol with 128-byte packets. Although rarely used in practice today, this protocol remains codified as the minimal basic standard implementation, since 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. The addressing scheme may be extended to accomodate 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.
The FidoNet nodelist, 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 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 worldwide hierarchic topology and enews via a worldwide ad hoc, but generally geographically hierarchic, acyclic graph.
Power users run points that 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, and so forth.
Within a local network (e.g., city), nodes usually exchange email directly with one another. In those cities where phone tariff zones divide the city, local hubs are used to concentrate intracity 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 by users), some local networks cooperate sufficiently to provide an outbound host to concentrate all mail destined for outside the city.
Each of the present six zones (continents) has a unique host which provides interzone 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 intercontental 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, for example, 1:105/42, has the domain 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 so 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,
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,
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 approximately one hundred gateway systems, most of them in North America. Aside from the expected internetwork 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 K12[underscore]Net 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 nongovernmental organizations (NGOs) in Africa, as well as by an ingenious transport between the South African academic IP network (UNINET-ZA) and the Internet .
FidoNet has currently over 20,000 distinct 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 (Oceania), 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 .
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 multiline 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 for 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 use enews, and 5% use private email. As not all FidoNet nodes have BBS access, we can estimate that on the order of 2 million FidoNet users read or write enews, and approximately 200,000 of these use private email.
In 1984, Tom Jennings wished to move messages from his MS-DOS-based Fido BBS to that of a friend, John Madill. 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 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 1985. The nodelist, a list of all known active nodes, was developed as a distributed external file and was initially maintained by Jennings. The reserved mail transfer hour became enshrined as zone 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 U.S. city are generally inexpensive, 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 Committe 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 the end of the year is illustrated in Table 1. 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 FidoNet users 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 (MB). 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 development began in 1986, with the publication of FSC-0001 describing the then-extant xmodem-based protocol suite and the basic data formats . This was shortly followed by a description of the nodelist in FSC-0002 . A FidoNet Standards Committee (now FTSC) was formed in 1986 by the then-active software authors, chaired by a nonauthor. 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 most interesting are depicted in Table 2. The current document set is kept on many FidoNet nodes and is available via ftp on the internet as (you may find this site generally useful for acquiring FidoNet supplies, such as documentation, tools, gateware).
Table 1: Year Nodes 1984 100 1985 600 1986 1,400 1987 2,500 1988 4,000 1989 6,500 1990 9,000 1991 11,000 1992 16,000 1993 20,000 (Apr '93) Table 2: Document Subject FTS-0001 Basic data formats and protocols FTS-0004 Format of echomail FTS-0005 Nodelist: syntax and semantics FTS-0006 Enhanced session and transport protocols FSC-0034 Control data embedded within message text
FTS-001 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 Telink, 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. Midfile restart recovery is also absent.
The FTS-0006 session and link layer protocols  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 midfile 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 and provides a mail and news user agent (M/NUA) to dial-up callers of the BBS, and it 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, multicolor, 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 interzone 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, and so forth. Because the mailer provides the link level protocols, its characteristics determine internode 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 anarchism to provide minimal-cost public access to email. 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) on 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, and is therefore generally observed.
The amazing resilience of FidoNet's social and technical structure was made evident yet again in 1989-'90, when the RCs on 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 others have since taken more passive and facilitative roles.
[1.] Baker, B. The distribution nodelist. FSC-0027.
[2.] Becker, P. YOOHOO and YOOHOO/2U2: The Netmail handshake used by Opus-CBCS and other intelligent FidoNet mail handling packages. FTS-0006.
[3.] Bush, R. A basic FidoNet technical standard. FTS-0001.
[4.] Guillarmod, E.J. From FidoNet to Internet: The evolution of a national network. In Proceedings of INET'92. 1992.
[5.] Murray, J. K12 Network: Global education through telecommunications. In Proceedings of INET'92. 1992.
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||international computer network|
|Publication:||Communications of the ACM|
|Date:||Aug 1, 1993|
|Next Article:||K12 Network: global education through telecommunications.|