599 lines
32 KiB
Plaintext
599 lines
32 KiB
Plaintext
|
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.
|