Mark Yarvis, Peter Reiher, and Gerald J. Popek, "Conductor: A Framework for Distribu ted Adaptation." Proc. Seventh Workshop on Hot Topics in Operating Systems (HotOS VII), Rio Rico, AZ, March 1999.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....of supporting diverse requirements for emerging valueadded service oriented applications such as bandwidth on demand, multimedia teleconference and telemedicine. However, to our knowledge, all of the currently proposed application level service architectures, for example, 7] 9] 10] [13], 16] are restricted to operate within one administrative domain, or a confederation of administrative domains. This paper addresses the following issue: Is it possible to remove the boundary that confines this closeness in operating environment and be able to extend application level ....

....service set up, maintenance and teardown. Section 4 presents our implementation design of the programmable execution environment for DEEPSEA and we conclude in Section 5. 2. 0 Related Work Some notable examples of earlier research work on adaptive application level networking include Conductor [13], Internet Core Network Architecture for Integrated Communication (ICEBERG) 7] and Dynamic VPN [16] Conductor is a distributed adaptation framework that consists of Conductor enabled nodes deployed inside an organization s network infrastructure or ISP, in order for the dynamic installation ....

M.Yarvis,P.Reiher,andG.Popek,"Conductor: A Framework for Distributed Adaptation," UCLA Tech Report: CSD-TR-010025.

....areas of related work. Here we briefly examine them and discuss how our work distinguishes from them. Transformational proxies: Our work is heavily influenced by the TACC [6] programming model; however, TACC focuses on the last hop issue and is limited to a single proxy architecture. Conductor [7] remedies in this regard, but does not address issues of dynamic insertion, deletion, and migration of proxies to adapt to server and network load variations. Furthermore, Conductor does not provide mobility support or handoffs across devices. Handoffs: Our work has benefitted from ideas of ....

Mark Yarvis, Peter Reiher, , and Gerald J. Popek., "Conductor: A framework for distributed adaptation.," in Proc. Seventh Workshop on Hot Topics in Operating Systems (HotOS VII), Rio Rico, AZ, March 1999.

....such as IFS [10] and Ufo [1] and several libraries that provide specific, transparent network services such as SOCKS [20] Reliable Sockets [29] and Migrate [23, 24] Each of these systems provides only a specific service, however, not an architecture usable by third parties. Conductor [28] traps application network operations and transparently layers composable adaptors on TCP connections, but its focus is on optimizing flows performance characteristics, not on providing arbitrary additional services. Similarly, Protocol Boosters [13] proposes interposing transparent agents ....

YARVIS, M., REIHER,P.,AND POPEK, G. J. Conductor: A framework for distributed adaptation. In Proc. HotOSVII (Mar. 1999), pp. 44--51.

.... A number of systems looked at application specific scheduling in reservation capable environments, for example, the OMEGA end system architecture [39] 40] A number of systems share our goal of supporting userspecified, adaptive streaming data applications, including CANS [9] Conductor [41], Darwin [5] End to end Media Paths [2] Ninja [42] PATHS [43] and [12] Central to all of these systems is the notion of paths of stream transformers that must be scheduled on the network, and the presence of a centralized plan manager to schedule paths across the network, similar to ....

M. Yavis, P. Reiher, and G. J. Popek, "Conductor: A framework for distributed adaptation," in Proceedings of the IEEE Workshop on the Hot Topics in Operating Systems (HOTOS), Mar. 1999.

....interposition. Reliable Sockets (Rocks) protects socket based applications from network failures by wrapping socket related system calls [38] a similar method was used to implement the transparent connection migration functionality found in the latest iteration of Migrate [33] Conductor [37] traps application network operations and transparently layers composable adaptors on TCP connections, but its focus is on optimizing ows performance characteristics, not on providing arbitrary additional services. To the best of our knowledge, Tesla represents the rst interposition toolkit ....

Mark Yarvis, Peter Reiher, and Gerald J. Popek. Conductor: A framework for distributed adaptation. In Proc. 7th Workshop on Hot Topics in Operation Systems, pages 44-51, March 1999. 72

....to decide when and how to modify runtime behavior, and the code embodying alternative algorithms or data representations. Current software support for adaptive applications primarily focuses on operating system, network, and middleware services such as runtime monitoring and resource management [22, 17, 6, 14, 30]. Programming language and compiler support for describing and managing adaptivity in distributed applications are essentially nonexistent. Therefore, the adaptation code is directly intermixed with the base application code, which is usually already fairly complex without adaptivity and becomes ....

.... Con ductor system is an application transparent system that monitors data flows on behalf of an application to determine if the data path from source to destination can support those flows, and if not, deploys adaptation agents along the path to adapt the flows to changing network conditions [30]. Recently, researchers from all the above groups have collaborated to develop a common conceptual framework for describing the architecture of network adaptive systems [4] The framework abstracts and integrates common design choices from their respective systems, and the authors have shown how ....

M. arvis, P. Reiher, and G. Popek. Conductor: A Framework for Distributed Adaptation. In Proc. 7th Workshop on Hot Topics in Operating Systems, Mar. 1999. 11

....control and resource reservation [16] or on the use of proxies that perform data ltering or on demand dynamic distillation (data type speci c lossy compression) 7, 22] Odyssey [19] sees adaptation as a collaborative partnership between the system and individual applications. Conductor [21] provides a general mechanism to select and dynamically deploy combinations of adaptive agents to multiple points in a network. Our approach to the problem of adapting to variability and heterogeneity is based on the runtime recon guration of the application. The recon guration consists of either ....

M. Yarvis, P. Reiher, and G. J. Popek. Conductor: A Framework for Distributed Adaptation. In Proceedings of the Seventh Workshop on Hot Topics in Operating Systems (HotOS '99), March 1999.

No context found.

Mark Yarvis, Peter Reiher, and Gerald J. Popek, "Conductor: A Framework for Distribu ted Adaptation." Proc. Seventh Workshop on Hot Topics in Operating Systems (HotOS VII), Rio Rico, AZ, March 1999.

No context found.

M. Yarvis, P. Reiher, G. Popek. "Conductor: A Framework for Distributed Adaptation." Proceedings of the Seventh Workshop on Hot Topics in Operating Systems (HotOS VII), Rio Rico, Arizona, March 1999.

No context found.

M. Yarvis, P. Reiher, G. Popek. "Conductor: A Framework for Distributed Adaptation." Proceedings of the Seventh Workshop on Hot Topics in Operating Systems (HotOS VII), Rio Rico, Arizona, March 1999.

....synchronization can not insulate the transport layer from midstream adaptation nor provide proper recovery from adaptor failure. VIII. STATUS AND FUTURE WORK Our belief that distributed adaptation is an important facility, as the complexity of networks increases, was originally published in [13]. Since that time, we have completed our initial implementation of the Conductor framework. This implementation allows selection and distributed deployment of adaptor modules into a network. These adaptor modules can then perform arbitrary operations on a data stream. We also constructed a sample ....

Mark Yarvis, Peter Reiher, and Gerald J. Popek, "Conductor: A Framework for Distributed Adaptation," Proceedings of the Seventh Workshop on Hot Topics in Operating Systems, Rio Rico, AZ, March 1999.

No context found.

Mark Yarvis, Peter Reiher, and Gerald J. Popek, "Conductor: A Framework for Distributed Adaptation," Proceedings of the 7 th Workshop on Hot Topics in Operating Systems (HotOS VII), Rio Rico, AZ, March 1999.

....of the new networking features they offer [3, 4, 7, 8] Other open architecture systems seek to provide their benefits even to programs and data streams that are unaware of the new possibilities. Some examples of the latter are protocol boosters [5] the Berkeley proxy system [2] and Conductor [9]. These application unaware systems sometimes require explicit user or system administrator configuration, such as designating a proxy point, or pre deploying various forms of adaptation modules. However, this approach limits their utility, since they provide benefit only when some person is ....

M. Yarvis, P. Reiher, and G. Popek, "Conductor: A framework for distributed adaptation", Proceedings of the Seventh Workshop on Hot Topics in Operating Systems. IEEE Computer Society Press, March 1999.

No context found.

Mark Yarvis, Peter Reiher, , and Gerald J. Popek., "Conductor: A framework for distributed adaptation.," in Proc. Seventh Workshop on Hot Topics in Operating Systems (HotOS VII), Rio Rico, AZ, March 1999.

No context found.

M. Yarvis, P. Reiher, G. Popek, Conductor: A Framework for Distributed Adaptation, in: Proc. 7th Workshop on Hot Topics in Operating Systems, 1999.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC