Editing FidoNet (section)

==Technical structure==
FidoNet was historically designed to use modem-based [[Dial-up Internet access|dial-up]] access between bulletin board systems, and much of its policy and structure reflected this.

The FidoNet system officially referred only to the transfer of ''Netmail''&mdash;the individual private messages between people using bulletin boards&mdash;including the protocols and standards with which to support it. A netmail message would contain the name of the person sending, the name of the intended recipient, and the respective FidoNet addresses of each. The FidoNet system was responsible for routing the message from one system to the other (details below), with the bulletin board software on each end being responsible for ensuring that only the intended recipient could read it. Due to the hobbyist nature of the network, any privacy between the sender and recipient was only the result of politeness from the owners of the FidoNet systems involved in the mail's transfer. It was common, however, for system operators to reserve the right to review the content of mail that passed through their system.

Netmail allowed for the ''attachment'' of a single file to every message. This led to a series of ''piggyback'' protocols that built additional features onto FidoNet by passing information back and forth as file attachments. These included the automated distribution of files and transmission of data for inter-BBS games.

By far the most commonly used of these piggyback protocols was ''Echomail'', public discussions similar to [[Usenet]] newsgroups in nature. Echomail was supported by a variety of software that collected up new messages from the local BBSes' public forums (the ''scanner''), compressed it using [[ARC (file format)|ARC]] or [[ZIP (file format)|ZIP]], attached the resulting archive to a Netmail message, and sent that message to a selected system. On receiving such a message, identified because it was addressed to a particular ''user'', the reverse process was used to extract the messages, and a ''tosser'' put them back into the new system's forums.

Echomail was so popular that for many users, Echomail ''was'' the FidoNet. Private person-to-person Netmail was relatively rare.

===Geographical structure===
FidoNet is politically organized into a tree structure, with different parts of the tree electing their respective coordinators. The FidoNet hierarchy consists of ''zones'', ''regions'', ''networks'', ''nodes'' and ''points'' broken down more-or-less geographically.

The highest level is the zone, which is largely continent-based:
* Zone 1 is the [[United States]] and [[Canada]]
* Zone 2 is Europe, Former [[Soviet Union]] countries, and Israel
* Zone 3 is [[Australasia]]
* Zone 4 is [[Latin America]] (except [[Puerto Rico]])
* Zone 5 was [[Africa]]
* Zone 6 was Asia, Israel and the Asian parts of Russia, (which are listed in Zone 2). On 26 July 2007 zone 6 was removed, and all remaining nodes were moved to zone 3.<ref>{{Citation | last = Shenkenberger | first = Carol | editor-last = Felten  | editor-first = Björn | date =  26 July 2007 | publication-date = 30 July 2007 | title = Removal of Zone 6 | periodical = FidoNews | volume =24 | issue= 31 | page = 2 | url = http://www.fidotel.com/public/fidonews/archive/2007/FIDO2431.htm | access-date = 2010-10-08 | quote =With sadness I have removed the last entry for Zone6 as of this writing.  All remaining members have been transitioned to Zone3 as previously determined by Z6 members at large.}}</ref><ref>The message from the 2 zone coordinator Ward Dossche to 50 region coordinator about 6 zone dropping — http://alex-rex.livejournal.com/282920.html {{webarchive |url=https://web.archive.org/web/20120105190446/http://alex-rex.livejournal.com/282920.html |date=January 5, 2012}}</ref>

Each zone is broken down into regions, which are broken down into nets, which consist of individual nodes.  Zones 7-4095 are used for ''othernets''; groupings of nodes that use Fido-compatible software to carry their own independent message areas without being in any way controlled by FidoNet's political structure. Using un-used zone numbers would ensure that each network would have a unique set of addresses, avoiding potential routing conflicts and ambiguities for systems that belonged to more than one network.

===FidoNet addresses===
FidoNet addresses explicitly consist of a ''zone'' number, a ''network'' number (or region number), and a ''node'' number. They are written in the form <code>Zone:Network/Node</code>.{{sfn|Schuyler|1992|loc=Section 4.0}} The FidoNet structure also allows for semantic designation of region, host, and hub status for particular nodes, but this status is not directly indicated by the main address.

For example, consider a node located in [[Tulsa, Oklahoma]], [[United States]] with an assigned node number is 918, located in Zone 1 (North America), Region 19, and Network 170. The full FidoNet address for this system would be <code>1:170/918</code>.  The ''region'' was used for administrative purposes, and was only part of the address if the node was listed directly underneath the Regional Coordinator, rather than one of the networks that were used to divide the region further.

FidoNet policy requires that each FidoNet system maintain a ''nodelist'' of every other member system. Information on each node includes the name of the system or BBS, the name of the node operator, the geographic location, the telephone number, and software capabilities. The nodelist is updated weekly, to avoid unwanted calls to nodes that had shut down, with their phone numbers possibly having been reassigned for voice use by the respective telephone company.

To accomplish regular updates, coordinators of each network maintain the list of systems in their local areas. The lists are forwarded back to the International Coordinator via automated systems on a regular basis. The International Coordinator would then compile a new nodelist, and generate the [[diff|list of changes]] (nodediff) to be distributed for node operators to apply to their existing nodelist.

===Routing of FidoNet mail===
In a theoretical situation, a node would normally forward messages to a ''hub''. The hub, acting as a distribution point for mail, might then send the message to the Net Coordinator. From there it may be sent through a Regional Coordinator, or to some other system specifically set up for the function. Mail to other zones might be sent through a Zone Gate.

For example, a FidoNet message might follow the path:
*1:170/918 ''(node)'' to 1:170/900 ''(hub)'' to 1:170/0 ''(net coordinator)'' to 1:19/0 ''(region coordinator)'' to 1:1/0 ''(zone coordinator)''. From there, it was distributed 'down stream' to the destination node(s).

Originally there was no specific relationship between network numbers and the regions they reside in. In some areas of FidoNet, most notably in Zone 2, the relationship between region number and network number are entwined. For example, 2:201/329 is in Net 201 which is in Region 20 while 2:2410/330 is in Net 2410 which is in Region 24. Zone 2 also relates the node number to the hub number if the network is large enough to contain any hubs. This effect may be seen in the nodelist by looking at the structure of Net 2410 where node 2:2410/330 is listed under Hub 300. This is not the case in other zones.

In Zone 1, things are different.
Zone 1 was the starting point and when Zones and Regions were formed, the existing nets were divided up regionally with no set formula. The only consideration taken was where they were located geographically with respect to the region's mapped outline. As net numbers got added, the following formula was used.

<blockquote>
Region number × 20
</blockquote>
Then when some regions started running out of network numbers, the following was also used.
<blockquote>
Region number × 200
</blockquote>
Region 19, for instance, contains nets 380-399 and 3800–3999 in addition to those that were in Region 19 when it was formed.

Part of the objective behind the formation of local nets was to implement cost reduction plans by which all messages would be sent to one or more hubs or hosts in [[data compression|compressed form]] ([[ARC (file format)|ARC]] was nominally standard, but [[PKZIP]] is universally supported); one toll call could then be made during off-peak hours to exchange entire message-filled archives with an out-of-town uplink for further redistribution.

In practice, the FidoNet structure allows for any node to connect directly to any other, and node operators would sometimes form their own toll-calling arrangements on an ad-hoc basis, allowing for a balance between collective cost saving and timely delivery. For instance, if one node operator in a network offered to make regular toll calls to a particular system elsewhere, other operators might arrange to forward all of their mail destined for the remote system, and those near it, to the local volunteer.  Operators within individual networks would sometimes have cost-sharing arrangements, but it was also common for people to volunteer to pay for regular toll calls either out of generosity or to build their status in the community.

This ad-hoc system was particularly popular with networks that were built on top of FidoNet. Echomail, for instance, often involved relatively large file transfers due to its popularity. If official FidoNet distributors refused to transfer Echomail due to additional toll charges, other node operators would sometimes volunteer. In such cases, Echomail messages would be routed to the volunteers' systems instead.

The FidoNet system was best adapted to an environment in which local [[telephone]] service was inexpensive and long-distance calls (or intercity data transfer via [[packet-switched]] [[computer network|networks]]) costly. Therefore, it fared somewhat poorly in [[Japan]], where even local lines are expensive, or in [[France]], where tolls on local calls and competition with [[Minitel]] or other data networks limited its growth.

===Points===
As the number of messages in Echomail grew over time, it became very difficult for users to keep up with the volume while logged into their local BBS. ''Points'' were introduced to address this, allowing technically savvy users to receive the already compressed and batched Echomail (and Netmail) and read it locally on their own machines.{{sfn|Schuyler|1992|loc=Section 5}}

To do this, the FidoNet addressing scheme was extended with the addition of a final address segment, the point number. For instance, a user on the example system above might be given point number 10, and thus could be sent mail at the address <code>1:170/918.10</code>.

In real-world use, points are fairly difficult to set up. The FidoNet software typically consisted of a number of small utility programs run by manually edited scripts that required some level of technical ability. Reading and editing the mail required either a "sysop editor" program or a BBS program to be run locally.

In North America (Zone 1), where local calls are generally free, the benefits of the system were offset by its complexity. Points were used only briefly, and even then only to a limited degree. Dedicated [[offline mail reader]] programs such as Blue Wave, Squiggy and Silver Xpress (OPX) were introduced in the mid-1990s and quickly rendered the point system obsolete. Many of these packages supported the [[QWK (file format)|QWK]] offline mail standard.

In other parts of the world, especially Europe, this was different. In Europe, even local calls are generally metered, so there was a strong incentive to keep the duration of the calls as short as possible. Point software employs standard compression (ZIP, ARJ, etc.) and so keeps the calls down to a few minutes a day at most. In contrast to North America, pointing saw rapid and fairly widespread uptake in Europe.

Many regions distribute a pointlist in parallel with the nodelist. The pointlist segments are maintained by Net- and Region Pointlist Keepers and the Zone Point List Keeper assembles them into the Zone pointlist. At the peak of FidoNet there were over 120,000 points listed in the Zone 2 pointlist. Listing points is on a voluntary basis and not every point is listed, so how many points there really were is anybody's guess. As of June 2006, there are still some 50,000 listed points. Most of them are in Russia and Ukraine.

===Technical specifications===
FidoNet contained several technical specifications for compatibility between systems.  The most basic of all is ''FTS-0001'',<ref>{{cite web |url=http://ftsc.org/docs/fts-0001.016 |title=FTS-0001 |first=Randy|last=Bush |date=1995-09-30 |format=TXT |website=FidoNet Technical Standards Committee |url-status=live |archive-url=https://web.archive.org/web/20080530024932/http://ftsc.org/docs/fts-0001.016 |archive-date=2008-05-30 }}</ref> with which all FidoNet systems are required to comply as a minimum requirement.  FTS-0001 defined:
*Handshaking - the protocols used by mailer software to identify each other and exchange meta-information about the session.
*Transfer protocol ''([[XMODEM]])'' - the protocols to be used for transferring files containing FidoNet mail between systems.
*Message format - the standard format for FidoNet messages during the time which they were exchanged between systems.

Other specifications that were commonly used provided for ''echomail'', different transfer protocols and handshake methods (''e.g.: Yoohoo/Yoohoo2u2, EMSI''), file compression, nodelist format, transfer over reliable connections such as the Internet ([[Binkp]]), and other aspects.

===Zone mail hour===
Since computer bulletin boards historically used the same [[telephone line]]s for transferring mail as were used for dial-in human users of the BBS, FidoNet policy dictates that at least one designated line of each FidoNet node must be available for accepting mail from other FidoNet nodes during a particular hour of each day.{{sfn|Schuyler|1992|loc=Section 6.0}}

''Zone Mail Hour'', as it was named, varies depending on the geographic location of the node, and was designated to occur during the early morning.  The exact hour varies depending on the time zone, and any node with only one telephone line is required to reject human callers. In practice, particularly in later times, most FidoNet systems tend to accept mail at any time of day when the phone line is not busy, usually during night.