davecl@shark.UUCP (11/15/83)
There are a couple of problems with arbitrarily "looking ahead" in uucp paths to see if you can make any shortcuts. First, imagine a situation where you have the following: Site A<--------------------------->Site B \ / \ / \ / +-------->Site C<-----/ i.e., where site A talks to sites B and C, site B talks to A and C, and site C talks to A and B. Suppose that for some reason or another, the link between sites A and C goes down for a long period of time, while the links between site A and B, and site B and C are still up. If you were on site A and had to reach someone on site C, without "optimization" you could just send the message through site B to reach site C. With "optimization", unless there was someone around to muck with tables, you would be unable to reach site C. The other big problem is that there is no guarantee that site "x" relative to site "y" is the same as site "x" relative to site "z". If all sites knew the TOTAL connectivity of the "uucp network" you might be able to handle the previous cases, but with the size, dynamics, distributed control, and general lack of complete knowledge it is IMPOSSIBLE to generate a system where you can 100% safely shortcut uucp paths. A couple of suggestions: Rather than taking a step as drastic as changing the semantics of a uucp path, you could just do first level rerouting; i.e., if you are presented with the path "a!b!c" and your site doesn't know how to reach site a directly you would use existing databases to try to generate a path to reach site a. You also could pick another syntax (such as the RFC822 source routed syntax) that could be specified as having the semantic property that parts of the path might be shortcutted. To summarize, for the above reasons, Tektronix currently does not, and most likely will not, ever do the suggested "uucp path" optimization. (However, we do do the first level rerouting that I mentioned a couple of paragraphs above). Dave Clemans Tektronix