"Network Objects", Birrell, Nelson, Owicki, Wobber, SOSP 1993. What problems are they trying to solve? Make RPC more transparent! Avoid explicit server binding arguments to all RPCs. Automatic handling of object handles. 3rd-party transfers. Distributed GC. More convenient marshaling (via pickling; avoid complete type specs). Can we think of any situation where this would be valuable? X clients exchange complex data in cut buffers via server. This is not client/server! Symmetric. What restrictions are they willing to live with? OO. Language-dependent. Pure types -- methods only. All types descended from NetObj.T. How do they provide location transparency for objects? Attaches a fixed location to each object. Tracks locations automatically. Allows one to pass/return objects in any call. Pass objects to any machine (not just object's server). Was this model inevitable? Why not distributed shared memory? (To support non-pure objects.) Why not allow objects to move? How does a call on a surrogate's method work? I.e. client already knows about the object. Surrogate in client contains SpaceID/ObjID, location, and stub method. Stub method creates a new connection to the owner (SpaceID). In owner, connection's thread reads the ObjID. Looks up ObjID in object table, calls object's dispatch stub method. Dispatch stub method reads method # and args, calls real method. Marshalls return value and sends back. What if a network object is passed as an argument/return value? Object owner: Create entry in object table (i.e. allocate an ObjID). Set the real object's disp field from stub table. Object sender: Send SpaceID and ObjID across network. "WireRep" Object receiver: Check object table to see if a surrogate already exists. Find owner by asking sender about SpaceID. Ask owner for type. Figure out corresponding local type code. Create a surrogate for that type, Tsrg from stub table. Send a "dirty" message to owner. Various tables: objtbl: SpaceID, ObjID, Ref NetObj: State, WireRep, Location, Dispatcher (not really a table) stubs: TypeCode, TypeCode (of surrogate), Dispatcher names: SpaceID, Endpoint maps between TypeCode and Fingerprint What are TypeCodes? What are fingerprints? Where do they come from? Why are they neccessary? Type relationships T, TImpl, TSrg, parents of T TImpl is *not* the same as T. What if the client stub for a class isn't present? What if the server stub isn't present? What if the client casts an object and then calls a method? Cast up inheritance tree -- no difference. Cast down -- no difference, but not allowed to cast below Tsrg. System has to get surrogate types right regardless of declarations. What does the stub compiler produce for T? Surrogate sub-class of T. Methods overridden to marshall and call owner. Dispatcher function in owner. Unmarshalls, calls correct real method. Puts both in stub table. What does N.O. require from the surrounding system? Universal naming of computers (i.e. IP addresses), for SpaceID/Endpoint. Universal connectivity. (NAT? firewalls?) A name registry to get started. Automatic allocation, so N.O. can create stub objects. Garbage collection, so N.O. can free stub objects. Does it have to be reference counting? Run-time type tags: to allocate surrogates. Type fingerprints: portable type descriptions. Threads, so a program can always service calls w/o deadlock. Is it fully transparent to the programmer? I.e. can we add it to existing programs with no pain? You have to run the stub generator on the right types. You have to make the right types children of NetObj.T If objects are the right granularity of location. If objects don't need to move. If all object accesses are through methods. If performance isn't a problem. If security isn't a problem. If you don't have to GC inter-machine cycles. If no hidden concurrency problems: if(item.inventory() > 0){ item.decrement_inventory(); shipment.add_item(item); } Or partial failure (after the decrement). Does N.O. solve real problems? Dramatically more transparent than ordinary RPC! Is this a good paper? Does it have clearly stated claims? Does it support those claims? Does it analyze whether the system is successful?