B. Liskov, T. Bloom, D. Gifford, R. Scheifler and W. Wiehl, `Communication in the Mercury system', Proceedings of the Hawaii International Conference on System Sciences, Honolulu, Hawii, January 1988.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....Discuss could use any other protocol that provides the same functionality. Discuss clients and servers only deal with a set of meeting operations, which are available as ordinary procedure calls. Discuss could be implemented on other RPC mechanisms, such as Sun RPC, Apollo NCS, or the Mercury RPC[12], without much of a problem. Alternatively, the operations could be encoded in ASCII on a standard TCP stream, as SMTP[14] is. 6 Authentication and Authorization Many existing networked conferencing systems are explicitly insecure they make no guarantees about the integrity, confidentiality, or ....

B. Liskov et al. Communication in the Mercury System. In Proceedings of the 21st Annual Hawaii International Conference on System Sciences, pages 178--187, January 1988.

....space restrictions force us to limit such comparisons. We choose the multiple compatible language extensions to best satisfy the conflicting goals of accommodating legacies and hiding complexity. An entirely new language designed to support distributed computing (e.g. NIL [30] Argus [20], SR [2] Emerald [11] Hermes [29] a survey may be found in [8] can effectively and elegantly hide complexity for someone familiar with the language. However, such languages are, in general, poor at accommodating legacy code, and require new programmer skills. At the opposite extreme, ....

B. Liskov, T. Bloom, D. Gifford, R. Scheifler, and W. Weihl. Communication in the Mercury system. Proceedings of the 21st annual Hawaii International Conference on System Sciences, pages 178--187, January 1988.

....body, it is impossible to derive which statements access the results of a callee. Therefore, the programmer has to indicate a synchronization point after which he or she expects all results to be available. This conforms to the implementation of an asynchronous rpc suggested in the literature [22]. The program annotations introduced are explained in detail in the following: parallel This new keyword preceeds a function definition and simply tells the compiler that this function is intended to be executed in parallel. sync This newly introduced statement defines the synchronization point ....

B. LISKOV, T. BLOOM, D. GIFFORD, R. SCHEIFLER, W. WEIHL. Communication in the Mercury System. In Proceedings of the 21st Annual Hawaii Conference on System Sciences, 1988.

.... procedure call using a common backing store is given by Essick [6] Finally, the Durra system allows for some forms of dynamic reconfiguration within the Ada environment [3] while the Mercury system supports heterogeneity in applications by managing a networked object repository [13]. 6 CONCLUSION We have described a broad framework that organizes software reconfiguration activities, specifically within a distributed programming environment. In order to run experiments within this framework, we have constructed an execution environment containing a few, fundamental ....

B. Liskov, T. Bloom, D. Gifford, R. Scheifler, W. Weihl, "Communication in the Mercury System," Proceedings of the 21st Annual Hawaii Conference on System Sciences, pp. 178-187, 1988.

....software development environments. Some related work has been done at Carnegie Mellon University with the Matchmaker language [19] designed to support the construction of multi lingual interprocess communication interfaces, and at the Massachusetts Institute of Technology with the Mercury project [24, 16], which uses a value transmission method for abstract data types. 2.5.1 Matchmaker When supported by the capability based interprocess communications found in the Mach kernel [1] Matchmaker provides a heterogeneous, distributed, object oriented programming facility. Currently the Mach Matchmaker ....

B. H. Liskov, T. Bloom, D. Gifford, R. Scheifler, and W. Weihl. Communication in the mercury system. In Proceedings of the 21st Annual Hawaii Conference on System Sciences, pages 178--187. IEEE, January 1988.

....input to another node only upon completion. Results of the remote computation are passed on to other nodes rather than being returned to the invoker. Some notable systems where RPC has been employed to permit mixed language programmingand support for heterogeneous architectures include Mercury [36], MLP [30] and HRPC [12] 8.3 Graphical Programming Examples of systems that use graphical notations to express parallel computations include Fel [32] Poker [38] CODE [17] Alex [33] LGDF [6, 7] and apE [26] None of these systems addresses fault tolerance nor provides a programming ....

B. Liskov, et al. Communication in the Mercury System. In Proc. 21st Annual Hawaii Conference on System Sciences, January 1988.

....the sense of PROFIT, with objects implemented in C . SOS provides a mechanism for certain cases of dynamic reconfiguration in the form of dynamic classes, where all member functions are called via a dynamic table, but requires dynamic linking capabilities avoided by PROFIT. The Mercury system [Liskov 88] provides a general interprocess communication mechanism for heterogeneous systems. Servers are written independently of whether their application clients choose communication protocols to provide low latency or high throughput. The performance requirements of the application determines the ....

Barbara Liskov, Toby Bloom, David Gifford, Robert Scheifler and William Weihl. Communication in the Mercury System. In Bruce D. Shriver (editor), 21st Annual Hawaii International Conference on System Sciences, pages 178-187. IEEE Computer Society, Kona HI, January, 1988.

....directly on top of each individual operating system and programming language. Alternatively, for ease of portability, one might implement a coordination language on top of a uniform set of system level communication constructs for heterogeneous distributed systems. For example, the Mercury system [13] provides a remote procedure call facility that spans multiple programming languages and operating systems. Each supported programming language is extended with a thin layer or veneer between the application program and the operating system. If one were to implement a coordination language on ....

B. Liskov, T. Bloom, D. Gifford, R. Scheifler, and W. Weihl. Communication in the Mercury system. In Hawaii International Conference on System Sciences, pages 178--187, January 1988.

....system. This lack of flexibility portability and the sparse usage of Mach make Matchmaker unsuitable as a solution to the interoperability needs of most contemporary software development environments. 6. 5 Mercury The work done at MIT on a value transmission method for abstract data types [10, 5] was designed to support communicating abstract data types that are interoperable between regions of a system using di#erent data value representations. This method defines call by value semantics for communicating values over a network of di#erent computers. A canonical representation for each ....

B. H. Liskov, T. Bloom, D. Gi#ord, R. Scheifler, and W. Weihl. Communication in the mercury system. In Proceedings of the 21st Annual Hawaii Conference on System Sciences, pages 178--187. IEEE, January 1988.

....in our case any local subenvironment can play the role of the Configuration Manager. Wei and Endler [27] describe another port based facility similar to Conic, where change scripts consisting of condition action rules can, for example, delete components and place components on hosts. Mercury [16] provides a general interprocess com munication mechanism for heterogeneous systems. Servers are written independently of whether their application clients choose communication protocols to provide low latency or high throughput. The performance requirements of the application determines the ....

Barbara Liskov, Toby Bloom, David Gifford, Robert Scheifler, and William Weihl. Communication in the Mercury system. In Bruce D. Shriver, editor, 21st Annual Hawaii International Conference on System Sciences, volume II Software Track, pages 178--187, Kona HI, January 1988. IEEE Computer Society Press.

....another node only upon completion. Results of the remote computation are passed on to other nodes rather than being returned to the invoker. Some notable systems where RPC has been employed to permit mixed language programming and support for heterogeneous architectures include Horus [25] Mercury [35], MLP [27] and HRPC [9] 8.3 Graphical Programming Examples of systems that use graphical notations to express parallel computations include Fel [30] Poker [37] CODE [14] Alex [32] LGDF [6] and apE [22] None of these systems addresses fault tolerance nor provides a programming environment ....

B. Liskov, et al. Communication in the Mercury System. In Proc. Twenty-first Annual Hawaii Conference on System Sciences, January 1988.

.... languages can be implemented directly on top of each supported operating system and programming language, or for ease of portability, they may be implemented on top of a uniform set of system level communication constructs for heterogeneous distributed systems, such as the Mercury system [19] or PVM [9] Communication: Having implicit communication means that the programmer need not think about when to initiate communication. Communication occurs as a byproduct of computation. In the message passing model, communication is inherently explicit (sends and receives) For dataflow, the ....

B. Liskov, T. Bloom, D. Gifford, R. Scheifler, and W. Weihl. Communication in the Mercury system. In Hawaii International Conference on System Sciences, pages 178--187, January 1988.

....a single application is composed of components using different models. 2. Related Work Multi model programming is related to, but distinct from, the work of several other researchers. Remote procedure call systems have often been designed to work between programs written in multiple languages [5, 14, 16, 20]. RPC based systems support a single style of process interaction, and are usually intended for a distributed environment; there is no obvious way to extend them to fine grained process interactions. Synchronization is supported only via client server rendezvous, and even the most efficient ....

B. Liskov, R. Bloom, D. Gifford, R. Scheifler and W. Weihl, "Communication in the Mercury System," Proceedings of the 21st Annual Hawaii International Conference on System Sciences, January 1988, pp. 178187.

....replicas gossip with all other replicas. Communication between the front end and the replicas can be made more efficient by taking advantage of the fact that a front end typically communicates with the same replica. Communication could be done over a streaming connection such as TCP or Mercury [24]. In this case, the front end need not wait to receive the uid timestamp from an update it requested before sending the next operation (query or update) to the replica. Instead, the replica maintains a copy of the front end s timestamp, into which it merges uids of updates as they complete. ....

....the front end cannot send on a message from its client to another client until it knows the timestamp for the most recent update requested by its client. A further optimization is possible when using streaming: operations from the front end can be batched if they are small. Mercury streams [24] do this automatically. A message would be sent from the front end when the client does a query, when the buffer is full, or when its client is sending a message to another client. This technique will cause an additional delay only in the latter case; the front end may need to flush the stream ....

Liskov, B., Bloom, T., Gifford, D., Scheifler, R., and Weihl, W. Communication in the Mercury System. Proc. of the 21st Annual Hawaii Conference on System Sciences, IEEE, January, 1988, pp. 178-187.

....client and the FE to share a single address space. Since inter process calls are usually fairly expensive, it would be good to avoid them by bundling several calls together. We are investigating ways of making such combined operations [ our approach is based partly on the promises of Mercury[18], and partly on the work of Stamos[ FE OR fetch (oref) commit (new objs, mod objects, read objs) ping ( end session ( trim fe table (array[oref] invalidate (xref) block new objs info must abort lease call returns signals failed Figure 3: The FE OR interface 3.2 Implementation of the ....

B. Liskov, T. Bloom, D. Gifford, R. Scheifler, and W. Weihl. Communication in the mercury system. In Proc. of the 21st Annual Hawaii Conference on System Sciences, pages 178--187. IEEE, January 1988.

No context found.

Liskov B., T. Bloom, D. Gifford, R. Scheifler, W. Weihl. (1988a) Communication in the Mercury System. In Proceedings of the 21st Hawaii International Conference on System Sciences, pages 178--187.

No context found.

B. Liskov, T. Bloom, D. Gifford, R. Scheifler and W. Wiehl, `Communication in the Mercury system', Proceedings of the Hawaii International Conference on System Sciences, Honolulu, Hawii, January 1988.

No context found.

Barbara Liskov, Toby Bloom, David Gifford, Robert Scheifler, and William Weihl. Communication in the Mercury system. In Proc. Hawaii Conference on System Sciences, pages 178--187. IEEE, January 1988.

No context found.

Barbara Liskov, Toby Bloom, David Gifford, Robert Scheifler, and William Weihl. Communication in the Mercury system. In Proc. Hawaii Conference on System Sciences, pages 178--187. IEEE, January 1988.

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