FSC-0003
FidoNet Route Files Explained
Part 1 -- The Many Faces of FidoNet
by Ben Baker, Fido 100/76
There is no aspect of FidoNet more universally mis-
understood than routing. It is the intent of this foru-
part series to clear some of the fog.
The justification for nets and routing has been
discussed many times and will NOT be discussed again here.
Given that routing is good, how is it done? What's the
meaning of the various statements that go into route files?
Indeed, what's the meaning of route files?
Let's first take a look at "the network." But how do we
do that? In reality, there is no "the network." FidoNet is
a different thing when viewed by each different Fido! The
only formal definition of FidoNet is the node list, and it
serves as an adaquate view of "the network" for most
independent Fidos but only the members of some nets.
Consider the hypothetical node, Fido 21/7. He's an
independent member of a "Region." To him, "the network" is a
couple of hundred other independent nodes to whom he sends
messages directly and another couple of hundred to which he
has access through 36 defined "Hosts." If he receives a
message not addressed to his node, his Fido "orphans" it.
He has no intention of forwarding someone else's mail. They
can pay their own phone bills! When he sends a message to
18/3, Fido knows (from the node list) that is another
independent and sends the message direct. When he sends a
message to 100/76, Fido knows (from the node list) that is a
member of net 100 and sends it to 100/0. Fido 21/7 executes
only schedule A during the national mail window. He has no
use for ANY route files.
Another hypothetical node, Fido 201/4 is a member of an
"inbound only" net. Since the sysop has used the '4'
command properly, Fido knows he is a member of net 201 and
will treat other members of that net as though they were
independent nodes. When he sends a message to 201/5, Fido
will send it direct and not to 201/0. Messages headed out-
side net 201 will be handled for 201/4 just as they were for
21/7. Fido 201/4 executes two schedules, A during the
national window followed immediatly by B when he just sits
quietly and waits for 201/0 to send him any mail he
received. He has no use for ANY route files.
Everyone else has a view of "the network" more
complicated than Fido can discover from just the node list.
If you're a Southern California Hub, or a local node in the
New York Megalopolis, or maybe the host of a modest network
in Memphis "the network" looks different to you than to
other sysops. It is the function of route files to modify
Fido's view of "the network" to conform to yours.
If your Fido is executing any mail event and any other
Fido calls it up and offers it a mail packet, your Fido will
graciously receive that packet and at the end of the mail
event, he will unpack it into messages. These actions have
nothing whatever to do with route files!
Reread that last paragraph two or three times until it
sinks in. It is a very important, very misunderstood point.
Route files do not and cannot control the way you receive
mail. ROUTE FILES CONTROL ONLY THE WAY YOU SEND MAIL!!!
After all, that's when you're paying the phone bill.
Furthermore, what you say in ROUTE.B has absolutely
nothing to do with how Fido behaves in schedule C. I will
come back to this point later.
Ever since we first began routing FidoNet messages to
places other than their final destination, route files have
used three basic commands to mold Fido's view of FidoNet to
correspond with your view. In part 2 we will look at
SCHEDULE, ROUTE-TO and ACCEPT-FROM and see just how they
influence Fido.
Part 3 will examine a bevy of new routing commands
available with Fido V11 and see how they have made automatic
distribution at last possible.
LISTGEN V2 is capable of generating route files auto-
matically. Part 4 will discuss how ROUTE.CTL statements map
to route file commands.
Stay with me for the next few weeks and maybe we can
burn off the fog and find a bright sky, a calm sea and clear
sailing. (And don't throw away your newsletters, you'll
want to refer back from time to time.)
------------------------------------------------------------
FidoNet Route Files Explained
Part 2 -- In the Beginning
by Ben Baker, Fido 100/76
From the time he first began "routing" messages, Fido
has used "route files" to tell him what messages to send
where when. Three basic route file commands do this;
SCHEDULE aka SEND-TO, ROUTE-TO and ACCEPT-FROM. This week,
we'll look at these commands in depth.
Before going farther, I need to define a couple of
terms. A "target" is a node to which your Fido will connect
and directly send a message. An "addressee" is the ultimate
destination node for a message. This is an important
distinction. Because of routing, the addressee and the
target for a particular message are often different nodes.
A "packet" is a collection of messages all to be sent
to a single target (though perhaps several addressees). At
the beginning of each schedule Fido builds all the packets
he will be permitted to send during that schedule.
Now, let's take a look at the three basic commands that
may appear in a route file, and see how each of them can
modify Fido's behavior.
SCHEDULE <tag> <target list> or
SEND-TO <target list>
These commands are equivalent. They tell Fido "During
this schedule, you may build packets for any target in
<target list>. Include all messages to different addressees
which may be routed to these targets. Do not consider any
outgoing messages which cannot be sent to one of these
targets." Unless there is an ACCEPT-FROM statement (see
below) only messages originating on your Fido qualify to go
into packets. If <target list> is empty (and this is NOT
schedule A), Fido will not build any packets. If he doesn't
build any packets he will not send any mail, even if he is
POLLed (see next week).
ROUTE-TO <target> <addressee list>
This command will override any node list implied
routing affecting these nodes. It tells Fido "If <target>
is in <target list> and there are outgoing messages for any
nodes in <addressee list>, put them in <target>'s packet."
If <target> is not in <target list> you blew it. It's
almost, but not quite a "no operation." No packets will be
built for nodes in <addressee list>, even if they are in
<target list>! Don't route messages to a <target> that's
not in the <target list> for this schedule.
By the way, a bug in an earlier version of Fido pre-
vented messages to <target> from being sent unless he was
also in <addressee list>. I don't know if that has been
corrected, but it's still good general practice to put
<target> in <addressee list>.
ACCEPT-FROM <originating list>
Normally, Fido only sends mail originating on your
board. If you receive a message originating on A and
addressed to B, without this statement, your Fido will not
attempt to send it along to B. Instead, he will mark it
"orphan" to give you an indication that he had a problem
with it and otherwise ignore it. This statement in a route
file tells Fido "When you build packets, if you find any
messages from any nodes in <originating list>, treat them as
if they originated here. In other words FORWARD any
messages from the nodes in <originating list> that you can
get into packets FOR THIS SCHEDULE's <target list>."
I actually suggested this verb for this action and have
regretted it ever since! It's a misnomer. A better verb
might be "FORWARD-FOR" but hindsight is always 20-20. It
really means "Accept, for forwarding, only messages from
these guys." It's designed to prevent you from paying
someone else's phone costs without prior arrangement.
So where do you put this statement? Remember two
important points I've mentioned before. 1) Route files
affect how you SEND mail, not how you receive it. 2) A
particular route file affects only the schedule with the
matching <tag>. Consider Fido 202/0, a hypothetical bi-
directional host. He executes three schedules each night.
During schedule B, before the national window, he collects
outgoing mail from his locals. During schedule C he sends
mail from himself and his locals to "the network" and
receives mail for himself and his locals from it. Then in
schedule D, after the national window, he distributes the
mail he received for his locals.
ROUTE.B needs neither a <target list> nor an ACCEPT-
FROM statement. Indeed, he doesn't really need any ROUTE.B
file at all because HE ISN'T SENDING ANY MAIL DURING
SCHEDULE B.
ROUTE.C has the national net excluding 202/0's locals
in its <target list>. It also has "ACCEPT-FROM 1, 2, 3,
(all locals)." Now let's say that 202/3 received a message
from 125/1 last night, but it wasn't delivered because 202/3
was down. The message is still here. Won't it be
"orphaned" because 125/1 isn't in the ACCEPT-FROM list? NO!
Because 202/3 isn't in the <target list>, the message won't
even be considered DURING THIS SCHEDULE.
ROUTE.D has all the nodes in net 202 in the <target
list>, and an "ACCEPT-FROM ALL" statement. Now the fore-
going message will be processed correctly and forwarded to
202/3.
Now let's say that 100/76 tries to forward a message to
Jakarta through 202/0. 202/0 cannot refuse delivery of the
offending message, so there it sits in his mail area.
During schedule B, he ignores all outgoing mail because he
doesn't have a <target list>. During schedule C Jakarta is
in his <target list>, but 100/76 is not in his <originating
list>, so the message is orphaned. During schedule D 100/76
IS in the <originating list>, but Jakarta is not in the
<target list> so the message is again ignored.
Make no mistake, if Jakarta had been in the <target
list> in schedule D, the message would have been sent, even
though it had been marked an orphan during schedule C
(provided, of course that a connection could be made and
Jakarta happened to be in a mail schedule at that time).
This means that if messages are orphaned because of errors
in your routing files, the routing files can be corrected
and the messages can still be sent. The orphan flag is NOT
a dead end!
A similar kind of bug existed (and may still; I don't
know) with ACCEPT-FROM as with ROUTE-TO (above). If a route
file contains an ACCEPT-FROM statement, make sure your own
node is in the <originating list>. (The first time I used
this statement, I forwarded a lot of messages, but
"orphaned" my own messages!)
Well, that's how routing is achieved. Remember, all
these statements control out-going mail. You can receive
mail even if you don't have any route files!
A final point on routing. If a message says it has a
file attached (even if the file doesn't exist) all bets are
off. Routing is suspended and the message will be sent
direct from the originator to the addressee. Fido has
several built-in safeguards to prevent you from forwarding
someone else's files, or forwarding your files through
someone else for that matter.
Next week we'll take a close look at the goodies TJ has
provided in version 11 and see how they are making automatic
node list distribution at long last a reality.
------------------------------------------------------------
FidoNet Route Files Explained
Part 3 -- Keep the Old, Ring In the New
by Ben Baker, Fido 100/76
Last week we looked at the basic routing statements
that have been with us since version 7 or so. Now let's
look at what's been added in version 11.
Please refer back to last weeks definitions. I con-
tinue to use them as defined.
RECV-ONLY
This tells Fido "Go ahead and build packets for any
targets in the SCHEDULE command's <target list>, but DON'T
ATTEMPT TO CALL ANYBODY. If any targets happen to call in
for any reason, try to give them their packets before they
get away."
There MUST be a <target list> for this statement to
mean anything. It is not intended for normally "receive
only" schedules like 202/0's collection schedule (see last
week). Instead, it prevents you from originating calls
during schedules when you are trying to SEND mail. (Route
files control how you send mail, not how you receive it.)
You are really trying to send mail on the other guy's
nickel, but as you will see, he has to cooperate in that
venture.
This statement might be used by the locals during the
collection schedule in a large, busy net. Collisions are
avoided because there's only one node, the outbound host,
placing calls. He POLLs (see below) the locals for their
outgoing traffic.
HOLD <hold target list>
"OK, Fido, build packets for targets in the <target
list>, but don't attempt to actually call any targets in
<hold target list>." This is a limited "RECV-ONLY" command.
Any packets for targets not in <hold target list> will be
sent normally (if they haven't been picked up), but packets
for <hold target list> have to be "picked up."
There's a hidden gimmick here that bears further
exploration. Ken Kaplan (Fido 100/22 AKA 1/0) is the
original source in the national nodelist distribution
system. Regional coordinators call his Fido each week to
pick up copies of the latest nodelist. The route file for
his national window contains the statement "HOLD <regional
coordinator list>." Fido will not attempt to send any
packets targetted for a regional coordinator. Does this
mean that he can't send "normal" messages to the
coordinators? Not at all. Because he is a member of net
100, all his "normal" messages, including those addressed to
the coordinators, wind up in a packet targetted for 100/10,
the outbound host. Since 100/10 is not in the <hold target
list>, that packet is sent and the messages go out. HOLD
APPLIES TO THE TARGETS OF PACKETS, NOT TO THE ADDRESSEES OF
MESSAGES! It is only when Ken sends messages to the
coordinators with the nodelist (or other files) attached to
them that Fido builds packets targetted for them instead of
100/10.
Does that mean that Ken can't send the coordinators
other files without waiting for them to pick them up? Well,
yes and no. Because of the HOLD statement, he can't say
send FIDO_IBM.EXE to 14/61 (see PICK-UP below for why 14/61
and not 14/0). But he can use another gimmick. The
coordinators have dual identities (set by the '4' command of
Fido) and he can certainly send a file to 14/0. Fido is
smart, but so smart he'll notice that 14/0 and 14/61 happen
to have the same phone number. He'll send the packet for
14/0 and hold the one for 14/61. By the same token, if both
packets are still present when 14/61 calls in, he'll only
pick up the the nodelist targetted for 14/61 and not the new
Fido targetted for 14/0. (You can't have your cake and eat
it too.)
PICKUP <pickup target list>
Whenever any other Fido calls your Fido for any reason,
your Fido looks to see if there is a packet targetted for
him. If there is, your Fido will try to deliver it then and
there and avoid making the phone call which you have to pay
for. Without this statement (or the next one) in his route
file, the other Fido will simply hang up on you, leaving you
with a phone call to make in order to deliver your packet.
This statement says to Fido "If you happen to call any
target in <pickup target list>, hang around to see if he has
mail for me."
This is a two-edged sword. It can speed up mail
exchange, but the Fido that places the call pays for it. It
works best within a local net where the calls are all toll
free anyway. In fact, it won't work at all between larger
nets supported by distinct inbound and outbound hosts.
Specifying "PICKUP 100/0" in your national window schedule
would only get you messages originating on 100/0 (or 100/51
actually) with files attached. Any other mail for you might
be in a packet addressed to you, but on 100/10, the outbound
host, and that's not who you called.
Even worse, let's say Tom Jennings is sending a file to
100/10 and wants to pick up any mail from St. Louis for San
Francisco while he's at it. He's the host of net 125, and
that's perfectly legitimate, right? Wrong! His primary
identity (the '4' command again) is 125/1 and 100/10 may
have a packet for 125/0, but he won't have a packet for
125/1. This command deals at the packet/target level just
as the HOLD command does. Furthermore, it deals with real
identities, not alternate identities.
As I said, this is most useful within a local net, and
that's where it probably should be applied.
POLL <poll target list>
This tells Fido "Even if I don't have any mail for the
targets in <poll target list> generate empty packets
addressed to them so you have an excuse to call them. Then
when you do call them, pick anything they have for me."
"POLL <poll target list>" implies "PICKUP <poll target
list>" which need not be specified. This is the statement
an outbound host might use to poll his locals or hubs for
outgoing traffic prior to national mail time. Together with
the next statement, this method can be very efficient.
The regional coordinators run a special schedule each
Saturday morning during the national mail window. It's
route file is identical to their normal national schedule
route file except that it contains the statement "POLL 1/0."
That's how they get the nodelist for subsequent redis-
tribution.
As I see it, POLL has a lot more uses than PICKUP.
SEND-ONLY
This one is mainly for outbound hosts. It says "I'm
not expecting any mail during this schedule, so don't wait
the normal one or two minutes for incomming calls after
making an outgoing call. As soon as you finish one, dial
another until all packets have been sent."
As I said above, this can be very efficient, but
there's a problem you need to be aware of. Fido will make a
maximum of 30 attempts without connect to send a packet to a
particular target. If you have only one packet addressed to
a busy target, Fido would normally take about an hour to use
up 30 attempts, but in SEND-ONLY mode he can attempt 30
calls in about 20 minutes! If you have a Courier and are
running it in "X4" response code mode, he'll make 30
attempts in 10 to 15 minutes. (The Courier doesn't waste a
lot of time in "fast-dial, busy-detect" mode.)
If you're an outbound host and want to try SEND-ONLY
during the national window, you risk using up your call
attempts while your target is busiest, then when he's
quieted down and you could get through, you've given up! I
suggest you break your national time into two schedules, and
only use SEND-ONLY during the last 20 minutes or so of the
national window.
On the other hand, polling your locals or hubs is a
different matter. They should be in RECV-ONLY mode and you
can expect every call to connect the first try. The call
attempt limit doesn't apply to this situation and the SEND-
ONLY command should be used to shorten the time needed to
POLL everyone.
NO-ROUTE <addressee list>
This command tells Fido "Do not send messages addressed
to these nodes anywhere but to the addressed nodes. Treat
them as though they have files attached, whether they do or
not."
This lets you say things like Fido 100/76 (in Illinois)
might:
SEND-TO 100/10 ; Outbound Host (in Missouri)
ROUTE-TO 100/10 ALL ; Send everything to accross the river
NO-ROUTE 100/482 ; Except other Illinois traffic
The only other way to achieve this end is to list in
the ROUTE-TO command all 500 odd nodes whose messages should
be routed to 100/10, and that list changes every week!
Now you should have a good handle on how the commands
used in ROUTE.<tag> control how Fido SENDS files during
schedule <tag>. But sometimes these commands require very
long lists of node numbers which change from week to week as
the node list changes. LISTGEN 2 will generate the route
files automatically and let you specify the long lists
symbolically in terms of nets, area codes, etc.. Next week
in the last part of this series, we'll see how the
statements in LISTGEN's ROUTE.CTL file correspond to the
commands in ROUTE.<tag>.
------------------------------------------------------------
FidoNet Route Files Explained
Part 4 -- LISTGEN and ROUTE.CTL
by Ben Baker, Fido 100/76
LISTGEN Version 2 will automatically generate route
files for you if you desire. The advantage is that LISTGEN
is driven by a control file, ROUTE.CTL, in which you specify
the statements necessary with symbolic parameters that you
define in terms of nets, area codes, etc.. A properly
designed ROUTE.CTL need only change when your routing needs
change. LISTGEN will continue to create correct route files
week after week as the nodelist changes.
Before I begin, I'd like to do a quick review of the
route file commands and their effect.
SCHEDULE <tag> <list> or
SEND-TO <list> Determines which nodes may have
packets build to SEND mail to.
ROUTE-TO <target> <list> Directs that messages to par-
ticular addressees be SENT in
packets to another node.
ACCEPT-FROM <list> Specifies which oritinators'
messages may be SENT.
RECV-ONLY States that packets may only be
SENT by being picked up.
HOLD <list> States that packets to part-
icular nodes may only be SENT
by being picked up.
PICK-UP <list> States that it is OK to receive
mail from particular nodes when
we originate calls to SEND them
packets.
POLL <list> Directs that packets (empty if
necessary) be generated and
SENT to particular nodes in
order to pick up mail.
SEND-ONLY States that calls may be made
rapid-fire to SEND as many
packets as possible.
Note that each definition above includes the verb SEND
or SENT. I did that deliberately to emphasize that these
commands all control some aspect of sending mail.
LISTGEN has been adaquately documented and I do not
intend to re-document it here, but I would like to show you
how ROUTE.CTL commands map to the ROUTE.<tag> commands
covered above.
SCHEDULE <tag> <target list>
When LISTGEN encounters this command in ROUTE.CTL it
does two things. First it closes any route file it may be
working on and creates a new ROUTE.<tag> file for the new
<tag>. Then it generates a SCHEDULE statement from the
specifications in this one for the new ROUTE.<tag>,
expanding any symbolic parameters to lists of nodes from the
nodelist. In other words, it begins a new route file as you
would expect it to by defining the <target list>.
FROM <accept list>
This phrase, when encountered, generates an ACCEPT-FROM
statement.
TO <addressee list> [ VIA <target> ]
If the VIA clause is present, this statement generates
a "ROUTE-TO <target> <addressee list>." Successive TO
phrases without VIA clauses accumulate to make a larger
<addressee list> until a VIA clause IS found. Then the
entire list is routed to the <target>. (I'm not entirely
happy with this "feature," but that's the way it works.) If
no VIA clause is ever found, the TO phrase generates no
output at all! It does serve as documentation in your
ROUTE.CTL file, saying "I expect to be sending mail TO these
nodes in this schedule."
All of the other route file commands discussed above
map one-for-one in the same format from ROUTE.CTL to
ROUTE.<tag>.
The big advantage in using LISTGEN is to be able to use
simple symbols which it will translate into long lists of
nodes. To illustrate, net 100 spans two area codes, 314 in
Missouri and 618 in Illinois. To minimize the number of
toll calls placed accross the Mississippi, I serve as "Metro
East" hub to concentrate the Illinois traffic. I have the
following statements (among others) in my ROUTE.CTL file:
define Metro-East as Net-100 except Area-314 ; Area 618
define Outbound as 100/10
define World as all except Metro-East
* * *
FROM Metro-East TO World VIA Outbound
Nodes may come and go, both in our net and across the
country, and these statements need not change. LISTGEN
interprets them week after week and builds the right route
files every time. And in several months, if our outbound
host should change making it necessary to change ROUTE.CTL,
I can look at this and not have to say to myself "What on
earth was I trying to do here?" It's all pretty obvious.
Before I wrap it up, there are two important exceptions
to the things I have said. First, schedule A is special in
that the <target list> always is the entire nodelist, no
matter what ROUTE.A says. For that reason, if you do any
routing not defined by the node list, I recommend that you
DO NOT USE SCHEDULE A. For all other schedules, Fido does
exactly what ROUTE.<tag> tells it to do and nothing more.
And second, ROUTE.BBS is a special route file that affects
all schedules for which there are no ROUTE.<tag> files. For
that reason, I recommend that you FORGET YOU EVER HEARD OF
ROUTE.BBS. It'll cause more problems than it'll ever solve!
So, routing can get pretty complex (just ask 'em in
Southern California), but it doesn't need to be complicated
once you know what the objective of each schedule is from
your point of view, and what your Fido needs to do to meet
those objectives.
In fact, it's pretty easy if you just remember the two
points I have been hammering at you since we began:
1) Route files control the way you send messages, not
the way you receive them. Every command we discussed above
controls some aspect of sending messages. And. . .
2) A particular route file only affects the schedule
with the matching <tag>. What you say in ROUTE.B has no
bearing whatever on schedule C. Each schedule must be
separately spelled out.
