M. Schroeder and M. Burrows: Performance of Firefly RPC. ACM Transactions on Computer Systems 8, 1-17 (1990)  Home/Search   Document Not in Database   Summary   Related Articles   Check

....is based on the assumption that the applications can tolerate some inconsistency and reconciliation methods should be available to resolve conflicts. Typical applications that have used weak consistency are Internet news, air traffic control, airline reservation and stock exchanges. Grapevine [SBN84] and the Global Name Service [Lam86] were among the first systems to use weak consistency. Other weak consistency protocols were presented in [DGH 87, DGP90, Gol92, LLS90, QP93, WB84] These protocols are useful and interesting; however, they require a node to communicate with all other nodes. ....

M. Schroeder, A. Birrell, and R. Needham. Experience with Grapevine. ACM Transactions on Computer Systems, 2(1), February 1984.

....300 200 400 600 800 1000 0 100 200 300 200 400 600 800 1000 Round Trip Time (ms) Maxima Means Minima Time (Sample Group Number) Webster sample, ping layer, raw data, filtered at 1000 ms threshold. Figure 7: Comparison of Minima, Means, and Maxima ratory experiments (such as [15]) In a laboratory, all the external interference is eliminated to yield consistently reproducible results. This process yields the minima as the final result. In our measurements, we cannot eliminate the external interference, but the minima approximates the situation since they show the least ....

....of traffic and reliability of nodes connected to WAINs. However, unlike LR, these studies do not attempt to measure the response time of applications running across WAINs since they are studying the network as a conduit for packets. 6. 2 LAN Protocol Measurements A study of the Firefly RPC [15] is similar in objective to LR since it measures the end to end performance over a LAN. However, unlike LR, this work measures only RPC in a controlled environment. The goal of LR is to simultaneously measure layers such as application, RPC and network to build an overall profile of end to end ....

M. Schroeder and M. Burrows. Performance of Firefly RPC. ACM Transactions on Computer Systems, 8(1):1--17, February 1990.

....an abstract execution trace of a call to rmin. 1 Performance of RPC Communication using the RPC paradigm is at the root of many distributed systems. As such, the performance of this component is critical. As a result, a lot of research has been carried out on the optimization of this paradigm [32, 6, 17, 36, 15, 26]. Many studies have been carried out, but they often result in using new protocols that are incompatible with an existing standard such as the Sun RPC. The problem in reimplementing a protocol that is specified only by its implementation is that features (and even bugs) may be lost, resulting in ....

....such as specific RPC optimizations, kernel level optimizations, operating system structuring, and automatic program transformation. Let us outline the salient aspects of these research directions. General RPC optimizations. A considerable amount of work has been dedicated to optimize RPC (see [32, 17, 36, 25, 24]) In most of these studies, a fast path in the RPC is identified, corresponding to a performance critical, frequently used case. The fast path is then optimized using a wide range of techniques. The optimizations address different layers of the protocol stack, and are performed either manually ....

M.D. Schroeder and M. Burrows. Performance of Firefly RPC. ACM Transactions on Computer Systems, 8(1):1-- 17, February 1990.

....take full advantage of SHRIMP s features. The result is a round trip null RPC latency of 9.5 microseconds, which is about one microsecond above the hardware minimum. 2 1 Introduction Much is known about how to optimize remote procedure call (RPC) mechanisms on traditional workstation networks[2, 14, 17, 20]. The main effort in previous work was to reduce or avoid copying, to make traps and context switches fast, and to take advantage of common case behavior. The emergence of new multiprocessor network interfaces opens new possibilities for constructing network software. It is not always clear, ....

....[21] approach allows an arbitrary handler to be invoked, using a fast path implementation but switching to a slower path if the handler blocks. Neither of these systems provides full RPC services, such as automatic stub generation or binding between untrusting parties. Several papers (e.g. [14, 17]) describe optimizations that dramatically improve the performance of RPC in traditional systems. This is generally done by avoiding copying, and reducing context switching overhead and network and RPC protocol overhead. 9 Discussion and conclusions Network interfaces can have a great impact on ....

M. Schroeder, and M. Burrows. Performance of Firefly RPC. ACM Transactions on Computer Systems 8(1):1-- 17, Feb. 1990.

....a remote procedure look like a local one. A call to this procedure is done transparently on the local machine but the actual computation takes place on a distant machine. Performance is a key point in RPC. A lot of research has been carried out on the optimization of the layers of the protocol [23, 5, 16, 24, 14, 18]. Many studies have been proposed, but they necessitate the use of new protocols, incompatible with existing standard such as Sun RPC. The high genericity of the RPC implementation is an invitation to specialization. Our group is currently developing a partial evaluator for C, named Tempo [7] It ....

....which belong to the operating system s interface. This makes it impossible to separately specialize an application module, and, in particular, our XDR example. General RPC Optimizations. A considerable amount of work has been dedicated to optimize existing RPC implementations (see for example [23, 16, 24]) In these studies, a fast path in the RPC is identified, corresponding to a performance critical, frequently used case. The fast path is then optimized using a wide range of techniques. Some of these consist of manual optimizations on a specific layer of the RPC protocol stack. Our approach aims ....

M.D. Schroeder and M. Burrows. Performance of Firefly RPC. ACM Transactions on Computer Systems, 8(1):1--17, February 1990.

....of reducing software protocol overhead. Researchers have explored several approaches for reducing the cost of messaging layers. While substantial progress has been made, much of it has been made at the cost of reducing functionality. For example, techniques for speeding interprocess communication [1, 21] have resorted to lower level (and more risky) communication primitives to achieve high performance. In parallel systems, a number of reduced messaging layers have also been developed. In fact, active messages, the basis for our study, is one such reduced layer. The lowest level primitive ....

M. D. Schroeder and M. Burrows. Performance of Firefly RPC. ACM Transactions on Computer Systems, 8(1):1--17, February 1990.

....but it can be found in [9] The set of parameters that describe the model elements are provided in Table 1. The ff Rel i factor indicates the fraction of the server relation i that is cached in every client disk manager. Both clients and servers spent time for processing the critical path of RPCs [21, 5] in their Network Proc: Modules(NPM ) Table 2 shows some additional parameters used in the models of this section. The net proc parameter accounts for the extra CPU penalties that take place at the NPM processing elements. DBMS Operational Aspects V alue page size 2KBytes srv cpu mips 41 MIPS ....

M. Schroeder and M. Burrows. Performance of Firefly RPC. ACM--Transactions on Computer Systems, 8(1):1--17, February 1990.

....for implementing widespread distributed services such as NFS [32] and NIS [29] The RPC implementation used in this paper is the commercial, 1984 copyrighted version of Sun. Performance is a key point in RPC. A lot of research has been carried out on the optimization of the layers of the protocol [3,15,24,30,33]. However, many of these optimizations involve new protocols that are incompatible with an existing standard such as the Sun RPC. 2.1 RPC Main Features The RPC protocol makes a remote procedure look like a local one. A call to a remote procedure is done transparently on the local machine, but the ....

M.D. Schroeder and M. Burrows. Performance of Firefly RPC. ACM Transactions on Computer Systems, 8(1):1--17, February 1990.

....Many existing kernels have been built using either the interrupt or the process model internally: for example, most Unix systems use the process model exclusively, whereas QNX [19] the Cache Kenrel, and the exokernels use the interrupt model exclusively. Other systems such as Firefly s Taos [25, 28] were designed with a hybrid model where threads often give up their kernel stacks in particular situations but can retain them as needed to simplify the kernel s implementation. Minix [30] used kernel threads to run process model kernel activities such as device driver code, even though the ....

M. Schroeder and M. Burrows. Performance of Firefly RPC. ACM Transactions on Computer Systems, 8(1):1--17, Feb. 1990.

....procedure call (RPC) Birrell Nelson 1984] In RPC, a server process exports an interface to one of its procedures; any client process can then bind to the procedure as if it was linked directly into the client. Local RPC has been extensively studied [Bershad et al. 1990, Bershad et al. 1991, Schroeder Burrows 1990] and seems to be the most convenient communication paradigm for integrating software systems across domains. Druschel and Peterson optimized their RPC system mainly for data throughput; we feel that this goal has been achieved, and optimize our anonymous RPC system ARPC for round trip ....

....find comparable performance figures for other RPC systems, since we do not know of any other optimized local RPC results on the same architecture. Instead, Table 2 compares our performance to that of four other RPC implementations running on other hardware: Mach RPC [Bershad et al. 1992] SRC RPC [Schroeder Burrows 1990], LRPC [Bershad et al. 1990] and URPC [Bershad et al. 1991] These are all optimized RPC implementations; commercial RPC implementations are frequently another order of magnitude slower. 7 Related Work The most closely related work to ours is Druschel and Peterson s fbufs, packet buffers mapped ....

Schroeder, M. and Burrows, M. Performance of Firefly RPC. ACM Transactions on Computer Systems, 8(1):1--17, February 1990.

....is based on the assumption that the applications can tolerate some inconsistency and reconciliation methods should be available to resolve conflicts. Typical applications that have used weak consistency are internet news, air traffic control, air line reservation and stock exchanges. Grapevine [SBN84] and the Global Name Service [Lam86] were among the first systems to use weak consistency. Other weak consistency protocols were presented in [DGH 87, DGP90b, Gol92, LLS90, QP93, WB84] However, these protocols assumed that any node could communicate with any other node. This assumption, ....

....The flooding approach suffers from incurring a large number of messages and lots of redundancy which causes waste in network bandwidth. The second approach is based on probabilistic techniques and has been used by most of the previous weak consistency protocols [DGH 87, DGP90b, Gol92, LLS90, SBN84, QP93] These schemes rely on delayed propagation, where nodes exchange status and new messages periodically in sessions. Partners in these sessions are selected to include either all nodes or a subset of nodes drawn from a probabilistic function (e.g. randomly or such that communication distance ....

[Article contains additional citation context not shown here]

M. Schroeder, A. Birrell, and R. Needham. Experience with Grapevine. ACM Transactions on Computer Systems, 2(1), February 1984.

....is available, the client need only make one remote procedure call. Generic services can be combined to implement the high level service a client needs. But in this case, the number of remote procedure calls increases. Since RPC usually performs 60 to 100 times slower than local procedure calls [SB90, BN84] it is desirable to keep the number of remote procedure calls low. Even if a cross domain RPC is required to invoke a service, the difference between a cross domain and a cross machine RPC can be substantial [BALL90] Remote evaluation (REV) Sta86, SG90] is an extension to the RPC model. ....

....appendix C.7) This agent simply reads the briefcase from stdin (a pipe) and unarchives it. It then calls a null routine before it archives the briefcase and writes it stdout (a pipe or file) see section 4.4, below. This is comparable with the null procedure call commonly used to test RPC [BN84, SB90] The same agent, ag nop is used as the argument of the rexec( call. Pseudo code for the test loop of the synchronous rexec( is given in figure 4.3, and the asynchronous variation in figure 4.4. 4.3.2 Results The results of these experiments are plotted in 4 graphs, displayed in figure 4.5 ....

[Article contains additional citation context not shown here]

M. D. Schroeder and M. Burrows. Performance of Firefly RPC. ACM Transactions on Computer Systems, 8(1):1--17, February 1990.

....for a null RPC with no arguments or return values between two user level threads executing on separate Sun 3 60 workstations on the Ethernet is 573 microseconds. This time compares well with the fastest null network RPC times reported in the literature, ranging from about 1100 to 2600 microseconds [3, 12, 8, 15, 17, 19], and is only 309 microseconds above the measured hardware latency defined by the network penalty for the call and result packets in our environment. A null RPC with a single 1 kilobyte argument requires 1397 microseconds, showing an increase over the time for null RPC with no arguments of just ....

....prototypes. Procedure arguments may be of any data type. Individual arguments may be either immediate data values or pointers to data values. Pointer arguments may optionally be declared in one of three ways, depending on whether the data value must be passed on the call, the return, or both [15]: ffl An in pointer argument describes a data value that must be passed on the call, but need not be passed back on the return. ffl An out pointer argument describes a data value that must be passed on the return, but need not be passed on the call. ffl An in out pointer argument describes a data ....

[Article contains additional citation context not shown here]

M.D. Schroeder and M. Burrows. Performance of Firefly RPC. ACM Transactions on Computer Systems, 8(1):1--17, February 1990.

....the writing of distributed programs. With RPC, a request for service from a client to a server process is structured to give synchronization semantics at the client similar to normal procedure call. Numerous examples of different RPC services and implementations exist, including Firefly RPC [SB90] Alphorn [AGH 91] lightweight RPC [BALL90] Peregrine [JZ93] and SUPRA RPC [Sto94] Among the commercial RPC packages released have been Courier from Xerox [Xer81] Sun RPC [Sun88] Netwise RPC from Novell Netware, NCA from Apollo [Apo89] and DCE RPC. On the surface, the semantics of RPC ....

....we deal exclusively here with these aspects of RPC. Other issues, although important, are beyond the scope of this paper. These include stub generation and heterogeneity [Sun88, Gib87, HS87, Apo89, TB90, WSG91] binding [BN84, LT91, BALL90] performance or performance optimizations, PA88, RST89, SB90, BALL90] and security issues [Bir85] 2 Properties of RPC Services 2.1 Point to point RPC The properties of RPC can be classified into categories as follows. ffl Failure semantics specify what guarantees are given to the client about the execution of the server procedure, both when the call ....

M. Schroeder and M. Burrows. Performance of Firefly RPC. ACM Transactions on Computer Systems, 6(1):1--17, Feb 1990.

....are air traffic control [16] resource discovery systems e.g. archie [9] stock exchanges and so on. In this paper we describe a propagation protocol for managing replicated data asynchronously. This method is especially suited for the bulletin board application mentioned above. Grapevine [17] and the Global Name Service [15] were among the first systems to use weak consistency. Other weak consistency protocols were presented in [7, 8, 12, 14, 16, 18] These protocols are useful and interesting; however, they require a node to send messages to all other nodes. This would be acceptable ....

M. Schroeder, A. Birrell, and R. Needham. Experience with Grapevine. ACM Transactions on Computer Systems, 2(1), February 1984.

....a null RPC with no arguments or return values between two user level threads executing on separate Sun 3 60 workstations on the Ethernet is 573 microseconds. This time compares well with the fastest null network RPC times reported in the literature, ranging from about 1100 to 2600 microseconds [3, 12, 8, 15, 17, 19], and is only 309 microseconds above the measured hardware latency defined by the network penalty for the call and result packets in our environment. A null RPC with a single 1 kilobyte argument requires 1397 microseconds, showing an increase over the time for null RPC with no arguments of just ....

....prototypes. Procedure arguments may be of any data type. Individual arguments may be either immediate data values or pointers to data values. Pointer arguments may optionally be declared in one of three ways, depending on whether the data value must be passed on the call, the return, or both [15]: ffl An in pointer argument describes a data value that must be passed on the call, but need not be passed back on the return. ffl An out pointer argument describes a data value that must be passed on the return, but need not be passed on the call. ffl An in out pointer argument describes a ....

[Article contains additional citation context not shown here]

M.D. Schroeder and M. Burrows. Performance of Firefly RPC. ACM Transactions on Computer Systems, 8(1):1--17, February 1990.

....to take full advantage of SHRIMP s features. The result is a round trip null RPC latency of 9.5 microseconds, which is about one microsecond above the hardware minimum. 1 Introduction Much is known about how to optimize remote procedure call (RPC) mechanisms on traditional workstation networks[2, 14, 17, 21]. The main effort in previous work was to reduce or avoid copying, to make traps and context switches fast, and to take advantage of common case behavior. The emergence of new multiprocessor network interfaces opens new possibilities for constructing network software. It is not always clear, ....

....uses long, obscure identifier names to avoid name collisions. 0 200 400 600 800 1000 Argument Size (bytes) 0 50 100 150 Roundtrip Time (microseconds) Optimized vRPC ShrimpRPC Figure 8: Round trip time for null RPC, with a single INOUT argument of varying size. STRUCT thingy int a; float b[17]; PROCEDURE add(IN int x, IN int y, OUT int sum) PROCEDURE myproc(IN thingy q) The stub generator creates an include file that contains the data structure definition shown in Figure 9. The client side stub is shown in Figure 10. The stub first copies the arguments into the RPC buffer, and sets a ....

[Article contains additional citation context not shown here]

M. Schroeder, and M. Burrows. Performance of Firefly RPC. ACM Transactions on Computer Systems 8(1):1--17, Feb. 1990.

....communication mechanism that passes typed data objects among address spaces. Subsystems present themselves to one another in terms of interfaces implemented by servers. The absence of a single, uniform address space is compensated by automatic stub compilers and sophisticated runtime libraries [180, 110, 207] that transfer complex arguments in messages. RPC systems require that the data passed among cooperating modules be strongly typed; within a module, a programmer is free to mix languages, use weakly typed or untyped languages, violate typing if needed, and execute code for which source is not ....

M. Schroeder and M. Burrows. Performance of firefly rpc. ACM Transactions on Computer Systems, 8(1):1--17, February 1990.

.... for clock synchronization under different failure scenarios are also known [ST87] Algorithms The problem of clock synchronization has been studied extensively, and a large number of algorithms proposed [Cri89, HSSD84, KO87, LMS85, LWL88, ST87] A survey of some of these algorithms appears in [RSB90] These algorithms differ from each other in their assumptions about the clocks and the network topology, as well as their failure hypothesis. The mechanics of clock synchronization involves periodically exchanging information about local clock values and then computing a correction factor and ....

....the minimum and the maximum message transit times. The hardware approaches provide a smaller clock skew, but are expensive and inflexible. Some of the algorithms use a combination of hardware and software, where the smaller skew of the hardware algorithms is sacrificed for a lower software cost [RSB90] Most of the software approaches use a convergence function that guarantees the properties of monotonicity, precision and interval preservation. One class of algorithms consists of first exchanging local clock values and then applying a fault tolerant averaging function to these values to ....

[Article contains additional citation context not shown here]

M. Schroeder and M. Burrows. Performance of Firefly RPC. ACM Transactions on Computer Systems, 6(1):1--17, Feb 1990.

....to combine separate system calls into a single system call. Other Work Research in the area of remote procedure call has used virtual memory services to help move data. The DEC Firefly RPC system used a permanently mapped unprotected area of memory shared across all processes to pass RPC data [61] and provide low latency. The LRPC and URPC systems copy data into memory statically shared between the client and the server [5, 6] The DASH IPC mechanism used a reserved area of virtual space in processes to exchange IPC data through page remapping [67] The Peregrine IPC system used ....

M. Schroeder and M. Burrows. The performance of Firefly RPC. ACM Transactions on Computer Systems, 8(1):1--17, February 1990.

....data units from the sending domain and maps them into the receiving domain. Virtual copying (copy on write) 8] shares the transferred pages among the sending and receiving domain, and delays copying until one of the sharing domains attempts to write the shared data unit. Shared virtual memory [13] employs buffers that are statically shared among two or more domains to avoid data transfers. Virtual page remapping has move rather than copy semantics, which limits its utility to situations where the sender needs no further access to the transferred data. Virtual copying has copy semantics, ....

M. D. Schroeder and M. Burrows. Performance of firefly RPC. ACM Transactions on Computer Systems, 8(1):1--17, Feb. 1990.

....the functions of the session layer. As with the OSI ISO model, the presentation layer of the RPC mechanism performs no multiplexing. Security A number of mechanisms for secure and authenticated RPC, based on both public and private key encryption schemes, are to be found in the literature [Birrell 85] Birrell 87] All aim to distribute a key in a secure manner to both the client and server, which is then used as the key for some crypto system which is the basis of the security mechanism. The use of this key for more than one RPC, i.e. the use of some form of RPC session mechanism, is ....

A Birrell. Secure communications using RPC. ACM Transactions on Computer Systems, 3(1), February 1985. (69)

....of establishments. These systems have not, in general, been extended into heterogeneous, or wide area networks, as they present network requirements which cannot be met by current interconnection architectures. For example, distributing computing mechanisms, such as remote procedure call (RPC) Birrell 84] are sensitive to long round trip delays, while real time traffic requires constraints on the variation in delay, or jitter. In an internetwork, the largest source of delay and jitter is often the internetwork switching nodes, or routers. The architecture presented here addresses the issues ....

....aim is to utilize the underlying MSN architecture capabilities effectively, as well as obtain advantage from applying similar design techniques to the mechanisms present in these distributing computing components. The main distributed computing mechanism discussed is remote procedure call (RPC) Birrell 84] RPC is widely used in distributed computing, and when combined with tools for automatic stub generation and interface checking provides a 1 Adaptive schemes to overcome the problem of a bounded round trip time have been suggested, but these work by modification of future frames to compensate ....

A Birrell and G Nelson. Implementing RPC. ACM Transactions on Computer Systems, 2(1), February 1984. (2, 65)

....computing. Low latency and high throughput communication allow a much closer coupling of distributed systems than has been feasible in the past: with previous generation networks, the high cost of sending messages led programmers to carefully minimize the amount of net1 work communication [Schroeder Burrows 90] Further, when combined with today s faster processors, faster networks can enable a new set of applications, such as desktop multimedia and using a network of workstations as a supercomputer. A primary barrier to building high performance networks is the difficulty of high speed switching of ....

Schroeder, M. and Burrows, M. Performance of Firefly RPC. ACM Transactions on Computer Systems, 8(1):1--17, February 1990.

....designer. As an alternative to static generation of stubs, some projects have designed efficient remote evaluation mechanisms for heterogeneous applications. Distributed applications gain substantial performance improvements through the use of customized interface mechanisms like RPC or REV stubs [3, 14, 17, 6]. Stubs in these projects are often handwritten or rewritten from those generated automatically because their performance is critical in many systems and their design if often dependent upon the context of use in a configuration. In comparison, Polygen accommodates many of these approaches by ....

M. Schroeder and M. Burrows. Performance of the Firefly RPC, ACM Transactions on Computer Systems, vol. 16, (February 1990), pp. 1-17.

.... Bir85a, EL90, KGR91, MPS92] A time service provides consistent information about time in a distributed system, either in the form of logical or virtual time that can be used to reason about the relative order of events [Lam78, Sch82, 25 Mat89] or real time from synchronized clocks [KO87, WL88, RSB90, VR92] Other important service abstractions are atomic actions, a collection of operations whose execution is indivisible despite concurrency and failures [Lam81, Lis85, SDP89] and stable storage, storage whose contents is guaranteed to survive failures [Lam81, BY87] Paradigms for structuring ....

....the writing of distributed programs. With RPC, a request for service from a client to a server process is structured to give synchronization semantics at the client similar to normal procedure call. Numerous examples of different RPC services and implementations exist, including Firefly RPC [SB90] Alphorn [AGH 91] lightweight RPC [BALL90] Peregrine [JZ93] RSV94] and SUPRA RPC [Sto94] Among the commercial RPC packages released have been Courier from Xerox [Xer81] Sun RPC [Sun88] Netwise RPC from Novell Netware, and NCA from Apollo [Apo89] TA90] gives a survey of work in this ....

[Article contains additional citation context not shown here]

M. Schroeder and M. Burrows. Performance of Firefly RPC. ACM Transactions on Computer Systems, 6(1):1--17, Feb 1990.

....is based on the assumption that the applications can tolerate some inconsistency and reconciliation methods should be available to resolve conflicts. Typical applications that have used weak consistency are Internet news, air traffic control, airline reservation and stock exchanges. Grapevine [SBN84] and the Global Name Service [Lam86] were among the first systems to use weak consistency. Other weak consistency protocols were presented in [DGH 87, DGP90, Gol92, LLS90, QP93, WB84] These protocols are useful and interesting; however, they require a node to communicate with all other ....

M. Schroeder, A. Birrell, and R. Needham. Experience with Grapevine. ACM Transactions on Computer Systems, 2(1), February 1984.

....than once at network speeds. 2.2.2 Shared Memory Another approach is to statically share virtual memory among two or more domains, and to use this memory to transfer data. For example, the DEC Firefly RPC facility uses a pool of buffers that is globally and permanently shared among all domains [16]. Since all domains have read and write access permissions to the entire pool, protection and security are compromised. Data is copied between the shared buffer pool and an application s private memory. As another example, LRPC [2] uses argument stacks that are pairwise shared between ....

M. D. Schroeder and M. Burrows. Performance of Firefly RPC. ACM Transactions on Computer Systems, 8(1):1--17, Feb. 1990.

.... Lampson [Lampson et al. 74] described a generalized control transfer interface based on continuations for an early version of the Mesa programming language [Geschke et al. 77] A much restricted form of Lampson s interface later appeared in the cross address space RPC implementation for Topaz [Schroeder Burrows 90] an operating system designed for the Firefly, DEC SRC s experimental multiprocessor workstation [Thacker et al. 88] This interface, implemented in assembly language, does a stack handoff, but does not use recognition or take advantage of a shared stack context. SRC s RPC path is so heavily ....

Schroeder, M. D. and Burrows, M. Performance of Firefly RPC. ACM Transactions on Computer Systems, 8(1):1--17, February 1990.

....is based on the assumption that the applications can tolerate some inconsistency and reconciliation methods should be available to resolve conflicts. Typical applications that have used weak consistency are internet news, air traffic control, airline reservation and stock exchanges. Grapevine [10] and the Global Name Service [8] were among the first systems to use weak consistency. Other weak consistency protocols were presented in [2, 3, 5, 6, 9, 12] However, these protocols assumed that any node could communicate with any other node. This assumption, though appropriate for small ....

....that each node receives a message only once; hence, there is no redundancy and the network bandwidth is used efficiently. The mechanism relies on nodes sending messages immediately (immediate propagation) which increases the speed of propagation. In contrast, previous weak consistency protocols [2, 3, 5, 6, 10], relied on delayed propagation where nodes exchange new messages periodically. However, in order to achieve an acceptable speed of propagation they had to add an unreliable broadcast on top of the periodic updates which introduced a fair amount of redundancy causing an increase in the traffic on ....

M. Schroeder, A. Birrell, and R. Needham. Experience with Grapevine. ACM Transactions on Computer Systems, 2(1), February 1984.

....the writing of distributed programs. With RPC, a request for service from a client to a server process is structured to give synchronization semantics at the client similar to normal procedure call. Numerous examples of different RPC services and implementations exist, including Firefly RPC [19], Alphorn [3] lightweight RPC [4] and Peregrine [14] Among the commercial RPC packages released have been Courier from Xerox [24] Sun RPC [22] Netwise RPC from Novell Netware, and NCA from Apollo [2] On the surface, the semantics of RPC seem very simple, yet the reality is that there are ....

M. Schroeder andM. Burrows. Performance of Firefly RPC. ACM Transactions on Computer Systems, 6(1):1--17, Feb 1990.

No context found.

M. Schroeder and M. Burrows: Performance of Firefly RPC. ACM Transactions on Computer Systems 8, 1-17 (1990)

No context found.

Schroeder, M. and Burrows, M. Performance of Firefly RPC. ACM Transactions on Computer Systems, 8(1):1-17, February 1990.

No context found.

Schroeder, M. and Burrows, M. Performance of Firefly RPC. ACM Transactions on Computer Systems, 8(1):1--17, February 1990.

No context found.

Schroeder, M. D. and Burrows, M. Performance of Firefly RPC. ACM Transactions on Computer Systems, 8(1):1--17, February 1990.

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