At a superficial level, Scout paths are similar to UNIX pipes [28] and Pilot streams [25]. While all three abstractions have in common a linear sequence of ``components'' (processes in UNIX, Mesa modules in Pilot, stages in Scout), neither pipes nor streams provide any global context to the individual modules. Neither do they attempt to optimize the code along a ``path.'' It is also the case that UNIX pipes are more coarse-grain and uni-directional.
As mentioned in Section 1, there is a wealth of mechanisms that offer point-solutions to the more general problem of exploiting paths, both as a structuring framework and as an optimization technique. This related work falls broadly into two categories, depending on their primary objective:
The system that is probably closest to Scout, at least in terminology, is Da CaPo (dynamic configuration of protocols) [11]. It defines an infrastructure for building multimedia protocols. While Da CaPo has a notion of paths and stages, there are important differences at all levels. At lowest level, Da CaPo paths are uni-directional and stages have very restricted functionality (they are essentially non-blocking event-handlers). As a result, Da CaPo is just powerful enough to accommodate common networking tasks. Also, interoperability with existing protocols is not a goal of Da CaPo. Another important difference is that path creation is left completely to an external ``configuration manager.'' As pointed out in Section 2, this means that in any reasonably complex system, the configuration manager will be burdened by detailed knowledge of the internal workings of particular protocols. In contrast, our path abstraction makes it easy to exploit both local and global knowledge during path creation. At a higher level, Da CaPo focuses completely on automatically selecting appropriate protocol functionality; performance and resource allocation appear to be secondary issues.
Kay [17] introduces the notion of a PathID, which is designed specifically to reduce the latency of receive-side network processing. Fundamentally, a PathID is similar to a fine-grained virtual circuit identifier (VCI) in ATM networks [7]. Since PathIDs are stored in a known location in the header of network messages, packet classification becomes trivial (in the worst case a table-lookup). In [17], packets with a PathID are processed by highly optimized, handwritten code. Since this code is manually tuned, maintainability and ease of use are problematic. In fact, the paper suggests that PathIDs should be used for the rare cases where having to maintain two parallel branches of source code is a justifiable cost. Finally, PathIDs do not attempt to elevate paths to a fundamental OS structure, and the problem of creating paths without human direction is not addressed.