home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-387-Vol-3of3.iso / r / rdmap116.zip / ROADMAP.DOC < prev    next >
Text File  |  1992-10-27  |  23KB  |  480 lines

  1. ***************************** Roadmap V1.10 *****************************
  2. *************************************************************************
  3.  
  4.  
  5. Purpose:        Roadmap will automatically create Squish/Qmail/FD
  6.                 compliant ROUTE.CFG files for your entire NETWORK.
  7.                 
  8. NOTE:           Roadmap is a very complicated program, and requires
  9.                 that anyone in your NET using the program coordinate
  10.                 information with one another. Failure to do so will
  11.                 result in ROADMAP creating incorrect route.cfg files
  12.                 that, at best,  may not create complete ROUTE.CFG
  13.                 files for every node. At worst, ROADMAP will create
  14.                 ROUTE.CFG files that "ping-pong" mail between systems.
  15.  
  16. *************************************************************************                
  17. ************************ Files Used and created *************************
  18.  
  19.  
  20. Roadmap requires 3 input files that it gets information from.
  21. They are:
  22.  
  23.                
  24. Nodelist        Roadmap reads any St. Loius style nodelist directly. 
  25.                 All you do is tell roadmap where your "nodelist"
  26.                 directory is, and roadmap will automatically select
  27.                 the latest nodelist to use.
  28.                 
  29. Roadmap.cfg     Roadmap has a configuration file. In this file is
  30.                 all the "custom" information for your particular
  31.                 system. These include your nodelist path,
  32.                 zone:net/node #, who will accept your LPM mail, 
  33.                 and a "template" ROUTE.CFG file that roadmap "modifies"
  34.                 every time it runs. 
  35.                
  36. Roadmap.exc     Roadmap.exc is the file that has details on your
  37.                 net's phone exchange information.
  38.                 
  39.  
  40. Using this information, roadmap creates 2 output files;
  41.  
  42. ROADMAP.TMP     This is the "solved" NET routing file... This is
  43.                 the file the "insert_map" verb writes in your 
  44.                 route.cfg file. I left it here just in case you
  45.                 have another use for this file. If not, it
  46.                 simply could be deleted in a batch file every 
  47.                 time the program is run.
  48.                 
  49. ROUTE.CFG       This is the actual output file of ROADMAP. This
  50.                 file is the actual ROUTE.CFG file that can be used 
  51.                 by your mailer. For FD users, you will have to rename
  52.                 this to ROUTE.FD before you can use it. Again, a 
  53.                 perfect job for a batch file (Or .CMD file for us
  54.                 OS/2 users)                           
  55.  
  56.  
  57. ************************************************************************
  58. ************************** Operation Overview **************************
  59.  
  60. Roadmap first opens it's configuration file. From here, it finds out
  61. where it can find a nodelist, it's zone:net/node#, node numbers
  62. that it shouldn't "solve" for (exclude from the output), the areacode
  63. it is in (as seen in the nodelist).
  64.  
  65. Roadmap then reads "operating" variables into it. It finds out who it
  66. can send LPM to, and what phone exchanges within your net have at least 
  67. one node participating in LPM distribution.
  68.  
  69. From there, it reads how you want to treat your "output". I.E. what
  70. verbs you want to use for the SEND's and ROUTE's it creates.
  71.  
  72. Lastly, the end of the configuration file holds the "template" of your
  73. configuration file. This template holds all the "outside" net routing,
  74. since roadmap will only solve your own net's routing. This also holds
  75. any "specially treated" nodes within your net. For Example, lets say a
  76. node within your net polls you for echomail. If you allow roadmap to
  77. "route" this node, your tosser will route echomail along that route.
  78. Usually, routed echomail is looked down upon in fidonet, and it is 
  79. not advised without prior consent of all involved. Routed echomail 
  80. is something much different than routed netmail. Routed Netmail 
  81. is usually low in  volume, routed echomail can be megabytes a day!.
  82. Also, if you have any tosser schedules, you MUST include them in your
  83. template. Again, ALL ROADMAP DOES is CREATE a ROUTING FILE FOR YOUR NET!!
  84. Anything else has to still be done manually!!, and those manual entries
  85. must be put in your TEMPLATE.
  86.  
  87.  
  88. After ROADMAP has read it's configuration file, it then reads the
  89. phone exchanges file. Here it groups the exchanges into calling groups,
  90. and finds out what other calling groups the group can call..
  91.  
  92. For Example:
  93.  
  94. Group Wallingford
  95. Exchanges 265,269,284,294,949
  96. Calling Meriden,Cheshire,New_Haven
  97. End Wallingford
  98.  
  99. The above is an entry in a typical ROADMAP.EXC file for Wallingford, CT.
  100. Roadmap reads this information, and from it does the following:
  101.  
  102. It creates a calling group called WALLINGFORD.
  103. It then is told information about group Wallingford. This information
  104. is in the form of what phone exchanges make up the group, and what
  105. other groups WALLINGFORD can call.
  106.  
  107. In this case, it knows that if the prefix of a phone # in your areacode
  108. begins with 265,269,284,294, or 949, it belongs to group WALLINGFORD,
  109. and that phone exchange can then call itself, and also the
  110. calling groups MERIDEN, CHESHIRE and NEW_HAVEN..
  111.  
  112.  
  113. Next, roadmap looks in your NODELIST directory, finds the latest NODELIST
  114. by date (this way it doesn't get confused in the beginning of JANUARY),
  115. and then opens the nodelist.
  116.  
  117. Roadmap scans the nodleist until it finds your Zone:net. It then, one by
  118. one, reads in every node in your net. It stores the node number, and then
  119. looks at the phone prefix for the phone number of the node. If there is
  120. no phone number (in the case of PVT nodes), it reports that the node
  121. is not within your areacode, or is PVT! and continues with the next node,
  122. disregaurding the "offending" node..
  123.  
  124. If it does find a phone number, it "checks" the prefix, and finds which
  125. calling group it belongs to. ROADMAP does NOT use the "location" found
  126. in the nodelist, it uses the phone number to find the "group" it is
  127. in as you specified in ROADMAP.EXC. If it cannot locate a dialing prefix
  128. match from the ROADMAP.EXC file, it warns you, and then throws that node
  129. away. After all the nodes in the net are processed, it closes the
  130. nodelist, and proceeds to "solve" the routing of your NET.
  131.  
  132.  
  133.  
  134. From here, roadmap looks, node by node, on how to create a NO-COST
  135. link to that node from your node. It goes by groups. Roadmap's logic
  136. can be confusing at first, and unfortunatly explaining things is NOT
  137. one of my strong points, but here goes:
  138.  
  139. Roadmap, while reading in the nodelist, searched for you. Let's say
  140. you are 1:141/865 (me). It finds out that your dialing prefix is
  141. 949, which is part of group WALLINGFORD, thus you are in group WALLINGFORD.
  142.  
  143. It now takes a node, and attemps to find a free link between you and the
  144. node in question. 
  145.  
  146. If you are local to the node, the node is placed at the beginning of
  147. the "solved" route file, with a SEND ???? in front of it. The ???? is 
  148. replaced with the verb you specified in the SEND_VERB keyword of the
  149. configuration file.
  150.  
  151. If the node is NOT local to you, it will attempt to find the shortest
  152. free route to that node. If it finds a route, it will place the node
  153. in the output "solved" file, with a SEND ???? Z:N/ROUTER in front
  154. of it, and any other nodes to be routed the same way. The ???? is 
  155. replaced with the verb you specified in the ROUTE_VERB keyword in
  156. the configuration file. The ROUTER will be replaced with the node
  157. number of the router it chose as the best person to send this node's
  158. mail to.
  159.  
  160. If ROADMAP is unable to find a toll-free link, it will
  161. place the node at the end of the "solved" route file, and will place
  162. a SEND ???? in front of it, and any other nodes that cannot be routed
  163. free. The ???? is replaced with the verb you specified in the
  164. NOTLOCAL_VERB keyword in the configuration file.
  165.  
  166.  
  167. PLEASE NOTE:    A TOLL FREE LINK means that NO NODE using roadmap
  168.                 will incur any expense in delivering the mail within the NET.
  169.                 ROADMAP IS DESIGNED NEVER TO MAKE ANY NODE MAKE
  170.                 AN LD CALL TO DELIVER NETMAIL WITHIN THE NET. IF
  171.                 ROADMAP CANNOT FIND A FREE LINK, IT DEAD-ENDS THAT
  172.                 NODE ON YOUR SYSTEM. You can either choose to send
  173.                 the mail yourself, incurring the charges yourself,
  174.                 or putting that node's mail on HOLD.. For this 
  175.                 reason, it is suggested the the ROUTE_TO nodes
  176.                 you choose also be using ROADMAP. This way, No-one
  177.                 will force any other node to make LD call's on it's 
  178.                 behalf.
  179.  
  180.  
  181. When roadmap cannot find a link in only a few steps (I.E. it's not local
  182. to you, or your routers), roadmap creates a "tree", starting with your
  183. routers, and builds search branches of that tree, one branch for every
  184. group that can be called (local to) by a group above it.. Example:
  185.  
  186.                                 Wallingford (Base of Tree, Level 1)
  187.                |------------------|-------------------|
  188. |--------------Meriden    |-----Cheshire   |------New_Haven (Level 2)
  189. Southington             Waterbury        Branford Milford Guilford (Level 3)
  190.  
  191.                 
  192. etc..etc..etc..
  193.  
  194. Roadmap keeps growing the search tree until it finds the group it's looking
  195. for (The group the node we are looking for is found). Once it finds this
  196. group, roadmap "looks up" to find which branch (level 2) spawned it. Level
  197. 2 is really all your routers, and by "looking up", it knows which router
  198. to route this node to.
  199.  
  200. PLEASE NOTE:    In this scenario, roadmap uses the CAN_ROUTE groups
  201.                 to determine if a group can be used in the search tree.
  202.                 For example, if, when ROADMAP starts searching group
  203.                 MERIDEN sees that MERIDEN can call group SOUTHINGTON,
  204.                 it marks SOUTHINGTON as a possible search "branch" on
  205.                 it's next pass (Next lower level). When roadmap gets
  206.                 to that level (Level 4 will expand Southington's calling
  207.                 area in the example above), roadmap first checks to see 
  208.                 if a node exists in Southington that can accept routed
  209.                 mail. It gets this from the CAN_ROUTE entries in the
  210.                 roadmap.cfg file. If group SOUTHINGTON does not appear,
  211.                 roadmap ignores Southington, saying that even if I
  212.                 can get to my target group via Southington, it won't
  213.                 matter because no-one in Southington can accept my mail.
  214.                 
  215. Now, let's examine this case:
  216.  
  217.                         Wallingford
  218.                         |
  219.                         Cheshire
  220.                         |
  221.                         Waterbury
  222.                         |
  223.                         Woodbury
  224.                         |
  225.                         Newtown
  226.                         |
  227.                         Danbury
  228.                        
  229. This is the shortest distance from Wallingford to Danbury. If all those
  230. towns above are in my CAN_ROUTE list, that's the route ROADMAP will choose
  231. when it trys to find a route to Danbury. If, however, I take a town out
  232. of the list, ROADMAP will attempt to find another route to DANBURY. 
  233. For example, lets say I take Cheshire out:
  234.  
  235.                         Wallingford
  236.                         |
  237.                         Meriden
  238.                         |
  239.                         Southington
  240.                         |
  241.                         Waterbury
  242.                         |
  243.                         Woodbury
  244.                         |
  245.                         Newtown
  246.                         |
  247.                         Danbury
  248.                         
  249. This is what happens, assuming all the above towns ARE in my
  250. CAN_ROUTE list. It said I cannot use Cheshire, but found out
  251. that Meriden can call Southington, which can call Waterbury, and
  252. chose that route. If it could not find a new route, it would mark
  253. that node as un-routable, and place it in the SEND LD line.
  254.  
  255. Now, for the reason why ROADMAP's CAN_ROUTE list HAS to be coordinated
  256. within a NET... 
  257.  
  258. Lets, for sake of argument, say the following towns are interconnected
  259. like this:
  260.  
  261.                 Wallingford----------------------
  262.                 |                               |
  263.                 Cheshire                        New Haven
  264.                 |                               |
  265.                 Waterbury                       Milford
  266.                 |                               |
  267.                 Woodbury-------------|       Bridgeport
  268.                 |                 Seymour       |
  269.                 Newtown              |-----------
  270.                 |
  271.                 Danbury
  272.                
  273. As you can see, both Bridgeport and Woodbury can call Seymour.
  274.  
  275. Now, lets say that ROADMAP attempts to solve the Cheshire
  276. nodes path to Danbury. WATERBURY, WOODBURY, and NEWTOWN are
  277. all in the node's CAN_ROUTE list, so ROADMAP determines the
  278. shortest distance to Danbury is .via. those 3 hops.
  279.  
  280. Now, ROADMAP on the system in Milford attempts to SOLVE for
  281. Danbury. It has BRIDGEPORT, SEYMOUR, WOODBURY, and NEWTOWN
  282. in it's list, and so, ROADMAP realizes that the shortest way
  283. to Danbury is going through Seymour. A total of 4 hops.
  284.  
  285. Now, the guy in BRIDGEPORT doesn't have SEYMOUR in his CAN_ROUTE list,
  286. so when ROADMAP solves for Danbury on his system, it says,
  287. hey, Seymour would be the shortest, but I can't go that way, so
  288. I have to go all the way around. MILFORD, NEW_HAVEN,WALLINGFORD,
  289. CHESHIRE,WATERBURY,WOODBURY and NEWTOWN are in his CAN_ROUTE list,
  290. and so roadmap determines the "best available" way to route to
  291. Danbury is through Milford...
  292.  
  293. We have a "ping-Pong" problem here... Milford will attempt to
  294. route Netmail destined to Danbury through Bridgeport. Bridgeport,
  295. on the other hand, will route it through Milford... So, the nodes
  296. will end up sending this poor little innocent netmail message back
  297. and forth between the node in Milford and the node in Bridgeport...
  298.  
  299. This is why IT IS VERY IMPORTANT that EVERYONE's CAN_ROUTE lists
  300. be the same in a NET!!!!!!!  
  301.  
  302. ***********************************************************************
  303. ******************** ROADMAP.CFG file Keywords ************************
  304. ***********************************************************************
  305.  
  306. Here is the list of keywords that can be included in the .CFG file, and
  307. their explanation. All keywords must be seperated from their arguments
  308. by at least one space, although any number of spaces can be used for
  309. viewability. Keywords ARE NOT CASE SENSITIVE.
  310.  
  311. NODELIST        Place the Path to where you store your NODELIST directoy.
  312.  
  313. MY_ZONE         Your fidonet Zone number.
  314.  
  315. NY_NET          Your Fidonet NET number.
  316.  
  317. NY_NODE         Your Fidonet NODE number.
  318.  
  319. EXCLUDE         List the nodes that you DO NOT want in the output.
  320.                 These are usually numbers if you have alias numbers,
  321.                 such as an administrative number. But, any number can
  322.                 be excluded.
  323.                 You can have a Maximum of 20 numbers here, and you can
  324.                 have them spread out over more than one EXCLUDE keyword.
  325.                 
  326. AREACODE        Your Areacode, as seen in the nodelist.
  327.  
  328. ROUTE_TO        The nodes that have agreed to accept your routed mail.
  329.                 It is suggested that these nodes also run ROADMAP.
  330.                 You can have a Maximum of 10 Nodes that you can send
  331.                 your ROUTED mail to, and they can be spread out over
  332.                 more than one ROUTE_TO keyword.
  333.                 
  334. CAN_ROUTE       This is a list of the calling groups that have a node
  335.                 in them that is willing to route mail.
  336.                 A Maximum of 50 CAN_ROUTE Groups can be given, and 
  337.                 you can spread them out over more than one CAN_ROUTE
  338.                 keyword, as shown in the sample .CFG file.
  339.                 
  340. SEND_VERB       This is the "modifier" that ROADMAP will place after
  341.                 any node that you can call locally, in the ROUTE.CFG
  342.                 file. This is the verb (Crash, Normal, Direct, Hold)
  343.                 that your mailer will use when determining the priority
  344.                 of the mail to these nodes. 
  345.                 
  346. ROUTE_VERB      This is the "modifier" ROADMAP will place after the
  347.                 ROUTE verb in the ROUTE.CFG file. This is the verb
  348.                 (Crash, Normal, Direct, Hold) that your mailer will
  349.                 use when determining the priority to send this mail
  350.                 to the node (Your Routers, the nodes in you ROUTE_TO
  351.                 list).
  352.                 
  353. NOTLOCAL_VERB   This it the "modifier" that roadmap will pace in your
  354.                 ROUTE.CFG file after and nodes that cannot be reached
  355.                 via a toll free link. Placing HOLD here will cause
  356.                 your mailer NEVER to call these nodes, thus NOT making
  357.                 any LD calls within your net. You could choose to
  358.                 place any other "modifier" here, so as to deliever
  359.                 the mail yourself, if your system gets any mail for 
  360.                 these nodes.
  361.                 
  362.                 
  363. NOTLOCAL_ROUTE  This keyword is optional. If this keyword is not used,
  364.                 ROADMAP will create a "SEND (NOTLOCAL_VERB) nodes....
  365.                 for all nodes that cannot be routed within the net
  366.                 toll free.
  367.                 If this keyword is used, ROADMAP will route all the
  368.                 nodes that cannot be routed for free to this node.
  369.                 
  370.                 THIS CAN BE DANGEROUS, AS IT ALLOWS ROADMAP TO SEND
  371.                 MAIL TO ANOTHER SYSTEM THAT MAY ULTIMATLY MAKE THAT
  372.                 SYSTEM CALL LONG DISTANCE!!! USE THIS KEYWORD WITH
  373.                 CAUTION, AND CHECK WITH THE NODE YOU PLAN TO ROUTE
  374.                 THESE 'UNROUTABLE' NODES TO BEFORE YOU DO THIS.
  375.  
  376. BEGIN_CFG       This marks the Beginning of you ROUTE.CFG template.
  377.                 Roadmap needs a TEMPLATE ROUTE.CFG file, that it will
  378.                 place it's "answers" into. This is because ROADMAP 
  379.                 cannot solve out of net LPM, and other special
  380.                 routing that you and others may have already established.
  381.                 The best thing to do is take the sample ROADMAP.CFG file
  382.                 that came with the package, and delete EVERYTHING after
  383.                 BEGIN_CFG. Then, append a copy of your PRESENT ROUTE.CFG
  384.                 to the ROADMAP.CFG file, after the BEGIN.CFG keyword.
  385.                 
  386. INSERT_MAP      This is used inside the ROUTE.CFG TEMPLATE. Wherever
  387.                 you place this verb, ROADMAP will replace this verb
  388.                 with the routing it determined for your NET. This
  389.                 verb can be used as many times as you want within the
  390.                 template. (Just in case you have more than one event that
  391.                 requires NET routing).
  392.                 
  393. END_CFG         This signifies the End of your ROUTE.CFG template file,
  394.                 and usually the end of your ROADMAP.CFG file as well.
  395.                 
  396.  
  397.  
  398. **********************************************************************
  399. ********************** ROADMAP.EXC File Format ***********************
  400. **********************************************************************
  401.  
  402. The ROADMAP.EXC file holds all the phonde dialing info for your
  403. particular area. This information may not be easy to find; it took
  404. me almost a week of searching various phone books (The front usually
  405. has a map of the calling area it covers with dialing exchanges 
  406. and calling coverages). 
  407.  
  408. First, you must pick a group name for every DIFFERENT calling group
  409. in your area. The group name you pick is arbitrary, so long as it
  410. has no spaces in it, and is not longer than 20 characters. I attempted
  411. to represent the towns (logical, huh?) that they encompass. Usually,
  412. the phone company has already named these groups. For Example, in the
  413. front cover of the NEW_HAVEN, CT phone book, the phone company has
  414. a little map showing all the dialing prefixes in NEW_HAVEN, and then
  415. little arrows to surrounding towns that NEW_HAVEN can dial. That's what
  416. you want. Physically, NEW_HAVEN, CT includes other towns, like North
  417. Haven, and Hamden. But, ALL their phonde numbers have the same dialing
  418. "range", so you include them in one group!
  419.  
  420. You organize a group like this in the ROADMAP.EXC file:
  421.  
  422. Group NEW_HAVEN
  423. Exchanges xxx,yyy,zzz,aaa,bbb
  424. Exchanges xxy,yyx,zza,aab,bbz
  425. Calling WALLINGFORD,MILFORD
  426. Calling CHESHIRE,BRANFORD
  427. End   NEW_HAVEN
  428.  
  429. Please note that you can have any number of EXCHANGES and CALLING keywords
  430. within a group. You can have 75 Exchanges (dialing Prefixes) and 20 Calling
  431. groups.
  432.  
  433. You can have a Maximum of 75 Groups.
  434.  
  435. When creating the calling groups, if you say that a group can call another
  436. group, you MUST define that other group somewhere in your ROADMAP.EXC file.
  437.  
  438. For example, I mentioned WALLINGFORD, MILFORD, CHESHIRE and BRANFDORD
  439. above. This means that I MUST define those groups in my ROADMAP.CFG also.
  440. Also, when I do define those groups, I put NEW_HAVEN in as a group it
  441. can call.
  442.  
  443. Hint:   Net 141's boundry is Southington. Southington can
  444.         call BRISTOL, but BRISTOL is not part of NET 141. It is
  445.         our neighboring net, NET 142. Which means when I solve for
  446.         net 141, I will NEVER have a BRISTOL node to deal with.
  447.         So, even though SOUTHINGTON can dial BRISTOL, I didn't
  448.         put BRISTOL in SOUTINGTON's calling info. This way,
  449.         I don't have to define BRISTOL in ROADMAP.EXC.
  450.          
  451.  
  452. It's pretty self explanatory, take a peek at the sample ROADMAP.EXC file
  453. if you still have any questions. If you still have any questions,
  454. comments, suggestions, or that "b" word (Bug reports), feel free
  455. to Netmail me at 1:141/865, or log into the BBS at (203) 949-0375.
  456.  
  457. While I'm here, I'd like to thank some people that helped me with
  458. beta-testing this program, putting up with my numerous phone calls,
  459. and netmail messages attempting to check ROADMAP, and all of NET 141
  460. in general for being so receptive and helpful.
  461.  
  462. Brian Bonfietti (141/1130) , Dave Drouin  (141/805) , Bob Morris  (141/333)
  463. Furlan Primus   (141/1100) , Tom Ruddy    (141/755) , Don Dawson  (141/730)
  464. Joel Lambert    (141/455)  , Terry Wodek  (141/375) , Jim Ryan    (141/9)
  465. Mark Terrace    (141/340)  , Phil Palumbo (141/336) , Don Bates   (141/814)
  466. Steve Sekula    (141/110)  , Chris Regan  (141/565) , Brian Dodds (141/1170)   
  467.  
  468. And last but not least, Registration:
  469. I wrote this to help out Fidonet, I don't want money for it. Maybe
  470. a note letting me know you use it would be nice, but not nessesary.
  471. I do ask you to do one little thing though. If you use it, go out,
  472. and buy a kid an ice cream cone. Spend some time with a kid. You'll
  473. both enjoy the time you spend together!
  474.  
  475. Andre Normandin
  476. NETWORK SOLUTIONS
  477. Fidonet:  1:141/865
  478. BBS: (203) 949-0375
  479.  
  480.