synchro.net

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

/ synchro.net / synchro.net.tar / synchro.net / modem.madness / SMMNETML / RDMAP116.ZIP / ROADMAP.DOC < prev next >

Wrap

Text File | 1992-10-27 | 22.8 KB | 480 lines

***************************** Roadmap V1.10 ***************************** ************************************************************************* Purpose: Roadmap will automatically create Squish/Qmail/FD compliant ROUTE.CFG files for your entire NETWORK. NOTE: Roadmap is a very complicated program, and requires that anyone in your NET using the program coordinate information with one another. Failure to do so will result in ROADMAP creating incorrect route.cfg files that, at best, may not create complete ROUTE.CFG files for every node. At worst, ROADMAP will create ROUTE.CFG files that "ping-pong" mail between systems. ************************************************************************* ************************ Files Used and created ************************* Roadmap requires 3 input files that it gets information from. They are: Nodelist Roadmap reads any St. Loius style nodelist directly. All you do is tell roadmap where your "nodelist" directory is, and roadmap will automatically select the latest nodelist to use. Roadmap.cfg Roadmap has a configuration file. In this file is all the "custom" information for your particular system. These include your nodelist path, zone:net/node #, who will accept your LPM mail, and a "template" ROUTE.CFG file that roadmap "modifies" every time it runs. Roadmap.exc Roadmap.exc is the file that has details on your net's phone exchange information. Using this information, roadmap creates 2 output files; ROADMAP.TMP This is the "solved" NET routing file... This is the file the "insert_map" verb writes in your route.cfg file. I left it here just in case you have another use for this file. If not, it simply could be deleted in a batch file every time the program is run. ROUTE.CFG This is the actual output file of ROADMAP. This file is the actual ROUTE.CFG file that can be used by your mailer. For FD users, you will have to rename this to ROUTE.FD before you can use it. Again, a perfect job for a batch file (Or .CMD file for us OS/2 users) ************************************************************************ ************************** Operation Overview ************************** Roadmap first opens it's configuration file. From here, it finds out where it can find a nodelist, it's zone:net/node#, node numbers that it shouldn't "solve" for (exclude from the output), the areacode it is in (as seen in the nodelist). Roadmap then reads "operating" variables into it. It finds out who it can send LPM to, and what phone exchanges within your net have at least one node participating in LPM distribution. From there, it reads how you want to treat your "output". I.E. what verbs you want to use for the SEND's and ROUTE's it creates. Lastly, the end of the configuration file holds the "template" of your configuration file. This template holds all the "outside" net routing, since roadmap will only solve your own net's routing. This also holds any "specially treated" nodes within your net. For Example, lets say a node within your net polls you for echomail. If you allow roadmap to "route" this node, your tosser will route echomail along that route. Usually, routed echomail is looked down upon in fidonet, and it is not advised without prior consent of all involved. Routed echomail is something much different than routed netmail. Routed Netmail is usually low in volume, routed echomail can be megabytes a day!. Also, if you have any tosser schedules, you MUST include them in your template. Again, ALL ROADMAP DOES is CREATE a ROUTING FILE FOR YOUR NET!! Anything else has to still be done manually!!, and those manual entries must be put in your TEMPLATE. After ROADMAP has read it's configuration file, it then reads the phone exchanges file. Here it groups the exchanges into calling groups, and finds out what other calling groups the group can call.. For Example: Group Wallingford Exchanges 265,269,284,294,949 Calling Meriden,Cheshire,New_Haven End Wallingford The above is an entry in a typical ROADMAP.EXC file for Wallingford, CT. Roadmap reads this information, and from it does the following: It creates a calling group called WALLINGFORD. It then is told information about group Wallingford. This information is in the form of what phone exchanges make up the group, and what other groups WALLINGFORD can call. In this case, it knows that if the prefix of a phone # in your areacode begins with 265,269,284,294, or 949, it belongs to group WALLINGFORD, and that phone exchange can then call itself, and also the calling groups MERIDEN, CHESHIRE and NEW_HAVEN.. Next, roadmap looks in your NODELIST directory, finds the latest NODELIST by date (this way it doesn't get confused in the beginning of JANUARY), and then opens the nodelist. Roadmap scans the nodleist until it finds your Zone:net. It then, one by one, reads in every node in your net. It stores the node number, and then looks at the phone prefix for the phone number of the node. If there is no phone number (in the case of PVT nodes), it reports that the node is not within your areacode, or is PVT! and continues with the next node, disregaurding the "offending" node.. If it does find a phone number, it "checks" the prefix, and finds which calling group it belongs to. ROADMAP does NOT use the "location" found in the nodelist, it uses the phone number to find the "group" it is in as you specified in ROADMAP.EXC. If it cannot locate a dialing prefix match from the ROADMAP.EXC file, it warns you, and then throws that node away. After all the nodes in the net are processed, it closes the nodelist, and proceeds to "solve" the routing of your NET. From here, roadmap looks, node by node, on how to create a NO-COST link to that node from your node. It goes by groups. Roadmap's logic can be confusing at first, and unfortunatly explaining things is NOT one of my strong points, but here goes: Roadmap, while reading in the nodelist, searched for you. Let's say you are 1:141/865 (me). It finds out that your dialing prefix is 949, which is part of group WALLINGFORD, thus you are in group WALLINGFORD. It now takes a node, and attemps to find a free link between you and the node in question. If you are local to the node, the node is placed at the beginning of the "solved" route file, with a SEND ???? in front of it. The ???? is replaced with the verb you specified in the SEND_VERB keyword of the configuration file. If the node is NOT local to you, it will attempt to find the shortest free route to that node. If it finds a route, it will place the node in the output "solved" file, with a SEND ???? Z:N/ROUTER in front of it, and any other nodes to be routed the same way. The ???? is replaced with the verb you specified in the ROUTE_VERB keyword in the configuration file. The ROUTER will be replaced with the node number of the router it chose as the best person to send this node's mail to. If ROADMAP is unable to find a toll-free link, it will place the node at the end of the "solved" route file, and will place a SEND ???? in front of it, and any other nodes that cannot be routed free. The ???? is replaced with the verb you specified in the NOTLOCAL_VERB keyword in the configuration file. PLEASE NOTE: A TOLL FREE LINK means that NO NODE using roadmap will incur any expense in delivering the mail within the NET. ROADMAP IS DESIGNED NEVER TO MAKE ANY NODE MAKE AN LD CALL TO DELIVER NETMAIL WITHIN THE NET. IF ROADMAP CANNOT FIND A FREE LINK, IT DEAD-ENDS THAT NODE ON YOUR SYSTEM. You can either choose to send the mail yourself, incurring the charges yourself, or putting that node's mail on HOLD.. For this reason, it is suggested the the ROUTE_TO nodes you choose also be using ROADMAP. This way, No-one will force any other node to make LD call's on it's behalf. When roadmap cannot find a link in only a few steps (I.E. it's not local to you, or your routers), roadmap creates a "tree", starting with your routers, and builds search branches of that tree, one branch for every group that can be called (local to) by a group above it.. Example: Wallingford (Base of Tree, Level 1) |------------------|-------------------| |--------------Meriden |-----Cheshire |------New_Haven (Level 2) Southington Waterbury Branford Milford Guilford (Level 3) etc..etc..etc.. Roadmap keeps growing the search tree until it finds the group it's looking for (The group the node we are looking for is found). Once it finds this group, roadmap "looks up" to find which branch (level 2) spawned it. Level 2 is really all your routers, and by "looking up", it knows which router to route this node to. PLEASE NOTE: In this scenario, roadmap uses the CAN_ROUTE groups to determine if a group can be used in the search tree. For example, if, when ROADMAP starts searching group MERIDEN sees that MERIDEN can call group SOUTHINGTON, it marks SOUTHINGTON as a possible search "branch" on it's next pass (Next lower level). When roadmap gets to that level (Level 4 will expand Southington's calling area in the example above), roadmap first checks to see if a node exists in Southington that can accept routed mail. It gets this from the CAN_ROUTE entries in the roadmap.cfg file. If group SOUTHINGTON does not appear, roadmap ignores Southington, saying that even if I can get to my target group via Southington, it won't matter because no-one in Southington can accept my mail. Now, let's examine this case: Wallingford | Cheshire | Waterbury | Woodbury | Newtown | Danbury This is the shortest distance from Wallingford to Danbury. If all those towns above are in my CAN_ROUTE list, that's the route ROADMAP will choose when it trys to find a route to Danbury. If, however, I take a town out of the list, ROADMAP will attempt to find another route to DANBURY. For example, lets say I take Cheshire out: Wallingford | Meriden | Southington | Waterbury | Woodbury | Newtown | Danbury This is what happens, assuming all the above towns ARE in my CAN_ROUTE list. It said I cannot use Cheshire, but found out that Meriden can call Southington, which can call Waterbury, and chose that route. If it could not find a new route, it would mark that node as un-routable, and place it in the SEND LD line. Now, for the reason why ROADMAP's CAN_ROUTE list HAS to be coordinated within a NET... Lets, for sake of argument, say the following towns are interconnected like this: Wallingford---------------------- | | Cheshire New Haven | | Waterbury Milford | | Woodbury-------------| Bridgeport | Seymour | Newtown |----------- | Danbury As you can see, both Bridgeport and Woodbury can call Seymour. Now, lets say that ROADMAP attempts to solve the Cheshire nodes path to Danbury. WATERBURY, WOODBURY, and NEWTOWN are all in the node's CAN_ROUTE list, so ROADMAP determines the shortest distance to Danbury is .via. those 3 hops. Now, ROADMAP on the system in Milford attempts to SOLVE for Danbury. It has BRIDGEPORT, SEYMOUR, WOODBURY, and NEWTOWN in it's list, and so, ROADMAP realizes that the shortest way to Danbury is going through Seymour. A total of 4 hops. Now, the guy in BRIDGEPORT doesn't have SEYMOUR in his CAN_ROUTE list, so when ROADMAP solves for Danbury on his system, it says, hey, Seymour would be the shortest, but I can't go that way, so I have to go all the way around. MILFORD, NEW_HAVEN,WALLINGFORD, CHESHIRE,WATERBURY,WOODBURY and NEWTOWN are in his CAN_ROUTE list, and so roadmap determines the "best available" way to route to Danbury is through Milford... We have a "ping-Pong" problem here... Milford will attempt to route Netmail destined to Danbury through Bridgeport. Bridgeport, on the other hand, will route it through Milford... So, the nodes will end up sending this poor little innocent netmail message back and forth between the node in Milford and the node in Bridgeport... This is why IT IS VERY IMPORTANT that EVERYONE's CAN_ROUTE lists be the same in a NET!!!!!!! *********************************************************************** ******************** ROADMAP.CFG file Keywords ************************ *********************************************************************** Here is the list of keywords that can be included in the .CFG file, and their explanation. All keywords must be seperated from their arguments by at least one space, although any number of spaces can be used for viewability. Keywords ARE NOT CASE SENSITIVE. NODELIST Place the Path to where you store your NODELIST directoy. MY_ZONE Your fidonet Zone number. NY_NET Your Fidonet NET number. NY_NODE Your Fidonet NODE number. EXCLUDE List the nodes that you DO NOT want in the output. These are usually numbers if you have alias numbers, such as an administrative number. But, any number can be excluded. You can have a Maximum of 20 numbers here, and you can have them spread out over more than one EXCLUDE keyword. AREACODE Your Areacode, as seen in the nodelist. ROUTE_TO The nodes that have agreed to accept your routed mail. It is suggested that these nodes also run ROADMAP. You can have a Maximum of 10 Nodes that you can send your ROUTED mail to, and they can be spread out over more than one ROUTE_TO keyword. CAN_ROUTE This is a list of the calling groups that have a node in them that is willing to route mail. A Maximum of 50 CAN_ROUTE Groups can be given, and you can spread them out over more than one CAN_ROUTE keyword, as shown in the sample .CFG file. SEND_VERB This is the "modifier" that ROADMAP will place after any node that you can call locally, in the ROUTE.CFG file. This is the verb (Crash, Normal, Direct, Hold) that your mailer will use when determining the priority of the mail to these nodes. ROUTE_VERB This is the "modifier" ROADMAP will place after the ROUTE verb in the ROUTE.CFG file. This is the verb (Crash, Normal, Direct, Hold) that your mailer will use when determining the priority to send this mail to the node (Your Routers, the nodes in you ROUTE_TO list). NOTLOCAL_VERB This it the "modifier" that roadmap will pace in your ROUTE.CFG file after and nodes that cannot be reached via a toll free link. Placing HOLD here will cause your mailer NEVER to call these nodes, thus NOT making any LD calls within your net. You could choose to place any other "modifier" here, so as to deliever the mail yourself, if your system gets any mail for these nodes. NOTLOCAL_ROUTE This keyword is optional. If this keyword is not used, ROADMAP will create a "SEND (NOTLOCAL_VERB) nodes.... for all nodes that cannot be routed within the net toll free. If this keyword is used, ROADMAP will route all the nodes that cannot be routed for free to this node. THIS CAN BE DANGEROUS, AS IT ALLOWS ROADMAP TO SEND MAIL TO ANOTHER SYSTEM THAT MAY ULTIMATLY MAKE THAT SYSTEM CALL LONG DISTANCE!!! USE THIS KEYWORD WITH CAUTION, AND CHECK WITH THE NODE YOU PLAN TO ROUTE THESE 'UNROUTABLE' NODES TO BEFORE YOU DO THIS. BEGIN_CFG This marks the Beginning of you ROUTE.CFG template. Roadmap needs a TEMPLATE ROUTE.CFG file, that it will place it's "answers" into. This is because ROADMAP cannot solve out of net LPM, and other special routing that you and others may have already established. The best thing to do is take the sample ROADMAP.CFG file that came with the package, and delete EVERYTHING after BEGIN_CFG. Then, append a copy of your PRESENT ROUTE.CFG to the ROADMAP.CFG file, after the BEGIN.CFG keyword. INSERT_MAP This is used inside the ROUTE.CFG TEMPLATE. Wherever you place this verb, ROADMAP will replace this verb with the routing it determined for your NET. This verb can be used as many times as you want within the template. (Just in case you have more than one event that requires NET routing). END_CFG This signifies the End of your ROUTE.CFG template file, and usually the end of your ROADMAP.CFG file as well. ********************************************************************** ********************** ROADMAP.EXC File Format *********************** ********************************************************************** The ROADMAP.EXC file holds all the phonde dialing info for your particular area. This information may not be easy to find; it took me almost a week of searching various phone books (The front usually has a map of the calling area it covers with dialing exchanges and calling coverages). First, you must pick a group name for every DIFFERENT calling group in your area. The group name you pick is arbitrary, so long as it has no spaces in it, and is not longer than 20 characters. I attempted to represent the towns (logical, huh?) that they encompass. Usually, the phone company has already named these groups. For Example, in the front cover of the NEW_HAVEN, CT phone book, the phone company has a little map showing all the dialing prefixes in NEW_HAVEN, and then little arrows to surrounding towns that NEW_HAVEN can dial. That's what you want. Physically, NEW_HAVEN, CT includes other towns, like North Haven, and Hamden. But, ALL their phonde numbers have the same dialing "range", so you include them in one group! You organize a group like this in the ROADMAP.EXC file: Group NEW_HAVEN Exchanges xxx,yyy,zzz,aaa,bbb Exchanges xxy,yyx,zza,aab,bbz Calling WALLINGFORD,MILFORD Calling CHESHIRE,BRANFORD End NEW_HAVEN Please note that you can have any number of EXCHANGES and CALLING keywords within a group. You can have 75 Exchanges (dialing Prefixes) and 20 Calling groups. You can have a Maximum of 75 Groups. When creating the calling groups, if you say that a group can call another group, you MUST define that other group somewhere in your ROADMAP.EXC file. For example, I mentioned WALLINGFORD, MILFORD, CHESHIRE and BRANFDORD above. This means that I MUST define those groups in my ROADMAP.CFG also. Also, when I do define those groups, I put NEW_HAVEN in as a group it can call. Hint: Net 141's boundry is Southington. Southington can call BRISTOL, but BRISTOL is not part of NET 141. It is our neighboring net, NET 142. Which means when I solve for net 141, I will NEVER have a BRISTOL node to deal with. So, even though SOUTHINGTON can dial BRISTOL, I didn't put BRISTOL in SOUTINGTON's calling info. This way, I don't have to define BRISTOL in ROADMAP.EXC. It's pretty self explanatory, take a peek at the sample ROADMAP.EXC file if you still have any questions. If you still have any questions, comments, suggestions, or that "b" word (Bug reports), feel free to Netmail me at 1:141/865, or log into the BBS at (203) 949-0375. While I'm here, I'd like to thank some people that helped me with beta-testing this program, putting up with my numerous phone calls, and netmail messages attempting to check ROADMAP, and all of NET 141 in general for being so receptive and helpful. Brian Bonfietti (141/1130) , Dave Drouin (141/805) , Bob Morris (141/333) Furlan Primus (141/1100) , Tom Ruddy (141/755) , Don Dawson (141/730) Joel Lambert (141/455) , Terry Wodek (141/375) , Jim Ryan (141/9) Mark Terrace (141/340) , Phil Palumbo (141/336) , Don Bates (141/814) Steve Sekula (141/110) , Chris Regan (141/565) , Brian Dodds (141/1170) And last but not least, Registration: I wrote this to help out Fidonet, I don't want money for it. Maybe a note letting me know you use it would be nice, but not nessesary. I do ask you to do one little thing though. If you use it, go out, and buy a kid an ice cream cone. Spend some time with a kid. You'll both enjoy the time you spend together! Andre Normandin NETWORK SOLUTIONS Fidonet: 1:141/865 BBS: (203) 949-0375