Network Objects

Authors: A. Birrel, G. Nelson, S. Owicki, and E. Wobber
Notes by Kevin Walsh

Overview

Motivation: Need a good way to distribute objects in the network, not just methods (RPC). This makes communication with multiple servers simpler by associating an object with it's server.

Problems with RPC: Client & server must bind with different "fake" implementation of network interface. This makes it difficult for one program to implement both client and server.

Network Objects (NOs)

• Object is transferred by reference to another process.
• The client sees a stub "Surrogate" object, which behaves just like a normal local object.
• Method invocations are forwarded back to "owner" process of the object. Arguments and return values are marshalled.
• Binding to "owner" is per-object and NOs are transferable to 3rd party processes.

Other features

• Supports network garbage collection (except for cross-network cyclic references) by counting processes which contain surrogates
• Network Streams: specialized case to marshall stream handles by inserting the cross-process transport stream.
• Can be used for IPC also, with no change of code.
• Multiple transport mechanisms (TCP, shared memory, IPC)
• Narrowest-surrogate rule allows multiple versions of NOs.
• Flexible marshalling of objects: NOs are transferred by reference (using surrogates). Other objects are by copy, with user-hooks for custom marshalling code

Implementation

• Each network object type gets a unique fingerprint, derived from it's structure, and a unique ID (sp, i) where sp is a unique ID for owner process and i is a index into that process.
• To pass a NO by reference, server passes the (sp,i) pair. If client is the owner of (sp, i), it uses the original object. Otherwise, client tells owner (found using sp) that a surrogate is being created for object i (for garbage collection), and receives a list of fingerprints for supertypes of the object. The client picks a type which is lowest in this hierarchy that it knows how to instantiate (allows for versioning).
• The owner of a NO maintains a list of clients with surrogates (for garbage collection). During and incoming method invocation, the object is unmarshalled, and per-object dispatch code decodes the arguments and returns a (marshalled) reply.

Questions

How does this co-exist with other networks or environments? It seems to assume that all network connections are NO related.

Security Issues (reading objects private data)?