Decentralized resource management for a distributed continuous media server Cyrus Shahabi and Farnoush Banaei-Kashani IEEE Transactions on Parallel and.
Published byModified over 4 years ago
Presentation on theme: "Decentralized resource management for a distributed continuous media server Cyrus Shahabi and Farnoush Banaei-Kashani IEEE Transactions on Parallel and."— Presentation transcript:
Decentralized resource management for a distributed continuous media server Cyrus Shahabi and Farnoush Banaei-Kashani IEEE Transactions on Parallel and Distributed Systems
DCMS architecture Network topology Designed with hierarchical network topology. Head-end The nodes at the leaves. Clients are connected to the head-ends. When a request for an object arrives at a head-end, the head-end serves the client if the object is available in its local storage. Otherwise, the request will be forwarded to the higher levels of the hierarchy. Resource management middleware Object placement Object delivery
RedHi Pure hierarchy: degree-1 parent. RedHi: Relax the degree-1 parent to degree-2 or more. The redundancy in RedHi is not of bandwidth, but of number of links.
Assumptions The entire set of objects are located at the root initially. When an object is served through a path from a server node to a head-end, the object is cached at all intermediate nodes on the path based on the LRU caching policy. The state of system resources are fully distributed. (Each node only stores the state data relevant to the local resources.)
Mechanisms Object location Locate all nodes that have the object stored locally. Path selection Select one of those nodes as the object server and select the “ best ” path. Resource reservation Reserve required streaming resources along the selected path.
Path selection Use a cost function to evaluate a path. Parameters Length of the path (is compared first) Amount of free streaming resources available along the path Bottleneck Minimum amount of free bandwidth among nodes Average
Resource reservation General approaches Pessimistic Preserving all resources that might be required during the path selection. Releasing the extra resources after the path is actually selected. Resources are over-reserved. Optimistic Reserving the required resources after path selection is finalized. The resource required for the selected path might have been pre-allocated to other concurrent requests.
Moderate policies Early Release Pessimistic (ERP) Resources are still preserved during query propagation. The extra resources are released early during the path selection process. Early Reserve Optimistic (ERO) Resources are reserved early during response processing. (before path selection is finalized)