447 lines
19 KiB
Plaintext
447 lines
19 KiB
Plaintext
* Fido/FidoNet Routing, Topology, History, and Recent Changes
|
||
Tom Jennings, 1:125/111
|
||
15 June 89
|
||
|
||
Fido/FidoNet, like all other FidoNet mailers and BBSs, generates<65>
|
||
messages, and puts them into packets that are later delivered to<74>
|
||
some appropriate destination by the mailer itself. All of the<68>
|
||
different mailers use different approaches as to just how you the<68>
|
||
sysop control where, how and when packets (and the messages they<65>
|
||
contain) get delivered.
|
||
|
||
In light of all the mailer systems out there today, I don't think<6E>
|
||
many are aware of just how Fido/FidoNet does it's routing. With a<>
|
||
few recent changes you might find the design has become<6D>
|
||
interesting once again. (And starting July 89, Fido/FidoNet is
|
||
once again shareware. File Request "ABOUT" and "FILES" from
|
||
1:125/111 for complete details.)
|
||
|
||
FIDO
|
||
|
||
Fido was originally just a bulletin board; the first FidoNet was<61>
|
||
a separate program that was run from a batch file with a few<65>
|
||
small hooks into the BBS. (The origin of the Fido version 9 - 11<31>
|
||
MAIL.SYS file.) Fido (the BBS) only let users generate messages;<3B>
|
||
FidoNet (the mailer) put messages into packets and delivered<65>
|
||
them.
|
||
|
||
At this point, four years later, Fido and FidoNet are pretty well<6C>
|
||
integrated, and this latest revision completes the weld.<2E>
|
||
Logically, to the user and sysop, the two remain quite separate,<2C>
|
||
and many (non-FidoNet) Fido systems are BBS only. (Most of my<6D>
|
||
commercial customers are BBS only.) It is just as easy to run<75>
|
||
FidoNet without Fido.
|
||
|
||
Fido's packeting/mailing system works in four discrete phases.<2E>
|
||
First, the destination node addresses for all the existing<6E>
|
||
messages is determined. This is done by the "router", more on<6F>
|
||
which follows. Second, the messages are put into packets by the<68>
|
||
"packeter" (I never was very good at names). Third, the phase<73>
|
||
that is most obvious to sysops watching the screen, is when the<68>
|
||
packets are delivered; Fido makes outgoing phone calls and sends<64>
|
||
the packets. Packets can also be received in between outgoing<6E>
|
||
calls. The last phase deletes un-sent packets, and marks the<68>
|
||
original messages that went into the packets as "(SENT)" as<61>
|
||
appropriate. This ends the FidoNet session.
|
||
|
||
Note that different from Opus and other similar mailers, Fido<64>
|
||
only puts a copy of the message into a packet; during the fourth<74>
|
||
phase Fido again processes each message, and marks it or deletes<65>
|
||
it as determined by the success of that packet delivery.
|
||
|
||
This is a fairly large amount of processing to do when looked at<61>
|
||
on a per-message basis, and is why Fido's FidoNet has always been<65>
|
||
slower to packet than other systems. In return there are many<6E>
|
||
advantages, that will become more obvious later.
|
||
|
||
FIDO AND FIDONET
|
||
|
||
Originally, as was stated before, Fido and FidoNet were two<77>
|
||
separate programs. Even when integrated into one package,<2C>
|
||
starting with Fido version 9 or 10, FidoNet was only usable when<65>
|
||
a FidoNet scheduled event was actually running; "continuous mail"<22>
|
||
is (relative to Fido) a new concept. Version 12 (Aug. 1987) could<6C>
|
||
accept incoming continuous mail, but not send mail unless a<>
|
||
FidoNet event was running; starting with 12M Wazoo and .REQ file<6C>
|
||
requests are supported.
|
||
|
||
Starting with version 12N, the FidoNet portion of Fido can be<62>
|
||
accessed at any time; packet creation and routing is under<65>
|
||
complete control, and can be altered, automatically using the<68>
|
||
routing language on a event by event basis throughout the day, or<6F>
|
||
manually as the sysop sees fit, up to the point when the specific<69>
|
||
message has been delivered. Events themselves can be turned on<6F>
|
||
and off from within Fido, allowing very high-level control over<65>
|
||
packet routing.
|
||
|
||
You can have Fido create packets available for pickup, with any<6E>
|
||
arbitrary routing, at any time of day. For example, you can have<76>
|
||
HOLD packets of long-distance systems waiting for pickup from<6F>
|
||
9:00AM til 6:00PM, while enabling outgoing calls on local-dial<61>
|
||
systems, in between human callers, or any other construct allowed<65>
|
||
by the routing language, without restriction. There is a<>
|
||
"penalty" of 30 - 60 seconds to prepare for a new schedule; once<63>
|
||
started, access is in the under 100 mS range.
|
||
|
||
On my 8MHz "turbo" junk-pclone, 80mS 20 meg drive, Fido takes 30<33>
|
||
seconds to load, create outgoing packets and be ready for an<61>
|
||
incoming call (human or otherwise). On this crappy hardware,<2C>
|
||
incoming echomail is received, unpacketed, tossed, the echo areas<61>
|
||
then scanned and outgoing packets made and delivered in 30 - 60<36>
|
||
seconds, in between human callers, using DCM and barefoot<6F>
|
||
Fido/FidoNet 12N.
|
||
|
||
The largest network Fido/FidoNet can (mathematically!) handle is<69>
|
||
(32767 * 32767 * 32767) or 3.5 x 10(e13) nodes; version 12's<>
|
||
implementation 65,535. A recompile (change a table index from 16<31>
|
||
to 32 bits) will make Fido handle about 4 billion nodes with some<6D>
|
||
performance loss and increased (disk) overhead, about 2<>
|
||
bytes/node. Performance with 65,000 nodes would still be better<65>
|
||
than Fido 12M's.
|
||
|
||
Current nodelist overhead (NODELIST.132) is: NODELIST.BBS 304,532<33>
|
||
(physical data); NODELIST.NMP 53,920 (nodemap; see below);<3B>
|
||
NODELIST.IDX 53920 (main index); NODELIST.NDX 2900 (host index).<2E>
|
||
NODELIST.SYS is no longer used.
|
||
|
||
FIDONET TOPOLOGY
|
||
|
||
The router design mimics exactly the FidoNet network topology.<2E>
|
||
The network went through four (so far...) stages: a "flat"<22>
|
||
system, ie. point to point; addresses were a simple number 1 -<2D>
|
||
32767. The second formalized the concept of "nets", incorporating<6E>
|
||
the routing optimization formerly done with Fido's primitive<76>
|
||
router. The third includes zones, which are similar<61>
|
||
mathematically to nets, but in real life act quite differently,<2C>
|
||
with "zone gates" concentrating mail between zones (generally<6C>
|
||
continents) because of real-life issues of telephone connect<63>
|
||
costs and equipment compatibility. The fourth adds "points",<2C>
|
||
allowing for the next (or current, I am a bit slow sometimes)<29>
|
||
wave of BBS technology.
|
||
|
||
OOPS BACKTRACK A LITTLE:
|
||
|
||
A small aside on nets and regions: "regions" originally were only<6C>
|
||
a way for nodes not in a net (ie. not inside a local calling<6E>
|
||
area) to be syntactically compatible with the "net/node"<22>
|
||
addressing scheme; since most nodes were in the most heavily<6C>
|
||
populated areas, cities, where nets naturally form, "regions"<22>
|
||
would be where nodes not in cities would be found. Nodes in<69>
|
||
regions (marked REGION in the nodelist) act as any other node,<2C>
|
||
but the mailers do not do the automatic routing to the "host" for<6F>
|
||
the region -- mail is sent direct, or point to point.
|
||
|
||
The function of region hosts as another layer of organizational<61>
|
||
hierarchy is a recent addition, and not part of the topology<67>
|
||
itself. Still further, there is nothing magic about the numbers<72>
|
||
themselves -- regions being numbered 1 - 99, nets 100 - 999 etc<74>
|
||
is a totally arbitrary decision on the part of the keepers-of
|
||
the-lists. The only magic numbers are 0's -- these indicate the<68>
|
||
host for the entity, ie. zone, net or region.
|
||
|
||
ROUTER DESIGN
|
||
|
||
Back to the router design. While the hierarchical model of<6F>
|
||
net/node is extremely useful (if not indispensable) there are<72>
|
||
still thousands of exceptions, usually on a system by system<65>
|
||
basis; you forward mail for one system that is local but is a<>
|
||
toll call for other net members. Your net has a sugar daddy that<61>
|
||
can make long distance outgoing calls. One system calls in to<74>
|
||
pickup their mail. Commonly called systems are more efficiently<6C>
|
||
handled in some special way.
|
||
|
||
You need to remember that the mathematical model used frequently<6C>
|
||
has nothing to do with the "real" world. This is as it should be.<2E>
|
||
However, you need a good solid theoretical base for the network<72>
|
||
otherwise the world falls apart. The router bridges the two<77>
|
||
otherwise-incompatible worlds.
|
||
|
||
Fido's router design can handle any topology based on our address<73>
|
||
syntax: zone:net/node, plus any arbitrary number of exceptions.<2E>
|
||
To do this, the router is very simple -- not complex.
|
||
|
||
Logically, the router is an N x N crossbar switch, where N is the<68>
|
||
number of nodes in the nodelist. You can imagine a crossbar<61>
|
||
switch by drawing on paper a grid:
|
||
|
||
IN
|
||
--> 1 ----O---O---O---O---O
|
||
| | | | |
|
||
2 ----O---O---O---O---O
|
||
| | | | |
|
||
3 ----O---X---O---O---O
|
||
| | | | |
|
||
4 ----O---O---O---O---O
|
||
| | | | |
|
||
5 ----O---O---O---O---O
|
||
| | | | |
|
||
1 2 3 4 5
|
||
OUT
|
||
|
||
Shown is a 5 x 5 crossbar switch. The O's represent an OFF (but<75>
|
||
potential) connection; X's represent a ON connection. The<68>
|
||
connection (3,2) is ON, all others closed. If a signal were<72>
|
||
applied to Input 3, it would appear also on Output 2. (ASCII<49>
|
||
graphics are terrible, sorry!) You will notice that by placing<6E>
|
||
X's and O's appropriately, any input can be connected to any<6E>
|
||
output.
|
||
|
||
A "real" crossbar switch can route one signal to many<6E>
|
||
destinations; just place X's along the same horizontal row in the<68>
|
||
example above. Any node can route to any node; times (N) nodes is<69>
|
||
(N * N) possible states. Not pleasant to think about in real<61>
|
||
terms -- a 5000 node nodelist would mean 25,000,000 states to<74>
|
||
represent on your disk! This is not a very useful side effect for<6F>
|
||
us; our messages have a single destination address.
|
||
|
||
Fido's router places one limitation upon the crossbar design:<3A>
|
||
there can be only one possible destination per node. It can still<6C>
|
||
be any possible node, but only one at a time. This means the<68>
|
||
router can consist of (2 * N) entries -- the originating node and<6E>
|
||
the destination node.
|
||
|
||
You can imagine Fido's router as the crossbar switch above, or as<61>
|
||
I do, a simple two column table:
|
||
|
||
----+----
|
||
1 | _
|
||
2 | _
|
||
3 | 2
|
||
4 | _
|
||
5 | _
|
||
|
||
The _'s represent potential, but OFF connections. #3 has been<65>
|
||
routed to #2 by merely filling in that table entry. This table is<69>
|
||
called the NodeMap.
|
||
|
||
(Fido's nodemap also contains a third column, where attributes<65>
|
||
like HOLD, SEND-TO, PICKUP and other things are stored. These<73>
|
||
attributes are built into the nodemap for programming convenience<63>
|
||
only, they are not really part of the router per se.)
|
||
|
||
HOW THE ROUTER WORKS
|
||
|
||
At FidoNet mail time, Fido prepares the router files before<72>
|
||
making packets and outgoing phone calls. The basic net host<73>
|
||
routing is performed, then any routing specified by the sysop in<69>
|
||
route language files.
|
||
|
||
Before any routing, the table looks like this:
|
||
|
||
ADDRESS ROUTE-TO ATTRIBUTES
|
||
1:1/1 1:1/1 (none)
|
||
1:1/2 1:1/2 ...
|
||
... ... ...
|
||
1:125/0 1:125/0
|
||
1:125/20 1:125/20
|
||
1:125/111 1:125/111
|
||
... ...
|
||
2:500/0 2:500/0
|
||
2:500/2 2:500/2
|
||
... ... ...
|
||
|
||
Basic default routing is applied, which does the FidoNet-as-we-
|
||
know-it net and zonegate routing (see the Appendix A: DEFAULT<4C>
|
||
ROUTING section):
|
||
|
||
ADDRESS ROUTE-TO ATTRIBUTES
|
||
1:1/1 1:1/1 ...
|
||
1:1/2 1:1/2
|
||
... ...
|
||
1:125/0 1:125/0
|
||
1:125/20 1:125/0
|
||
1:125/111 1:125/0
|
||
... ...
|
||
2:500/0 1:1/2
|
||
2:500/2 1:1/2
|
||
... ...
|
||
|
||
At this point Fido performs any additional routing you may have<76>
|
||
specified, such as overriding the routing, HOLD packets, enabling<6E>
|
||
only certain nodes or groups of nodes per schedule, etc. Things<67>
|
||
like HOLD, PICKUP, SEND-TO and other basic concepts are as<61>
|
||
attributes within the nodemap.
|
||
|
||
The nodemap is built on disk, and can be saved between schedules<65>
|
||
so that it an be used over and over; this is called a "QUICK"<22>
|
||
FidoNet event. It takes my Fido system mentioned above<76>
|
||
approximately 90 seconds to completely build the nodemap (about<75>
|
||
100 route language statements); subsequent "QUICK" events take a<>
|
||
fraction of a second.
|
||
|
||
PACKET CREATION
|
||
|
||
Fido creates packets when a FidoNet schedule starts (which is<69>
|
||
controlled by Fido's scheduler and is outside this discussion).<2E>
|
||
For every message in the netmail message area, Fido consults the<68>
|
||
nodemap, in two steps:
|
||
|
||
First, the actual destination (for example: 1:125/111) is looked<65>
|
||
up in the ADDRESS column of the nodemap. The ROUTE-TO column<6D>
|
||
determines where this message goes, ie. into which packet. If the<68>
|
||
destination node is not found, the message is marked (ORPHAN).
|
||
|
||
Secondly, Fido looks up the packet (ROUTE-TO) address (1:125/0)<29>
|
||
itself, in the ADDRESS column. This is done to locate the<68>
|
||
ATTRIBUTE bits for the destination node. If the bits indicate it<69>
|
||
is OK to packet this message (SEND-TO set, etc) then the packeter<65>
|
||
creates the packet.
|
||
|
||
This is done for all messages in the netmail area; once all the<68>
|
||
packets are built then FidoNet can dial out, allow incoming<6E>
|
||
pickups, etc.
|
||
|
||
Messages put into packets are not modified in any way; packets<74>
|
||
contain a copy of the original message. The post-FidoNet process<73>
|
||
takes care of messages that have been sent.
|
||
|
||
FIDONET SESSION COMPLETION
|
||
|
||
When a FidoNet schedule is over, Fido processes packets that were<72>
|
||
received from other mailers and cleans up any packets it had<61>
|
||
created earlier.
|
||
|
||
Packets that are un-sent are merely killed; the messages that<61>
|
||
these packet(s) were created from still exist in the netmail<69>
|
||
area; when a FidoNet session start again, Fido may put the<68>
|
||
messages into a packet to the same destination node or possibly<6C>
|
||
another; since packeting is done only before actual mailing the<68>
|
||
routing can be altered at any point up to actual successful<75>
|
||
transmission.
|
||
|
||
Packets that are sent, or picked up, are handled slightly<6C>
|
||
differently. The packets themselves are deleted, but Fido once<63>
|
||
again refers to the router to mark the messages that comprised<65>
|
||
the packet as (SENT), or kills them if they were indicated<65>
|
||
(KILL/SENT) by the originator.
|
||
|
||
Appendix A: DEFAULT ROUTING
|
||
|
||
Fido/FidoNet's routing is not "built-in" nor hard-coded; if it<69>
|
||
were not told otherwise, Fido would send messages to the<68>
|
||
destinations in the message itself. The routing needed to make a<>
|
||
practical mailer are added as layers upon this base; the tradeoff<66>
|
||
is speed vs. flexibility and accuracy. (Speed is, um, somewhat<61>
|
||
improved over older implementations...)
|
||
|
||
What the real-life Fido does at FidoNet mail time is make a pass<73>
|
||
through the table, and fill in the "default" routing that defines<65>
|
||
the FidoNet topology, which is our zone:net/node with routing to<74>
|
||
HOSTs for nets, which goes like this:
|
||
|
||
-For nodes in our own net, send direct (point to
|
||
point)
|
||
|
||
-For nodes in a net in our zone, outside our net,
|
||
send to it's host (net/0)
|
||
|
||
-For nodes in a region in our zone, sent direct
|
||
|
||
-For nodes in another zone, send to it's zone
|
||
host (zone:0/0)
|
||
|
||
The first three make sense in the network as we know it; the<68>
|
||
fourth requires some background.
|
||
|
||
FidoNet's topology is based upon a gimmick: the address of the<68>
|
||
logical host for any net or zone is composed of the number of the<68>
|
||
net or zone, with the magic zero added as the least significant<6E>
|
||
address field. A net or region host is net/0 or region/0; a zone<6E>
|
||
host is zone:0/0. FidoNet sysops use net/0 routinely; no one uses<65>
|
||
zone:0/0 routinely, if at all.
|
||
|
||
The difference is that the addressing scheme, the topology, is a<>
|
||
mathematical construct, and has nothing to do with the real<61>
|
||
world, ie. overseas phone calls, governmental regulations,<2C>
|
||
manufacturer incompatibilities, etc. The addressing scheme needs<64>
|
||
to be rigorous and provide a solid design base for all<6C>
|
||
implementations.
|
||
|
||
If we didn't have real-life complications like the above, never<65>
|
||
mind how overloaded the poor zone host computer would be, the<68>
|
||
mathematical model might fit the real world. Obviously it<69>
|
||
doesn't, and never did.
|
||
|
||
The solution in Fido's scheme is to merely modify the default<6C>
|
||
routing. There exists a keyword in Fido's routing language<67>
|
||
(called, not surprisingly, "ZoneGate") that does exactly what it<69>
|
||
sounds like: it routes all mail destined for another zone to any<6E>
|
||
arbitrary node designated "zone gate".
|
||
|
||
Zone Gates were thunk up at the now notorious "New Hampshire<72>
|
||
meeting" in '86 or so. The idea was to make it so that net/node<64>
|
||
mailers, ie. not zone-aware, could route messages destined for<6F>
|
||
other zones. The thing was called the "IFNA Kludge", and consists<74>
|
||
of two parts: (1) an addressing kludge to trick the mailer to<74>
|
||
route the interzone message to a node in it's own zone, and (2)<29>
|
||
to have the full zone:net/node origination and destination<6F>
|
||
addresses buried in the message body itself, hidden behind a line<6E>
|
||
that began with Control-A, so that message editors could learn to<74>
|
||
ignore it. (For your curiosity: full address consists of the very<72>
|
||
first line in the message, that looks like: "^AINTL z:n/f z:n/f",<2C>
|
||
where the first address is the destination node address, the<68>
|
||
second the originator.)
|
||
|
||
The addressing trick is: "Address the message for zone (N) to<74>
|
||
node 1/(N) in my zone". Node 1/(N) is designated the zone gate;<3B>
|
||
for example, the zonegate for Europe, Zone 2, node 1/2, in the<68>
|
||
North American zone 1. And so on.
|
||
|
||
Fido is a registered trademark of Tom Jennings
|
||
FidoNet is a registered trademark of Tom Jennings
|
||
(Sorry, I gotta say this!)
|
||
|
||
|
||
|
||
NEW SOFTWARE POLICY
|
||
|
||
This is the new (June 1989) software policy for the Fido/FidoNet<65>
|
||
package. Please read it carefully.
|
||
|
||
First, some important definitions:
|
||
|
||
Hobbyists run BBSs for their own personal reasons. Their BBS is<69>
|
||
not associated with their employer or any business. How they run<75>
|
||
their BBS is none of my business, ie. private, public,<2C>
|
||
subscription, collective or chattel slavery.
|
||
|
||
Commercial users are companies, corporations, proprietorships or<6F>
|
||
any other business entities that run a BBS, either publicly or<6F>
|
||
privately, associated with their business. "Non-profit" and "not<6F>
|
||
for profit" organizations are included in this category.
|
||
|
||
And here's the deal:
|
||
|
||
HOBBYISTS AND INDIVIDUALS: Fido/FidoNet is shareware; you can<61>
|
||
download the software itself, minus documentation, from the Fido<64>
|
||
Software BBS. There is no machine-readable documentation. (If you<6F>
|
||
thought the version 11 docs were unwieldy ... besides I pay<61>
|
||
royalties to the author). I will provide no direct support.<2E>
|
||
Hobbyists can receive the latest version on diskette plus printed<65>
|
||
and bound documentation for $50. If you later desire updates via<69>
|
||
diskette instead of download, updates (including printed errata<74>
|
||
sheet) cost $20 plus the original Fido Software diskette. $5<>
|
||
discount on either for US ca$h payment.
|
||
|
||
COMMERCIAL USERS: Fido/FidoNet is a usual licensable product; the<68>
|
||
license fee is $175, as it has been for two years. You will<6C>
|
||
receive the latest software version, complete documentation, and<6E>
|
||
support via the Fido Software BBS and voice telephone. (This has<61>
|
||
proved to be more than adequate for over two years.)
|
||
|
||
Deals, exceptions and special arrangements can be made on a case<73>
|
||
by case basis. In all cases, bugs are fixed promptly, as they<65>
|
||
have been for five years. This is basically the policy that was<61>
|
||
in force through 1987. It worked pretty well, there were very few<65>
|
||
problems, and most of those were caused by my ambiguity.
|
||
|
||
SHAREWARE DISTRIBUTORS: I do not wish Fido/FidoNet to be<62>
|
||
distributed by "shareware distributors", "libraries" or other<65>
|
||
similar organization. The problems are too numerous to count:<3A>
|
||
shipping ancient, incomplete versions; missing critical files;<3B>
|
||
giving out incorrect information regarding support; giving bad<61>
|
||
operating advice, etc. Never mind the fact that they are using<6E>
|
||
the software for profit, regardless of claims to the otherwise<73>
|
||
and suggesting that their customers pay instead.
|
||
|