MSGID: 1:153/757.1315 1999e809   
   CHRS: CP866 2   
   TZUTC: 0300   
                   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.   
      
   --- WinPoint Beta 5 (359.1)   
    * Origin: WinPoint (1:153/757.1315)   
   SEEN-BY: 1/123 15/0 18/200 90/1 105/81 106/201 120/340 616 123/10   
   SEEN-BY: 123/131 129/305 134/100 153/135 149 757 6809 7715 154/10   
   SEEN-BY: 154/50 218/700 840 220/90 221/6 226/18 30 227/114 229/110   
   SEEN-BY: 229/111 112 113 114 206 307 317 400 424 426 428 452 470 664   
   SEEN-BY: 229/700 266/512 280/464 282/1038 292/854 301/1 317/3 320/219   
   SEEN-BY: 322/757 342/200 396/45 460/58 633/280 712/848 2320/105 3634/12   
   PATH: 153/757 221/6 154/10 229/426