Network ObjectsAndrew Bh-rell, Greg Nelson, Susan Owicki, and Edward WobberDigital Systems Research CenterAbstractA network object is an object whose methods canbe invoked over a network. This paper describes thedesign, implementation, and early experience with anetwork objects system for Modula-3. The system isnovel for its overall simplicity. The paper includesa thorough description of realistic marshaling algo-rithms for network objects.1 IntroductionIn pure object-oriented programming, clients cannotaccess the concrete state of an object directly, butonly via the object’s methods. This methodology ap-plies beautifully to distributed computing, since themethod calls are a convenient place to insert the com-munication required by the distributed system. Sys-tems based on this observation began to appear abouta decade ago, including Argus [12], Eden [1], andearly work of Shapiro’s [18], and more keep arrivingevery day. It seems to be the destiny of distributedprogramming to become object-oriented, but the de-tails of the transformation are hazy. Should objectsbe mobile or stationary? Should they be communi-cated by copying or by reference? Should they beactive? Persistent? Replicated? Is the typical objecta menu button or an X server? Is there any differ-ence between inter-program typechecking and intra-program typechecking?This paper contributes a data point for these dis-cussions by describing a network objects system wehave recently imple~ented for “Modula-3. In additionPermission to copy without fee all or part of this material isgranted provided that the copies are not made or distributed fordirect commercial advantage, the ACM copyright notice and thetitle of the publication and its date appear, and notice is giventhat copying is by permission of the Assoclatlon for ComputingMachinery. To copy otherwise, or to republish, requires a feeand/or specific permission.SIGOPS ‘93/12 /93/N. C., USA@ 1993 ACM 0-89791 -632 -8/93 /0012 . ..$l .50to providing a design rationale, we present a num-ber of implementation details that have been omittedfrom previously published work, including simple al-gorithms for marshaling and unmarshaling networkobjects in a heterogeneous network.The primary distinguishing aspect of our systemis its simplicity.We restricted our feature set tothose features that we believe are valuable to alldistributed applications (powerful marshaling, strongtype-checking, garbage collection, efficient and conve-nient access to streams), and we omitted more com-plex or speculative features (transactions, object mi-gration, distributed shared memory). Also, we orga-nized the implementation around a small number ofquite simple interfaces, each of which is described inthis paper. Finally, we believe we have done this with-out compromising performance: we have not workedhard on performance, but we believe our design iscompatible with a high-performance implementation.As in any distributed programming system, argu-ment values and results are communicated by mar-shaling them into a sequence of bytes, transmittingthe bytes from one program to the other, and thenunmarshaling them into values in the receiving pro-gram. The marshaling code is contained in stub mod-ules that are generated from the object type declara-tion by a stub generator. Marshaling automaticallyhandles format differences in the two programs (forexample, different byte orders for representing inte-gers).It is difficult to provide fully general marshalingcode in a satisfactory way. Existing systems fail inone or more of the following ways. Some apply re-strictions to the types that can be marshaled, typ-ically prohibiting linked, cyclic or graph-structuredvalues. Some generate elaborate code for almost anydata type, but the resulting stub modules are exces-sively large. Some handle a lot of data types, but themarshaling code is excessively inefficient. We believewe have achieved a better compromise here by the use217of a general-purpose mechanism called Pickles. Thisuses the same runtime-type data structures used bythe local garbage collector to perform efficient andcompact marshaling of arbitrarily complicated datatypes. Our stub generator produces in-line code forsimple types (for efficiency ), but calls the pickle pack-age for complicated types (for compactness of stubcode). We believe our pickling machinery’s perfor-mance is within a factor of two of the performance ofmechanically generated in-line code.Since we marshal by pickling and the pickle packagewill handle any reference type, it’s possible to mar-shal arguments or results that are objects. There aretwo cases. If the object being marshaled (by pick-ling) is a network object, it is passed as an objectreference (as described later). Alternatively, if theobject being marshaled is not a network object, it ismarshaled by copying the entire object’s value. Thisprovides a form of object mobility that is satisfactoryfor many purposes, For example, a system like Her-mes [5], though designed for mobile objects, could beimplemented straightforwardly with our mechanisms.Inter-process byte streams are more convenient andefficient than RPC for transferring large amountsof unstructured data, as critics of RPC have oftenpointed out. We have addressed this issue by provid-ing special marshaling support for Modula-3’s st an-dard stream types (readers and writers). To commu-nicate a stream from one program to another, a surro-gate stream is created in the receiving program. Datais copied over the network between the buffers of thereal stream and the surrogate stream in a way thatminimizes data copies: for both the surrogate streamand the real stream, data is transferred between thestream buffer and the kernel via direct calls to readand write. An important feature of this design isthat the stream data is not communicated via RPC!,but by the underlying transport-specific communica-tion. This facility is analogous to the remote pipesof DCE RPC [17], but with a critical difference: thestreams we pass are not limited in scope to the du-ration of the RPC call. When we marshal a streamfrom process A to process B, process B acquires asurrogate stream attached to the same data as theoriginal stream. In process B the surrogate streamcan be used at will, long after the call that passed itis finished. In contrast, in a scheme such as the pipesprovided in DCE, the data in the pipe must be com-municated in its entirety at the time of the RPC call(and at a