Results 1 - 10
of
248
The X Window System
- ACM Transactions on Graphics, Vol
, 1986
"... The X Window System, Version 11, is the standard window system on Linux and UNIX systems. X11, designed in 1987, was “state of the art ” at that time. From its inception, X has been a network transparent window system in which X client applications can run on any machine in a network using an X serv ..."
Abstract
-
Cited by 392 (2 self)
- Add to MetaCart
(Show Context)
The X Window System, Version 11, is the standard window system on Linux and UNIX systems. X11, designed in 1987, was “state of the art ” at that time. From its inception, X has been a network transparent window system in which X client applications can run on any machine in a network using an X server running on any display. While there have been some significant extensions to X over its history (e.g. OpenGL support), X’s design lay fallow over much of the 1990’s. With the increasing interest in open source systems, it was no longer sufficient for modern applications and a significant overhaul is now well underway. This paper describes revisions to the architecture of the window system used in a growing fraction of desktops and embedded systems 1
Aries: A transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging
- ACM Transactions on Database Systems
, 1992
"... In this paper we present a simple and efficient method, called ARIES ( Algorithm for Recouery and Isolation Exploiting Semantics), which supports partial rollbacks of transactions, finegranularity (e.g., record) locking and recovery using write-ahead logging (WAL). We introduce the paradigm of repea ..."
Abstract
-
Cited by 388 (10 self)
- Add to MetaCart
In this paper we present a simple and efficient method, called ARIES ( Algorithm for Recouery and Isolation Exploiting Semantics), which supports partial rollbacks of transactions, finegranularity (e.g., record) locking and recovery using write-ahead logging (WAL). We introduce the paradigm of repeating history to redo all missing updates before performing the rollbacks of the loser transactions during restart after a system failure. ARIES uses a log sequence number in each page to correlate the state of a page with respect to logged updates of that page. All updates of a transaction are logged, including those performed during rollbacks. By appropriate chaining of the log records written during rollbacks to those written during forward progress, a bounded amount of logging is ensured during rollbacks even in the face of repeated failures during restart or of nested rollbacks We deal with a variety of features that are very Important in building and operating an industrial-strength transaction processing system ARIES supports fuzzy checkpoints, selective and deferred restart, fuzzy image copies, media recovery, and high concurrency lock modes (e. g., increment /decrement) which exploit the semantics of the operations and require the ability to perform operation logging. ARIES is flexible with respect to the kinds of buffer management policies that can be implemented. It supports objects of
Optimistic recovery in distributed systems
- ACM Transactions on Computer Systems
, 1985
"... Optimistic Recovery is a new technique supporting application-independent transparent recovery from processor failures in distributed systems. In optimistic recovery communication, computation and checkpointing proceed asynchronously. Synchronization is replaced by causal dependency trock-ing, which ..."
Abstract
-
Cited by 355 (6 self)
- Add to MetaCart
Optimistic Recovery is a new technique supporting application-independent transparent recovery from processor failures in distributed systems. In optimistic recovery communication, computation and checkpointing proceed asynchronously. Synchronization is replaced by causal dependency trock-ing, which enables a posteriori reconstruction of a consistent distributed system state following a failure using process rollback and message replay. Because there is no synchronization among computation, communication, and checkpointing, optimistic recovery can tolerate the failure of an arbitrary number of processors and yields better throughput and response time than other general recovery techniques whenever failures are infre-quent.
Building Secure and Reliable Network Applications
, 1996
"... ly, the remote procedure call problem, which an RPC protocol undertakes to solve, consists of emulating LPC using message passing. LPC has a number of "properties" -- a single procedure invocation results in exactly one execution of the procedure body, the result returned is reliably deliv ..."
Abstract
-
Cited by 230 (16 self)
- Add to MetaCart
ly, the remote procedure call problem, which an RPC protocol undertakes to solve, consists of emulating LPC using message passing. LPC has a number of "properties" -- a single procedure invocation results in exactly one execution of the procedure body, the result returned is reliably delivered to the invoker, and exceptions are raised if (and only if) an error occurs. Given a completely reliable communication environment, which never loses, duplicates, or reorders messages, and given client and server processes that never fail, RPC would be trivial to solve. The sender would merely package the invocation into one or more messages, and transmit these to the server. The server would unpack the data into local variables, perform the desired operation, and send back the result (or an indication of any exception that occurred) in a reply message. The challenge, then, is created by failures. Were it not for the possibility of process and machine crashes, an RPC protocol capable of overcomi...
Structure and encapsulation in distributed systems: the proxy principle
- Proc. 6th IEEE Int. Conf. on Distributed Computing Systems
, 1986
"... We present a novel view of the structuring of distributed systems, and a few examples of its utilization in an object-oriented context. In a distributed system, the structure of a service or subsystem may be complex, being implemented as a set of communicating server objects; however, this complexit ..."
Abstract
-
Cited by 228 (9 self)
- Add to MetaCart
We present a novel view of the structuring of distributed systems, and a few examples of its utilization in an object-oriented context. In a distributed system, the structure of a service or subsystem may be complex, being implemented as a set of communicating server objects; however, this complexity of structure should not be apparent to the client. In our proposal, a client must first acquire a local object, called a proxy, in order to use such a service. The proxy represents the whole set of servers. The client directs all its communication to the proxy. The proxy, and all the objects it represents, collectively form one distributed object, which is not decomposable by the client. Any higher-level communication protocols are internal to this distributed object. Such a view provides a powerful structuring framework for distributed systems; it can be implemented cheaply without sacrificing much flexibility. It subsumes may previous proposals, but encourages better information-hiding and encapsulation. 1
Object Structure in the Emerald System
- OOPSLA'S6 Conference Proceedings, 29 September
, 1986
"... Emerald is an object.based language for the construction of distributed applications. The principal features of Emerald lnehtde a uniform object model appropriate for programming both private local objects and shared remote objects, and a type system that permits multiple user.defined and compiler-d ..."
Abstract
-
Cited by 167 (12 self)
- Add to MetaCart
(Show Context)
Emerald is an object.based language for the construction of distributed applications. The principal features of Emerald lnehtde a uniform object model appropriate for programming both private local objects and shared remote objects, and a type system that permits multiple user.defined and compiler-defined implementations. Emerald objects are fully mobile and can move from node to node within the network, even during an invocation. This paper discusses the structure, programming, and inq~lementation of Emerald objects, and Emerald's use of abstract types. 1.
Sender-based message logging
"... Sender-based message logging is a new low-overhead mechanism for providing transparent fault-tolerance in distributed systems. It differs from conventional message logging mechanisms in that each message is logged in volatile memory on the machine from which the message is sent. Keeping the message ..."
Abstract
-
Cited by 159 (12 self)
- Add to MetaCart
(Show Context)
Sender-based message logging is a new low-overhead mechanism for providing transparent fault-tolerance in distributed systems. It differs from conventional message logging mechanisms in that each message is logged in volatile memory on the machine from which the message is sent. Keeping the message log in the sender's local memory allows us to recover from a single failure at a time without the expense of synchronously logging each message to stable storage. The message log is then asynchronously written to stable storage, without delaying the computation, as part of the sender's periodic checkpoint. Maintaining the sender-based message log requires at most one extra network packet over non-fault-tolerant reliable message communication and imposes little additional synchronization delay. It can be applied transparently to existing distributed applications and does not require specialized hardware. It is currently being implemented on a network of SUN workstations.
Dynamic Configuration for Distributed Systems
- Department of Computer Science, Cornell University, Upson Hall
, 1985
"... Abstract-Dynamic system configuration is the ability to modify and extend a system while it is running. The facility is a requirement in large distributed systems where it may not be possible or economic to stop the entire system to allow modification to part of its hardware or software. It is also ..."
Abstract
-
Cited by 153 (18 self)
- Add to MetaCart
(Show Context)
Abstract-Dynamic system configuration is the ability to modify and extend a system while it is running. The facility is a requirement in large distributed systems where it may not be possible or economic to stop the entire system to allow modification to part of its hardware or software. It is also useful during production of the system to aid incre-mental integration of component parts, and during operation to aid system evolution. The paper introduces a model of the configuration process which permits dynamic incremental modification and exten-sion. Using this model we determine the properties required by lan-guages and their execution environments to support dynamic configura-tion. CONIC, the distributed system which has been developed at Imperial College with the specific objective of supporting dynamic configuration, is described to illustrate the feasibility of the model. Index Terms-Configuration, configuration process, configuration specification, distributed systems, flexibility, reusability, system evolution.
Separation of concerns
, 1995
"... This paper identifies and analyzes the emergence of a new paradigm in software engineering, called separation of concerns, which tries to formally separate the basic algorithm from special purpose concerns such as synchronization, real-time constraints, and location control. This separation allows f ..."
Abstract
-
Cited by 128 (1 self)
- Add to MetaCart
(Show Context)
This paper identifies and analyzes the emergence of a new paradigm in software engineering, called separation of concerns, which tries to formally separate the basic algorithm from special purpose concerns such as synchronization, real-time constraints, and location control. This separation allows for the locality of different kinds of information in the programs, making them easier to write, understand, reuse, and modify. We identify the major concerns existing in today's software applications, and analyze recent proposals in the literature that address separation of single concerns. Furthermore, we study the commonalities of these proposals and discuss how they can be used to achieve separation of concerns in general. Finally, we address the problem of composition of several separated concerns.
Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control
, 2006
"... Permission is hereby granted to make and distribute verbatim copies of this document without royalty or fee. Permission is granted to quote excerpts from this documented provided the original source is properly cited. ii When separately written programs are composed so that they may cooperate, they ..."
Abstract
-
Cited by 124 (11 self)
- Add to MetaCart
(Show Context)
Permission is hereby granted to make and distribute verbatim copies of this document without royalty or fee. Permission is granted to quote excerpts from this documented provided the original source is properly cited. ii When separately written programs are composed so that they may cooperate, they may instead destructively interfere in unanticipated ways. These hazards limit the scale and functionality of the software systems we can successfully compose. This dissertation presents a framework for enabling those interactions between components needed for the cooperation we intend, while minimizing the hazards of destructive interference. Great progress on the composition problem has been made within the object paradigm, chiefly in the context of sequential, single-machine programming among benign components. We show how to extend this success to support robust composition of concurrent and potentially malicious components distributed over potentially malicious machines. We present E, a distributed, persistent, secure programming language, and CapDesk, a virus-safe desktop built in E, as embodiments of the techniques we explain.
