Distributed shared library

  • Authors:
  • Herman C. Rao;Larry L. Peterson

  • Affiliations:
  • AT&T Bell Laboratories, Murray Hill, NJ;University of Arizona, Tucson, AZ

  • Venue:
  • EW 5 Proceedings of the 5th workshop on ACM SIGOPS European workshop: Models and paradigms for distributed systems structuring
  • Year:
  • 1992

Quantified Score

Hi-index 0.00

Visualization

Abstract

By applying the notion of Shared Library to distributed environments, this paper introduces a new model, called the Distributed Shared Library (DSLib), which allows a given library function to be executed on the same address space of its invoker as well as on a different address space. We argue that remote services, which do not maintain static data or share global data with others, should be implemented as library functions, rather than individual servers. Examples of remote services include remote access to special devices (e.g., audio devices), and I/O intense functions that would have better performance if executed on the file server rather than on the local host (e.g., copying files located on the same file server). The Distributed Shared Library Model suggests a simple, elegant method to implement remote library functions. It, therefore, encourages programmers to migrate system services implemented as local functions to remote functions.Although built on top of Remote Procedure Call (RPC), the DSLib Model refines the latter in three aspects:Lazy Linking. Rather than linking service functions on compile-time, a per-host server links them only when accessed, by dynamically invoking a shared library. Hence, it is possible to runtime create, upgrade, or replace services without shutdown the server at all.Single Server. A single, generic super server is used to replace a collection of service-dependent servers under normal RPC model. Not only does this replacement save computing resources (e.g., idle processes waiting for requests) and reduce the overhead to maintain individual servers, but it also frees programmers from issues of constructing servers. The result is that the existence of servers is completely transparent from end-users as well as programmers.Customization. Users (application programs or end-users) are allowed to choose a shared library where service functions are implemented, decide to execute these functions locally (i.e., on the same address space) or remotely (i.e., on a different address space), and select the host for remote execution.The Distributed Shared Library Model adopts a single, per-host server, called Function EX-Ecutor (FEXE). that dynamically links a shared library, locates and executes the desired function, and returns the result to the client. Like UNIX's Internet Service Daemon (inetd), FEXE is a per-host demuliplexer of a collection of network services. Unlike inetd which executing commands, FEXE deals with library functions, and therefore, it avoids forking a new process for every request as inetd does.A prototype of FEXE on top of Sun RPC and Dynamic Linker has been implemented. This paper describes how to implement a DSLib function and explains how the function is invoked.