--------------------------------------------------- Return-Path: ddion@june Received: from june.cs.washington.edu (june.cs.washington.edu [128.95.2.4]) by whistler.cs.washington.edu (8.8.3/7.2ws+) with ESMTP id OAA00173 for ; Mon, 27 Jan 1997 14:00:18 -0800 Received: (ddion@localhost) by june.cs.washington.edu (8.8.5+CS/7.2ju) id OAA02246; Mon, 27 Jan 1997 14:00:17 -0800 From: ddion@june (David Dion) Message-Id: <199701272200.OAA02246@june.cs.washington.edu> Subject: NetworkObjects 552-reading summary To: bershad@cs Date: Mon, 27 Jan 1997 14:00:16 -0800 (PST) Cc: ddion@june (David Dion) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Distributed systems are inherently object-oriented. In true object oriented programming, an object's state is inaccessbile except through object methods, which are convenient places to insert communication. Network objects are objects whose methods can be invoked across a network. Remote invocation occurs by means of a client-side surrogate object. When a client obtains a reference to a network object, stub code selects a surrogate object, which is a subtype of the network object. The surrogate object overrides the network object methods, converting them into RPCs. In this manner, the stubs and communication are hidden from the programmer. The surrogate selection is based on the narrowest surrogate rule: the surrogate will have the most specific type of all surrogate types that are consistent with the type of the object on the owner and for which stubs are available in the client and in the owner. Two interesting aspects of the DEC SRC network object implementation are distributed garbage collection and marshalling. Distributed GC, based on reference counting, is supported by surrogate objects. When a client receives a network object, the surrogate sends a GC ref message to the owner. When the local surrogate is abandoned and hence collected, it sends a GC unref message to the owner. The owner's object is collected when there are no remaining local references or remote surrogate references. Marshalling with network objects can take two forms. Network objects are typically marshalled by reference, as described above. Other datatypes are marshalled by pickling, a clever way of copying the data. Arbitrarily complex datatypes may be pickled, though the programmer is responsible for breaking cyclical data structures. If the default pickle mechanism is unsatisfactory, client applications can specify custom marshalling procedures. The performance of network objects is satisfactory in some cases, but not remarkably fast. The base case, a null call, is twice as slow as a round-trip TCP message. Complex cases, such as those involving a GC ref call, are quite a bit slower. However, the authors claim that these numbers reflect little effort at optimization, and with study equivalent to that of RPC, these basic operations can become competitive. --------------------------------------------------- Return-Path: yasushi@silk Received: from silk.cs.washington.edu (silk.cs.washington.edu [128.95.2.238]) by whistler.cs.washington.edu (8.8.3/7.2ws+) with ESMTP id VAA05379 for ; Mon, 27 Jan 1997 21:02:13 -0800 Received: (yasushi@localhost) by silk.cs.washington.edu (8.7.2/7.2ws+) id VAA12539; Mon, 27 Jan 1997 21:02:13 -0800 (PST) Date: Mon, 27 Jan 1997 21:02:13 -0800 (PST) From: yasushi@silk Message-Id: <199701280502.VAA12539@silk.cs.washington.edu> To: bershad@silk Subject: NetworkObjects 552-reading summary Network objects is an object oriented RPC system. It is tightly integrated with Modula-3, and especially it uses the run-time type identification mechanism and GC mechanism cleverly to make the system almost transparent to the programmer. Modula-3 provides a way to access the internal structure of any data types at runtime. A library called pickle is provided to marshall and unmarshall any data structure without using a IDL compiler. If the programmer is unsatisfied with the default pickle behavior, he can provide his own pickler. The benefit of GC comes in two forms. First is that the client or server doesn't have to manually free the input arguments that are constructed on heap. The other is that remote reference are maintained automatically by Netobject runtime, thus the programmer doesn't have to care when an object becomes reclaimable. The latter mechanism is tricky, and netobject takes great care not to lose any live objects. One small problem is that the this remote reference mechanism can't collect network-wide cycle of objects, but I think it's a reasonable compromise. --------------------------------------------------- Return-Path: sparekh@crocus Received: from crocus.cs.washington.edu (crocus.cs.washington.edu [128.95.1.67]) by whistler.cs.washington.edu (8.8.3/7.2ws+) with SMTP id XAA06702 for ; Mon, 27 Jan 1997 23:24:04 -0800 Received: (sparekh@localhost) by crocus.cs.washington.edu (8.6.12/7.2ws+) id XAA03301; Mon, 27 Jan 1997 23:24:04 -0800 Date: Mon, 27 Jan 1997 23:24:04 -0800 Message-Id: <199701280724.XAA03301@crocus.cs.washington.edu> From: Sujay Parekh To: bershad@cs Subject: NetworkObjects 552-reading summary Network Objects is an alternative mechanism to RPC for programming distributed systems. By leveraging the natural modularity in object-oriented systems, it is able to integrate itself easily into such a system. Objects provide a nice abstraction and they also serve as convenient units of distribution. The strenghts and weaknesses of this system are best understood in relation to RPC, which it seeks to replace. The basic concept o a Network Object is one whose methods can be directly invoked from address spaces other than the one in which it was declared. They rely on some compiler support for maintaining type-correctness across address spaces. By relying on a strongly-typed object system and built-in garbage collection support, the Network Objects system provides automatic and efficient mechanisms (among them, pickling) for marshalling arguments of arbitrarily complex types for transmission over the network. In addition, there is a distributed garbage collection mechanism in place which work correctly (most of the time) in the presence of references to local objects from remote sites. Thus, it integrates well with the existing Modula-3 system, without placing an additional burden of learning a new programming paradigm on the programmer. At the same time, it is not completely transparent in that a programmer need to be aware that network errors may occur and be prepared to handle any exceptions that are caused by this. Setting up the distribution of objects is completely up to the programmer as well. The measured performance of some parts of their unoptimized implementation is generally within a factor of 2 of C code. Part of the overhead is due to extra Modula-3 runtime checks, and the usage of a not-so-good compiler. There is no comparison, however, with a comparable RPC-based system, so we have no idea if Network Objects, in practice, does lead to more efficient code. Arguably it is a nicer system to use in the case of an object-based language. --------------------------------------------------- Return-Path: rgrimm@cs.washington.edu Received: from june.cs.washington.edu (june.cs.washington.edu [128.95.2.4]) by whistler.cs.washington.edu (8.8.3/7.2ws+) with ESMTP id XAA06810 for ; Mon, 27 Jan 1997 23:34:33 -0800 Received: from [128.95.8.127] (h127.dyn.cs.washington.edu [128.95.8.127]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with SMTP id XAA12966 for ; Mon, 27 Jan 1997 23:34:28 -0800 X-Sender: rgrimm@june.cs.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Jan 1997 23:32:06 -0800 To: bershad@cs From: rgrimm@cs.washington.edu (Robert Grimm) Subject: NetworkObjects 552-reading summary Network objects, as introduced by Birrell et al., provide functionality that is similar to traditional RPC in several aspects: They allow for the remote invocation of code, use a programming language paradigm to model this invocation (invoking an object's method as opposed to calling a procedure in RPC), and provide a similar failure model (services are not automatically replicated and certain error conditions are signalled to the calling program). At the same time, network objects differ from traditional RPC due to several features: They provide a simpler interface to programmers by using an object oriented programming model and a clear and clean design (thus avoiding type clashes that occur in RPC systems, for example). They provide for network wide garbage collection and use pairs of streams on top of a transport abstraction for communication. While the described implementation does not (yet) show very good performance, similar techniques to those used to speed up RPC systems can be used to also improve the performance of network objects. Network objects presents a clear and clean distributed code execution model that features many innovative ideas, such as the possibility to use several transport mechanisms, the use of the Modula-3 pickling mechanism to marshal complex data types and the use of a strongly typed language to ensure type safety across the network. While network objects are not replicated or support the automatic migration of objects, these services can be implemented on top of network objects and the network objects design is not marred by the complexity of these features. In my opinion, network objects represents a good balance between features and simplicity and a good basis for more demanding services. --------------------------------------------------- Return-Path: tian@wally Received: from wally.cs.washington.edu (wally.cs.washington.edu [128.95.2.122]) by whistler.cs.washington.edu (8.8.3/7.2ws+) with ESMTP id XAA07027 for ; Mon, 27 Jan 1997 23:57:09 -0800 Received: (tian@localhost) by wally.cs.washington.edu (8.8.3+CSE/7.2ws+) id XAA31267; Mon, 27 Jan 1997 23:57:09 -0800 (PST) Date: Mon, 27 Jan 1997 23:57:08 -0800 (PST) From: Tian Lim To: Brian Bershad Subject: NetworkObjects 552-reading summary Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Network objects are a new paradigm for distributed applications. They are essentially passive, immobile Modula-3 objects whose methods can be invoked remotely. Clients refer to network objects via local surrogates whose method invocations essentially send RPC requests to the actual network object. Marshalling of complex types is performed with help from the M3 type information, although the default behavior can be overridden by the programmer if necessary. They also address the problem of bulk transfers in RPC systems by providing the means to create and hand off stream endpoints that persist beyond the lifetime of the RPC call. Furthermore, third party transfers of capabilities to exported objects is easy, and the system is able to maintain type safety across address spaces with help from the M3 runtime. It seems odd that they so quickly discarded network object migration. One of the primary reasons for migrating them would be to reduce the communication overhead if many invocations are expected from one site or client (although they do explicitly say that they wanted a clean design first and did not worry about performance). On one hand, network object migration could conceivably be implemented on top of network objects, but intuitively it seems the implementation would be fairly complex. On the other, their choice does simplify naming and type issues as well as the implementation. One such ramification is that the garbage collection of network objects simply uses a network wide refcount. It seems unlikely they would benefit from more elaborate methods, such as distributed mark and sweep, other than the ability to deal with cyclic structures. The result is a simple system and paradigm which is cleaner than RPC. --------------------------------------------------- Return-Path: mernst@nishin.cs.washington.edu Received: from june.cs.washington.edu (june.cs.washington.edu [128.95.2.4]) by whistler.cs.washington.edu (8.8.3/7.2ws+) with ESMTP id GAA09650 for ; Tue, 28 Jan 1997 06:56:39 -0800 Received: from nishin.cs.washington.edu (nishin.cs.washington.edu [128.95.4.39]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with ESMTP id GAA03212; Tue, 28 Jan 1997 06:56:37 -0800 Received: (from mernst@localhost) by nishin.cs.washington.edu (8.8.4/8.8.2) id GAA26577; Tue, 28 Jan 1997 06:56:36 -0800 Date: Tue, 28 Jan 1997 06:56:36 -0800 Message-Id: <199701281456.GAA26577@nishin.cs.washington.edu> From: Michael Ernst To: bershad@cs.washington.edu Subject: NetworkObjects 552-reading summary Network Objects Andrew Birrel, Greg Nelson, Susan Owicki, and Edward Wobbler A network object can be transparently invoked either locally or remotely; if the invocation is remote, a local stub accepts the local invocation, marshals arguments, sends them to the object's owner (a remote machine or different address space), and eventually unmarshals the results, returning them to the caller without it being any the wiser that communication was done. This transparency is key to the ease of implementing network objects: the programmer need not keep in mind where objects reside or call local and remote objects via different interfaces. Network objects are intended to be simple and relatively efficient (their numbers appear to back up the latter claim). A limited form of object migration (via by-value arguments) is supported for non-network objects. Of particular interest are the garbage collection algorithm (which uses reference counting for remote machines, but contains special code to account for machines that have gone down or become temporarily disconnected from the network) and the marshalling code, which depends on a "pickling" procedure. (That procedure depends on compiler support to provide a unique fingerprint for each distinct type in the system.) --------------------------------------------------- Return-Path: sungeun@wormwood Received: from wormwood.cs.washington.edu (wormwood.cs.washington.edu [128.95.2.107]) by whistler.cs.washington.edu (8.8.3/7.2ws+) with ESMTP id IAA10658 for ; Tue, 28 Jan 1997 08:35:07 -0800 Received: (sungeun@localhost) by wormwood.cs.washington.edu (8.8.3+CSE/7.2ws+) id IAA20492; Tue, 28 Jan 1997 08:35:06 -0800 (PST) Date: Tue, 28 Jan 1997 08:35:06 -0800 (PST) Message-Id: <199701281635.IAA20492@wormwood.cs.washington.edu> From: Sung-Eun Choi To: bershad@cs Subject: NetworkObjects 552-reading summary Reply-To: sungeun@cs.washington.edu Network objects are claimed to be an easy-to-use generalization of RPC. Specifically, network objects are objects in Modula-3 whose methods are invoked remotely, i.e., on a different machine or in a different address space. Due to their inherent encapsulation, objects are a nice abstraction for providing distributed services. The authors identified what they believed to be the essential features required for distributed programming and included these features in their system. First, they implemented distributed garbage collection. They reuse the runtime type data structures necessary for garbage collection to implement a general marshalling sheme. The system supports type safety at runtime, a nice requirement of all real object-oriented languages. Finally, they also provide general byte streams, apparently a feature missing in most RPC systems. It appears using network objects requires the programmer to be quite explicit. For example, a network object must register with the owner to aid in garbage collection (perhaps this explicit freeing is part of Modula-3?). Network objects are distinct from regular objects, possibly placing limitations on the extensibility of the system. In addition, network objects are not mobile, a decision that limits availability of services. On the other hand, these "restrictions" may enable opportunities for new static optimizations. --------------------------------------------------- Return-Path: echris@merganser Received: from merganser.cs.washington.edu (merganser.cs.washington.edu [128.95.2.192]) by whistler.cs.washington.edu (8.8.3/7.2ws+) with ESMTP id IAA11025 for ; Tue, 28 Jan 1997 08:55:58 -0800 Received: (echris@localhost) by merganser.cs.washington.edu (8.8.3+CSE/7.2ws+) id IAA22362; Tue, 28 Jan 1997 08:55:58 -0800 (PST) Date: Tue, 28 Jan 1997 08:55:58 -0800 (PST) Message-Id: <199701281655.IAA22362@merganser.cs.washington.edu> From: E Christopher Lewis To: bershad@cs Subject: NetworkObjects 552-reading summary Reply-To: echris@cs.washington.edu Birrell et al. describe the design and implementation of an object-based system, called network objects, for the development of reliable distributed systems. In the network objects system, objects are not mobile, network objects are communicated by reference, "regular" objects are communicated by copy, and virtually all high-level issues (persistence, replication, reliability, etc.) are left to the programmer. The guiding principle in the design of this system is that simple and explicit is good, as the authors hope to preserve the feel of RPC with OO conveniences. Toward this end, the authors reject system-wide performance features (such as object migration, automatic load balancing, or language support) and reliability features (such as all the CATOS stuff), and they strive to provide a minimal set of features that will allow for the convenient construction of distributed systems. This is a wise approach for two reasons. First, it is valuable to describe the operation and feasibility of an explicit system. And second, they would otherwise have had to rumble with Cheriton and Skeen at SOSP '93. --------------------------------------------------- Return-Path: matthai@franklin.cs.washington.edu Received: from franklin.cs.washington.edu (franklin.cs.washington.edu [128.95.2.103]) by whistler.cs.washington.edu (8.8.3/7.2ws+) with ESMTP id IAA11054 for ; Tue, 28 Jan 1997 08:57:28 -0800 Received: from localhost (localhost [127.0.0.1]) by franklin.cs.washington.edu (8.8.3+CSE/7.2ws+) with SMTP id IAA30535; Tue, 28 Jan 1997 08:57:27 -0800 (PST) Message-Id: <199701281657.IAA30535@franklin.cs.washington.edu> X-Mailer: exmh version 1.5.3 12/28/94 To: bershad@franklin.cs.washington.edu, Matthai Philipose Subject: NetworkObjects 552-reading summary Reply-to: Matthai Philipose Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 Jan 1997 08:57:27 PST From: Matthai Philipose Objects communicate by sending messages. Each object (class) specifies an interface via which others may interact with it, and when another object invokes a method in the interface, a table-lookup is performed to choose the appropriate implementation of the method, which is then invoked. If the method invocation is an RPC, we have a clean mechanism for objects that are between two addresses spaces to communicate. Network objects is a design for such a mechanism. The two main questions addressed in the design are: 1)What is the minimum functionality that a useful distributed-object system must supply? They identify marshalling, distributed garbage collection, strong type-checking and providing efficient support for streaming operations. I agree with these choices, except that I think object migration may be an important additional functionality to have: co-locating communicating processes/related data should be a performance win in many applications. 2)How should this functionality be implemented? --They provide a strong form of marshalling, called pickling, which allows objects (and every object they refer to transitively) to be converted to a wire representation. --They provide a form of reference-counting garbage collection for network objects that leverages off local garbage collectors. --They allow the creation and distribution of stream-objects that persist beyond the RPC that created them, and that may communicate via an appropriate bulk-transfer protocol. --Strong type-checking seems to be achieved by ensuring that the interface to the network-objects package is just a M3-interface. No special rules are therefore required to type-check network-object related code. The design provided is remarkably clean and simple; remote communication is well abstracted away, and machine or user-specific issues such as transport protocol and custom-pickling procedures are handled well by isolating them in classes. On the other hand, it will be interesting to see to what extent the simplicity of the interface can be maintained once "non-essential" features such as object mobility and replication are added. --------------------------------------------------- Return-Path: govindk@shasta.ee.washington.edu Received: from june.cs.washington.edu (june.cs.washington.edu [128.95.2.4]) by whistler.cs.washington.edu (8.8.3/7.2ws+) with ESMTP id KAA12845 for ; Tue, 28 Jan 1997 10:53:45 -0800 Received: from shasta.ee.washington.edu (shasta.ee.washington.edu [128.95.28.11]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with SMTP id KAA21444 for ; Tue, 28 Jan 1997 10:53:44 -0800 Received: from andes.faulty (andes.ee.washington.edu) by shasta.ee.washington.edu (4.1/SMI-4.1) id AA01844; Tue, 28 Jan 97 10:54:54 GMT Received: by andes.faulty (SMI-8.6/SMI-SVR4) id KAA23487; Tue, 28 Jan 1997 10:54:33 -0800 Date: Tue, 28 Jan 1997 10:54:33 -0800 From: govindk@shasta.ee.washington.edu (Govindarajan K) Message-Id: <199701281854.KAA23487@andes.faulty> To: bershad@cs Subject: NetworkObjects 552-reading summary The paper deals with Network Objects as an alternative to RPC. Network Objects are objects whose methods can be executed on a remote machine thus having an operation similar to that of RPC. The important aspects of the NetObj paradigm (*)simplicity: The feature set restricts itself to the ones which are valuable to running distributed applications and it has left out the complex ones. (*) General purpose marshalling technique called pickles: It uses the same data structures used by the garbage collector to perform efficient marshalling for arbitarily complicated data types. (*) In their treatment of streams data is not communicated via RPC, but by the underlying transport communication, this way the streams which are passed are not limited to the duration of the RPC call. (*) Third party transfers of objects is simple as compared to traditional RPC. (*) The ambiguity of there being more than one possible surrogate type available in the client is resolved by the narrowest surrogate rule. (*)Failure semantics for failure of callee and caller processes included but does not distinguish between failure of a process or failure of the communication link between the callee and the caller. (*) Garbage collection is done in a very interesting way where in the runtime maintains for each exported network object a dirty set having a list of clients having surrogates for this object and the pointer to the object is retained till the dirty set is non-empty. (*) Performance measurements prove the authors claim that they havent looked to optimize a great deal, but they havent compared its performance with a similar distributed object paradigm. Network Objects thus represents a nice methodology to run distributed applications.