No full-text available
To read the full-text of this research,
you can request a copy directly from the author.
REXDC - A Remote Execution Mechanism.
Abstract
A new concept, Remote EXecution with During Construct (REXDC), is introduced. In addition to the Remote Procedure Call (RPC) functionality, it allows the client to execute cooperatively with the server during the call period. The During Construct (DC) is a unit where effective cooperation between the client and the server is provided. A mechanism is proposed to integrate the REXDC into a many-client and many-server environment. The mechanism provides a way to program different types of process to process communication and synchronization.
... By specifying the computation to be performed while waiting for data, it allows the efficient use of CPU time. A similar construct has been proposed for RPC (Chang, 1989). ...
Computation intensive programs can utilise idle workstations in a cluster by exploiting the parallelism inherent in the problem being solved. A programming language for distributed computing offers advantages like early detection of type mismatch in communication and offers structured mechanisms to specify possible overlap in communication and computation, and exception handling for catching run time errors. Success of a language depends on its ease of use, expressibility and efficient implementation of its constructs.
EC is a super set of C supporting process creation, a message passing mechanism, and exception handling. The pipelined communication constructs and multiple process instances help in expressing concurrency between computation and communication. Data driven activation of EC processes is used for scheduling.
EC has been implemented in a Sun-3 workstation cluster. An inter-node message passing mechanism has been built on top of the socket interface using the TCP protocol, and intra-node message passing is done by passing pointers to improve efficiency. However, message type variables hide the implementation details, improve type safety and location transparency of a program.
Matchmaker, a language used to specify and automate the generation of interprocess communication interfaces, is presented. The process of and reasons for the evolution of Matchmaker are described. Performance and usage statistics are presented. Comparisons are made between Matchmaker and other related systems. Possible future directions are examined.
A software structure created by the Heterogeneous Computer Systems (HCS) Project at the University of Washington was designed to address the problems of heterogeneity that typically arise in research computing environments.
TRIX is a kernel operating system designed for use on a network of interconnected processors. Its semantics revolve around a stream communication mechanism, rather than passive objects such as files or processes, allowing uniform and transparent access to local and remote objects. The basis of TRIX semantics on communication paths yields several interesting properties: (i) minimization of the kernel system (directories and naming mechanisms, for example, may be left to higher-level software); (ii) abstraction of function from implementation (a file containing the digits of Pl, for example, may be indistinguishable from a process which computes them on demand); and (iii) a single, ″anarchistic″ name space in which interpretation of names and access to the services they denote is controlled by local rather than global mechanism.
This paper presents a short survey of contemporary work in communication models for distributed computer systems, and then discusses in detail the Remote Pipe and Procedure Model. The survey portion of the paper discusses two classes of models for distributed communication: message based models and remote procedure call models. The advantages and disadvantages of both approaches are outlined.
MultiRPC is an invocation mechanism that enables a client to access multiple servers in a single remote procedure call. Parallelism is obtained from concurrency of processing on servers and from the overlapping of retransmissions and timeouts. Each of the parallel calls retains the semantics and functionally of the underlying remote procedure call mechanism. These include secure, authenticated communication and the use of application-specific side effects. The underlying communication medium does not have to support multicast of broadcast transmission. This paper describes the design and evolution of MultiRPC, focusing on the issues of runtime efficiency, versatility, and ease of use. The authors derive an analytic model of the system and present experimental results that validate this model. They also present their observations on using MultiRPC to contact up to 100 servers in parallel. Keywords: UNIX operating system; C programming language.
A parallel procedure call executes a procedure in n different address spaces in parallel. The calling code remains blocked while the n procedures execute. As each procedure result becomes available, the caller is unblocked to execute a statement to process the result of the returned call. After executing the statement, the caller reblocks to wait for the next result. This continues until the caller breaks out of the parallel remote procedure call or until no further results are available.
Programs making parallel procedure calls are modeled as network processes. A network process is a tree of local processes that communicate by making parallel procedure calls. We report on the design and implementation of PARPC, a system for developing and executing such programs on a network of UNIX hosts.
Distributed programs that run on nodes of a network are now technologically feasible, and are well-suited to the needs of organizations. However, our knowledge about how to construct such programs is limited. This paper discusses primitives that support the construction of distributed programs. Attention is focussed on primitives in two major areas: modularity and communication. The issues underlying the selection of the primitives are discussed, especially the issue of providing robust behavior, and various candidates are analyzed. The primitives will ultimately be provided as part of a programming language that will be used to experiment with construction of distributed programs.
A reliable broadcast protocol for an unreliable broadcast network is described. The protocol operates between the application programs and the broadcast network. It isolates the application programs from the unreliable characteristics of the communication network. The protocol guarantees that all of the broadcast messages are received at all of the operational receivers in a broadcast group. In addition, the sequence of messages is the same at each of the receivers and a total ordering exists among all broadcast messages. This unique message sequencing can be used to simplify distributed database systems and distributed processing algorithms. The protocol can operate with as few as one acknowledgment message per broadcast message, instead of one acknowledgment from each receiver per broadcast message. The protocol continues to operate when sites in the broadcast group fail.
Accent, a communication-oriented operating system kernel was designed to support the needs of a large network of personal computers. One of the Accent design goals was that its communication abstractions be transparently extensible into the network environment. We therefore chose to pass all data between processes by-value in messages. At the same time, experience with previous operating systems, notably Rochester's RIG system led us to seek an alternative to data copying for large messages. Our approach was to combine virtual memory management and interprocess communication in such a way that large data transfers could use memory mapping techniques rather than data copying. By-value semantics are preserved by transferring large amounts of message data with copy-on-write memory mapping, so that both the sending and receiving process have their own logical (if not disjoint physical) copy of the data.
A new proposal for synchronization and communication in parallel programs is presented. The proposal synthesizes and extends aspects of procedures, coroutines, critical regions, messages, and monitors. It provides a single notation for parallel programming with or without shared variables and is suited for either shared or distributed memory architectures. The essential new concepts are operations, input statements, and resources. The proposal is illustrated by the solutions of a variety of parallel programming problems; its relation to other parallel programming proposals is also discussed.
Remote procedure calls ( RPC ) are a useful paradigm for providing communication across a network between programs written in a high level language. This paper describes a package, written as part of the Cedar project, providing a remote procedure call facility. The paper describes the options that face a designer of such a package, and the decisions we made. We describe the overall structure of our RPC mechanism, our facilities for binding RPC clients, the transport level communication protocol, and some performance measurements. We include descriptions of some optimisations we used to achieve high performance and to minimize the load on server machines that have many clients.
Our primary aim in building an RPC package was to make the building of distributed systems easier. Previous protocols were sufficiently hard to use that only members of a select group of communication experts were willing to undertake the construction of distributed systems. We hoped to overcome this by providing a communication paradigm as close as possible to the familiar facilities of our high level languages. To achieve this aim, we concentrated on making remote calls efficient, and on making the semantics of remote calls as close as possible to those of local calls.
A troupe is a set of replicas of a module, executing on machines that have independent failure modes. Troupes are the building blocks of replicated distributed programs and the key to achieving high availability. Individual members of a troupe do not communicate among themselves, and are unaware of one another's existence; this property is what distinguishes troupes from other software architectures for fault tolerance. Replicated procedure call is introduced to handle the many-to-many pattern of communication between troupes. The semantics of replicated procedure call can be summarized as exactly-once execution at all replicas. An implementation of troupes and replicated procedure call is described, and its performance is measured. The problem of concurrency control for troupes is examined, and a commit protocol for replicated atomic transactions is presented. Binding and reconfiguration mechanisms for replicated distributed programs are described.
Remote Procedure Call Programming Guide
- Remote Procedure Call Programming
CCITT Remote Operations: Model. Notation and Service Definition
- Remote Operations