Simtel MSDOS - Coast to Coast

home *** CD-ROM | disk | FTP | other *** search

/ Simtel MSDOS - Coast to Coast / simteldosarchivecoasttocoast2.iso / fido / ftsc_all.z43 / FSC-0003.TXT next >

Wrap

Text File | 1986-03-22 | 33KB | 602 lines

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.